PATENT DOCUMENT

Publication Number: US-8892831-B2
Application Number: US-19355108-A
Country: US
Kind Code: B2

Title: Memory subsystem hibernation

Abstract:
In a managed memory subsystem, information associated with the memory subsystem is copied from volatile memory in the memory subsystem to host system memory. The copying can be over a standard interface. Responsive to memory subsystem power up from a powered down state or power loss, the information is copied from the host system memory back to the volatile memory in the memory subsystem, where the information can be used by the memory subsystem to perform memory operations. Transferring information from host system memory to volatile memory in a memory subsystem is faster and more power efficient than transferring the same information from non-volatile memory to volatile memory in the memory subsystem.

Claims:
What is claimed is: 
     
       1. A method comprising:
 copying state information from a volatile memory of a managed memory system into a non-volatile memory included in the managed memory system, wherein the state information includes information used to map logical sector requests from a host system to the non-volatile memory; 
 copying address information from the volatile memory of the managed memory system to a volatile memory of the host system coupled to the managed memory system, wherein the address information includes a physical address of the state information stored in the non-volatile memory; 
 responsive to a power-related trigger event, reading the address information from the volatile host system memory; and 
 using the physical address included in the address information read from the volatile memory of the host system to access the state information stored in the non-volatile memory. 
 
     
     
       2. The method of  claim 1 , wherein the managed memory system is a managed NAND memory system. 
     
     
       3. The method of  claim 1 , wherein the address information is copied over a bus that conforms to at least one of the following standard bus protocols: Advanced Technology Attachment (ATA), MultiMediaCard (MMC) and Secure Digital (SD). 
     
     
       4. The method of  claim 1 , wherein the volatile memory of the managed memory system is accessible by an embedded controller in the managed memory system. 
     
     
       5. The method of  claim 1 , further comprising detecting the power-related trigger event by the managed memory system. 
     
     
       6. The method of  claim 1 , wherein the power-related trigger event comprises the managed memory system powering up from a powered down or power loss state. 
     
     
       7. A memory system, comprising:
 a host system comprising volatile memory; and 
 a managed memory system comprising volatile memory and non-volatile memory, wherein information related to the managed memory system is stored in the volatile memory, and wherein the managed memory system comprises a processor configured to:
 copy state information from the volatile memory of the managed memory system into the non-volatile memory of the managed memory system, wherein the state information includes information used to map logical sector requests from the host system to the non-volatile memory of the managed memory system; 
 copy address information from the volatile memory of the managed memory system to the volatile memory of the host system, wherein the address information includes a physical address of the state information stored in the non-volatile memory; 
 read, responsive to a power-related trigger event, the address information from the volatile host system memory; and 
 use the physical address included in the address information read from the volatile memory of the host system to access the state information stored in the non-volatile memory. 
 
 
     
     
       8. The memory system of  claim 7 , wherein the managed memory system is a managed NAND memory system. 
     
     
       9. The memory system of  claim 7 , wherein the address information is copied over a bus that conforms to at least one of the following bus protocols: Advanced Technology Attachment (ATA), MultiMediaCard (MMC) and Secure Digital (SD). 
     
     
       10. The memory system of  claim 7 , wherein the processor is further configured to detect the power-related trigger event. 
     
     
       11. The memory system of  claim 7 , wherein the power-related trigger event comprises the managed memory system powering up from a powered down or power loss state.

Description:
RELATED APPLICATION 
     This application claims the benefit of priority from U.S. Provisional Application No. 61/021,560, for “Memory Subsystem Hibernation,” filed Jan. 16, 2008, which provisional application is incorporated by reference herein in its entirety. 
    
    
     TECHNICAL FIELD 
     This subject matter is generally related to managing solid state memory systems. 
     BACKGROUND 
     Managed memory solutions use industry-standard interfaces to provide seamless integration with host processors and eliminate the need for host systems to manage the complexity and deficiency of built-in memory devices. A typical managed memory solution integrates memory and an embedded controller. The embedded controller can emulate a block device interface, thus replacing emulation that is commonly performed by the host system. 
     In some managed memory solutions, an embedded controller in the memory subsystem uses volatile memory to store information related to the current state of the memory subsystem. A copy of this state information is also stored in non-volatile memory of the memory subsystem to preserve the information in case of power loss. 
     When the memory subsystem is powered up from a powered down or power loss state, the embedded controller reads the state information from non-volatile memory and stores the information in volatile memory for easy access. The process of reading state information from non-volatile memory and storing the state information in volatile memory in the memory subsystem takes time due to overhead and some processing of the state information. This delay, however, is often of no concern when this power down/power up cycle is infrequent (e.g., during initial power up). 
     To save power, it can be desirable to shut down power to a memory subsystem frequently. Every time the memory subsystem is powered up from a shutdown state, the memory subsystem reads state information from non-volatile memory as previously described. If this shutdown/power up cycle occurs on a regular basis, the additional reads to non-volatile memory and subsequent data processing can cause delay and loss of power which can negate any benefit obtained by frequently shutting down power to the memory subsystem. 
     SUMMARY 
     In a managed memory subsystem, information associated with the memory subsystem is copied from volatile memory in the memory subsystem to host system memory. The copying can be over a standard interface. Responsive to memory subsystem power up from a powered down state or power loss, the information is copied from the host system memory back to the volatile memory in the memory subsystem, where the information can be used by the memory subsystem to perform memory operations. Transferring information from host system memory to volatile memory in a memory subsystem is faster and more power efficient than transferring the same information from non-volatile memory to volatile memory in the memory subsystem. 
    
    
     
       DESCRIPTION OF DRAWINGS 
         FIG. 1  is a block diagram of an example managed memory system. 
         FIG. 2  is a flow diagram of an example boot process for the managed memory system of  FIG. 1 . 
     
    
    
     DETAILED DESCRIPTION 
     Example System 
       FIG. 1  is a block diagram of example managed memory system  100 . The Managed memory system  100  can be a solid state memory system (e.g., a managed NAND system) formed on a single substrate or chip (e.g., system on chip (SoC)). In some implementations, system  100  can include host system  102  coupled to memory subsystem  104  by interface  110 . Interface  110  can be a standard interface, such as Advanced Technology Attachment (ATA) standard interface, MultiMediaCard (MMC) interface or Secure Digital (SD) interface. Some examples of memory subsystem  104  can include MMC/SD cards or SSD. 
     Memory subsystem  104  can include controller  106  coupled to non-volatile memory  120  by interface  112 . Controller  106  can be an embedded controller. Interface  112  can be a NAND interface, for example. Block device emulator  122  can be a software layer which translates logical sector requests from host system  102  to physical reads/writes to non-volatile memory  120 . Driver  118  in controller  106  can be a low-level driver that reads from and writes to non-volatile memory  120  (e.g., NAND memory). Volatile memory  116  (e.g., RAM) which can be integrated in, or accessible by, controller  106  can be used to store information relating to a current state of memory subsystem  104 . States can include, for example, a mapping of logical sectors requested by host system  102  on non-volatile memory  120 . More particularly, volatile memory  116  can store tables that translate requests from host system  102  to non-volatile memory  120 . This state information is often stored in non-volatile memory  120  as well, so if there is a power shutdown or failure, controller  106  can retrieve the state information from non-volatile memory  120  and store the information in volatile memory  116  for quick access. The dashed lines conceptually illustrate this process. Memory subsystem  104  may include other components which have been omitted from  FIG. 1  for clarity. 
     Host system  102  (e.g., a media player, mobile phone, digital camera) includes host processor  126  and memory  114  (e.g., RAM). Host processor  126  can execute instructions (e.g., firmware) to control communications across interface  110  and to access memory  114 . If memory  114  is volatile memory, then memory  114  can be periodically refreshed by host processor  126 . Host system  102  may include other components which have been omitted from  FIG. 1  for clarity. 
     Example Process 
       FIG. 2  is a flow diagram of an example power up process  200  for system  100  of  FIG. 1 . In some implementations, process  200  can begin when information (e.g., state information) is copied from volatile memory (e.g., RAM) in a memory subsystem to memory in a host system ( 202 ) coupled to the memory subsystem. For example, the information can include a physical address in non-volatile memory where the managed NAND is storing state information which can be used for a faster boot. Typically, NAND drivers save state information on the NAND so that when the system boots up the state information is read from the NAND. The state information is not always stored in the same location in NAND due to wear leveling algorithms. By sending the physical address of the state information to the host device, the managed NAND subsystem need not export the state information to the host device which can result in a faster boot time than if the state information was sent to the host device. 
     Next, a power-related trigger event (e.g., a power up request) is received or detected by the memory subsystem ( 204 ). In some implementations, the power-related trigger event can be an intentional power down of the memory subsystem to conserve power. Such an implementation can be useful for battery-operated devices. 
     Responsive to the power-related trigger event, the information is read from memory in the host system to volatile memory in the memory subsystem ( 206 ). Once the information is stored in the volatile memory, the information can be easily accessed by, for example, an embedded controller in the memory subsystem. In some implementations, the volatile memory can be included in the embedded controller. In other implementations, volatile memory can be included in other portions of the memory subsystem or external to the memory subsystem. 
     A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made. For example, elements of one or more implementations may be combined, deleted, modified, or supplemented to form further implementations. As yet another example, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.

Metadata:
Filing Date: 20080818
Publication Date: 20141118
Grant Date: 20141118
Priority Date: 20080116
Inventors: KHMELNITSKY VADIM
WAKRAT NIR JACOB
Assignee: APPLE INC
CPC Classifications: [{"code": "Y02B60/1235", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F13/4239", "inventive": true, "first": true, "tree": "[]"}, {"code": "Y02B60/1228", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F13/4239", "inventive": true, "first": true, "tree": "[]"}, {"code": "Y02D10/00", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F13/4239", "inventive": true, "first": true, "tree": "[]"}, {"code": "Y02D10/00", "inventive": false, "first": false, "tree": "[]"}]
Family ID: 40851699