Memory module, method for managing operational state data in said memory module, and host device

Abstract

This specification and drawings present a novel apparatus and method for managing / configuring storage of operational status data for operating the memory module controller in various operating modes / conditions of a memory module and the host system memory, via a memory module controller, into an extended random access memory (ERRAM) system contained within both a memory module and the host system memory of a host device. Essentially, the memory module controller functions as the main controller for data transfer as described herein. The operational status data generally includes status information, a logic-to-physical (L2P) mapping table, and register settings.

Description

Technical Field

[0001] The exemplary and non-limiting embodiments of the present invention are generally related to memory storage systems, and more specifically to the management / configuration of the storage of operational status data for memory modules by means of a memory module controller. Prior Technology

[0002] This section is intended to provide background or context for the inventions described in the claims. The description herein may include feasible concepts, but not necessarily concepts that have been previously conceived, implemented, or described. Therefore, unless otherwise stated herein, the content described in this section is not prior art to the descriptions and claims of this invention, and is not considered prior art by virtue of its inclusion in this section.

[0003] The following abbreviations, which may be found in this specification and / or drawings, are defined as follows: ASIC Application-Specific Integrated Circuits CPU (Central Processing Unit) DMA (Direct Memory Access) DRAM (Dynamic Random Access Memory) eMMC Embedded Multimedia Card exFAT Extended File Configuration Table HW Hardware IO input / output JEDEC (Joint Electron Device Engineering Committee) LBA Logical Block Address MMM, MM refers to a large number of memory modules or memory modules. MMC Multimedia Card MMCO Memory Module Controller MRAM (Magnetic Random Access Memory) OS operating system P2L Entity to Logic PCRAM (Phase Change Random Access Memory) RAM (Random Access Memory) Resistive Random Access Memory (RRAM) SATAIO Serial Advanced Technology Attached International Organization SCSI Minicomputer System Interface SD Digital Security SM system memory or host system memory SRAM (Static Random Access Memory) SSD solid-state drive SW software UFS Universal Flash Memory

[0004] There are currently several types of flash mass storage memory. A fundamental premise of mass storage memory is to hide the complexity of flash technology from the host system. eMMC technology is one example. Managed NAND memory can be, for example, eMMC, SSD, UFS, or microSD.

[0005] Figure 1A is a reproduction of Figure 2, based on the JEDEC standard established by the JEDEC Solid State Technology Association in June 2007: High-Capacity Embedded eMMC Product Standard, JESD84-A42, and shows a functional block diagram of an eMMC. This JEDEC eMMC standard includes: an intelligent onboard controller that manages the MMC communication protocol, in addition to the flash memory itself. This controller also handles block management functions, such as logical block allocation and wear leveling. The interface includes a clock (CLK) input. It also includes a command (CMD), which is a bidirectional command channel for device initialization and command transmission. Commands are sent from a bus master to the device, and responses are sent from the device to the master. It also includes a bidirectional data bus (DAT[7:0]). The DAT signals operate in push-pull mode. By default, only DAT0 is used for data transmission after power-on or restart. The memory controller can be configured with a larger data bus to use DAT[3:0] (4-bit mode) or DAT[7:0] (8-bit mode) for data transfer.

[0006] A non-limiting example of a flash memory controller architecture is described in "A NAND Flash Memory Controller for SD / MMC Flash Memory Card" published by Chuan-Sheng Lin and Lan-Rong Dung in IEEE Transactions of Magnetics, Vol. 43, No. 2, pp. 933-935 (hereinafter referred to as Lin et al.). Figure 1B is a reproduction of Figure 1 by Lin et al. and shows an overall block diagram of the NAND flash controller architecture for SD / MMC memory cards. The particular controller shown in the figure happens to use a w-bit parallel Bose-Chaudhuri-Hocquengham (BCH) error correction code (ECC) designed to work in conjunction with a code paging mechanism to correct random bit errors in the flash memory. Summary of the Invention

[0007] According to a first aspect of the present invention, a method includes: dynamically managing storage of all or part of the operating state data for operating the memory module controller in an extended random access memory (ERRAM) via a memory module controller of a mass memory module, the ERAM being included in a memory of the mass memory module and a host system memory of a host device; and restoring an operating state of the memory module controller by reading at least a portion of the operating state data from one or more of the following: the ERAM and a non-volatile mass memory, after the memory module controller has been awakened from a power-off or sleep state of the mass memory module: the ERAM and a non-volatile mass memory.

[0008] According to a second aspect of the present invention, an apparatus includes: a mass memory module including an extended random access memory (ERRAM) and a portion of a host system memory (NAS) within a host device; and a memory module controller configured to dynamically manage the storage of all or a portion of operational state data for operating the memory module controller into the ERAM, the ERAM being contained in a memory of the mass memory module and the NAS of the host device, the memory module controller being further configured to, upon waking from a power-off or sleep state of the mass memory module, read all or a portion of the operational state data from one or more of the ERAM and a non-volatile mass memory of the mass memory module to restore an operational state of the memory module controller. Simple Explanation of the Diagram

[0009] Figure 1A is a re-creation of Figure 2, based on the JEDEC standard established by the JEDEC Solid State Technology Association in June 2007: High-capacity Embedded eMMC Product Standard, JESD84-A42, and shows a functional block diagram of an eMMC. Figure 1B is a reproduction of Figure 1 by Lin et al., and shows an example of an overall block diagram of an anti-flash controller architecture for SD / MMC memory cards; Figure 2 is a simplified block diagram of a host device connected to a mass storage memory device, which helps to describe exemplary embodiments of the present invention; Figure 3 is a signal / message flowchart illustrating an embodiment of the invention described in co-assigned U.S. Patent Application No. 12 / 455,763, wherein the mass storage memory device in Figure 2 is the RAM of the host device that can be allocated, used, and disposed of; Figure 4 is a signal / message flowchart illustrating another embodiment of the invention described in co-assigned U.S. Patent Application No. 12 / 455,763, wherein the mass storage memory device of Figure 2 has a built-in file system; Figures 5A and 5B, collectively referred to as Figure 5, are representative diagrams of a host device and a mass memory module according to embodiments of the present invention; Figure 6 is a logical flowchart illustrating the operation method and execution result of computer program instructions contained in a computer-readable memory, as further illustrating an exemplary embodiment of the present invention. Figures 7A and 7B show examples of the memory module controller memory mapping in the memory module when system resources, such as the DRAM 14G portion, are disabled (Figure 7A) or enabled (Figure 7B); Figure 8 is a schematic diagram illustrating an embodiment shown in the flow diagram of Figure 6, in which a memory controller responds to an instruction (or an attribute of an instruction) from a host device; and Figure 9 shows a block diagram of an exemplary embodiment of the host device when it is specifically used as a wireless communication device. Implementation

[0010] The exemplary embodiments described below are of interest to commonly assigned U.S. Patent Application No. 12 / 455,763 (US 2010 / 0312947 A1), filed June 4, 2009, by Olli Luukkainen, Kimmo Mylly, and Jani Hyvonen, entitled "Apparatus and Method to Share Host System RAM with Mass Storage Memory RAM," which is incorporated herein by reference. Before describing the exemplary embodiments of the invention in detail, it will be useful to review at least a portion of the specification of this commonly assigned U.S. Patent Application No. 12 / 455,763.

[0011] As mentioned earlier, most mass storage devices currently offer LBA-based access methods, such as eMMC and various types of external memory cards like SD cards. However, it is also possible for the entire File System (FS) to be embedded within the mass storage device.

[0012] When large amounts of storage memory are used in high-capacity consumer electronics devices, such as mobile wireless communication devices, cost is an important consideration. One factor affecting cost is the amount of RAM in the large storage memory device itself.

[0013] Another important consideration is performance. Overall performance depends on many factors. For example, for long-running (time-consuming) operations (especially if the large storage device contains the entire file system switch), including a large amount of RAM in the large storage device is an advantage. However, this will have a negative impact on cost.

[0014] This could be a case where the system's main data (metadata) is stored in the flash memory of the mass storage device. However, this method has several associated drawbacks. For example, repeatedly writing the system's main data (metadata) to the mass storage device increases wear and tear, which can affect the device's lifespan. Furthermore, writing data to the flash memory can be a relatively slow process.

[0015] Another important consideration is power efficiency. For good power efficiency, the large storage memory (LBA) should ideally be powered off when not in use (meaning the device's internal RAM should also ideally be powered off). However, assuming the RAM is inherently volatile, any data stored in it will be lost when power is removed. A reinitialization must then be performed upon power-on, requiring all necessary information (such as logical-to-physical mapping information and / or file system structure) to be re-stored. A complete reinitialization of an LBA can take a significant (and noticeable) time (e.g., up to one second with an SD card), and overall file system initialization (if the file system resides in the LBA) can take even longer. Therefore, it is still worthwhile to retain the core of the internal device during the power-off / power-on cycle.

[0016] Figure 2 shows a simplified block diagram of a host system or device 10 connected to a mass storage memory 20 via a mass storage bus (MSMB) 18. The MSMB 18 is compatible with any suitable mass storage interface standard, such as MMC or UFS, which are non-limiting examples. The MSMB 18 may include signal lines such as those shown in Figure 1A for an eMMC embodiment. The host device 10 includes at least one controller, such as a CPU 12 operating according to stored program instructions. These instructions may be stored in a RAM 14, or in another memory or multiple memory locations. The CPU 12 is connected to the RAM 14 and an MSMB interface (I / F) 16 via at least one internal bus 17. The MSMB interface 16 may include a memory controller (MC), or may be coupled to an MC unit associated with the CPU 12. The host device 10 can be a computer, a mobile phone, a digital camera, a gaming device, or a digital assistant (PDA), among other non-limiting examples. It should be noted that the RAM 14 can be any read / write memory or memory device, such as semiconductor memory or a disk-based memory.

[0017] The mass storage memory 20 includes a microcontroller, or more simply, a controller 22 connected via at least one internal bus 27 to a volatile RAM 24, a non-volatile mass storage memory 26 (e.g., a flash mass storage memory containing several gigabytes), and an MSMB interface (I / F) 28. The controller 22 operates according to stored program instructions. These instructions may be stored in RAM 24, a read-only memory (ROM), or the mass storage memory 26. The mass storage memory 20 may be specifically, in non-limiting examples, an MMC, eMMC, UFS, or SD device; and it may be externally connected to (inserted into) the host device 10 or installed within the host device 10. It should be noted that in some embodiments, the mass storage memory 26 stores a file system (FS) 26A. In this case, the RAM 24 series can store metadata 24A associated with the FS, such as one or more data structures containing bitmaps, file configuration table data and / or other FS-related information.

[0018] An embodiment of the invention described in jointly assigned U.S. Patent Application No. 12 / 455,763 provides a technique for sharing RAM 14 of a host device 10 with the mass storage memory device 20. It can be assumed that the host device 10 (e.g., a mobile computer, a mobile phone, a digital camera, a gaming device, a PDA, etc.) has the ability to allocate and deallocate RAM 14. The allocation of RAM 14 can be performed dynamically or statically. The allocation of a portion of the RAM can be performed in response to a request received by the host device 10, or in response to an active request from the host device 10.

[0019] In an embodiment of the invention described in jointly assigned U.S. Patent Application No. 12 / 455,763, if the Mass Storage Memory 20 needs to expand its own RAM 24 space, and / or if the Mass Storage Memory 20 needs non-volatile RAM (whose contents are not lost when the Mass Storage Memory 20 is powered off), the RAM 14 is allocated for use by the Mass Storage Memory 20 (connected to the host CPU 12 via the MSMB 18). The Mass Storage Memory 20 can also read from and / or write to (R / W) the allocated RAM 14 in the host device 10. This allocation / deallocation and R / W access method can be implemented by an extension of an instruction set used to communicate with the Mass Storage Memory 20 via a suitable Mass Storage Protocol.

[0020] According to certain embodiments of the invention described in co-assigned U.S. Patent Application No. 12 / 455,763, the mass storage memory device 20 provides a mechanism for interrupting / sending a message to the host device 10 to initiate space allocation in RAM 14. The interrupt message is sent to MSMB 18 and can be considered an extension of the current instruction set. Referring to Figure 3, a memory allocation instruction is sent in process 3-1. If the allocation request is successful (as indicated in process 3-2), the controller 22 can extend its own RAM 24 using the host device 10's RAM 14. This mass storage memory device 20 can use a RAM WRITE instruction to store, for example, a large table into RAM 14, or it can use a RAM READ instruction to retrieve data from the host device RAM 14. The read or write operations are shown as interleaved processes 3-3, 3-4, 3-5, 3-6, ..., 3-(N-1), 3-N. When the mass storage memory device 20 and the RAM 14 complete the process, they can use another instruction (operation 3-(N+1)) to request the RAM memory of the host device 10 to be disposed of to release the host device RAM 14.

[0021] Figure 4 illustrates a further exemplary embodiment described in co-assigned U.S. Patent Application No. 12 / 455,763, which utilizes the RAM 14 of a host system for use by a mass storage memory 26 having a built-in file system (FS 26A as shown in Figure 2). First, the host system 10 sends a SHUTDOWN instruction to the mass storage memory 20 (procedure 4-1). Then, the mass storage memory 20 allocates RAM 14 from the host 10 and loads (e.g., using a RAM WRITE instruction) all important "static" file system-related data (metadata 24A) into the host RAM 14 (procedure 4-2). In this context, a "static" file can be, for example, a various bitmap, such as an allocated bitmap in an exFAT or ext3 file system. This data can be processed by the CPU 12 (controller) of the host device (e.g., sorting, arranging, and filtering at least one of these), and can contain data from a large number of segments in the mass storage memory 26. Mass storage device 20 can then send a shutdown OK instruction (process 4-3). The host device 10 can remove power from the mass storage device 20, and the device 20 can be physically removed from the MSMB 18. The reinitialization process of the mass storage device 20 (processes 4-4, 4-5, 4-6) is performed when the host device 10 needs to obtain / put some data into the mass storage device 20. The reinitialization of the mass storage 26 (and file system 26A) can be accelerated by using sorted / arranged / filtered read data from the RAM 14. When the reinitialization process is complete, the file storage device 20 can deallocate the RAM 14 used by the host device 10, or the RAM 14 can be left undeallocated to reserve RAM space for future use by the mass storage device 20.

[0022] In some embodiments, the allocation of host RAM 14 can occur in different ways. For example, the host device 10 can dynamically allocate RAM 14 and pass an "indicator" to the allocated RAM in the mass storage device 20. The controller 22 of the mass storage device 20 then determines how to utilize the allocated host RAM 14. It should be noted that in this embodiment, an explicit allocation request from the mass storage device 20 may not be sent to the host device 10. Instead, the host device 10 can proactively allocate a portion of the RAM 14, for example, when the presence of the mass storage device 20 is first detected. Of course, subsequent signals between the mass storage device 20 and the host device 10 can be used to change the size of the allocated RAM 14 if the initial allocation is insufficient for the needs of the controller 22. Another example of RAM 14 allocation is that a portion of RAM 14 can be allocated statically by the host device 10, and the mass storage device 20 then only needs to use the same portion of RAM 14 each time it needs to expand its RAM 24. In this case, the mass storage device 20 may already have knowledge of the location / size of the allocated RAM 14 and does not need to send an indicator from the host device 10.

[0023] It should be noted that, although it may typically be the case that the mass storage memory device 20 receives allocation from the host memory to store the contents of the volatile RAM 24, generally the allocation can be used to store data from any read / write memory contained within the mass storage memory device 20.

[0024] With the overview of various non-limiting and exemplary embodiments of the invention described in commonly assigned U.S. Patent Application No. 12 / 455,763 provided, exemplary embodiments of the invention will now be described. In a managed NAND memory (e.g., eMMC, SSD, UFS, microSD), the memory controller (e.g., controller 22 shown in FIG. 2) is responsible for flash management functions, such as bad block management and wear leveling. In a typical low-cost build, only a small amount of input / output (I / O) buffered static random access memory (buffer SRAM) is present within the managed NAND. In memory modules of more advanced managed NAND, such as SSDs, tens to hundreds of megabits of discrete DRAM can be embedded therein as cache memory. In some newer storage technologies of the future, such as MRAM, it can also serve as very fast non-volatile flash memory.

[0025] The built-in memory within the controller is insufficient to store all the operational data required by the module. Therefore, some operational data is stored / mapped in the module's non-volatile memory (e.g., NAND). This is necessary to avoid data loss in the event of a sudden power outage. This non-volatile mass memory, such as NAND, is significantly slower to store and retrieve data compared to typical volatile / non-volatile execution memory (e.g., SRAM, DRAM, MRAM). This results in latency in the memory module's operation. For example, after power-on, all mass memory subsystems need to be reinitialized from NAND, which can take up to a second (e.g., eMMC, SD, SATAIO devices).

[0026] Please refer to Figure 5, where the components referring to Figure 2 are numbered accordingly. In Figures 5A and 5B, a portion 14G (e.g., DRAM) of the system RAM 14 is allocated for use by the mass memory module 20 (in the non-limiting embodiment described herein, it is a UFS memory module or a memory module). The host device 10 includes an application processor that may specifically be a CPU 12. A DRAM controller 11 for the DRAM 14 may be included in or coupled to the application processor 12. The aforementioned mass memory module 20 (e.g., UFS) and host controller 13 are also provided. The host controller 13 may specifically be a CPU 12, or may specifically be a separate device. The mass memory module (MMM) 20 (also referred to herein as a memory module, MM, 20) may be connected to the host device via an interface 22a, for example via a bus (e.g., the mass storage bus 18 shown in Figure 2). The memory module 20 may be part of the host device 10 as shown in FIG5a, or it may be a separate device as shown in FIG2.

[0027] Furthermore, the memory module 20 may include a non-volatile memory (e.g., NAND) 26 (or a large amount of memory) and a memory controller 22 with SRAM 24, a portion 26A of the non-volatile memory being allocated for use by the memory controller. For the purposes of this invention, the SRAM 24 and a portion 14G of the system DRAM 14 may be considered as an extended random access memory. It should be noted that an execution memory 24 of the memory controller 22 and / or the host system memory 14 may be a non-volatile memory, such as MRAM, PCRAM, and / or RRAM.

[0028] Figure 5B shows that the system DRAM 14 stores an operating system (OS) 14a and applications 14b. The system DRAM 14 also typically stores a file system cache 14c associated with the file system (part of the operating system (OS)). In the embodiment of Figure 5B, a portion of the system DRAM 14 is allocated to store an access serial number 14F. This DRAM portion 14G is also included and allocated for use by the memory module 20, and operational state data can be moved therein for use by the memory module 20.

[0029] The jointly assigned U.S. Patent Application No. 12 / 455,763 further describes enabling the memory module to store or retrieve data from the system DRAM (see, for example, Figures 3-4 above). This can be further utilized in the embodiments described herein to enable the mass storage memory module to, for example, store its state in the system DRAM, then enter sleep / shutdown mode, and quickly read back the previous state upon wake-up / power-on. In a managed NAND environment, such storage and retrieval of the operating state can be handled by the mass storage memory module 20 itself, particularly by the memory module controller 22, rather than by the host device 10, which knows what data needs to be stored and which part of the operating phase is lossy (e.g., during a power outage).

[0030] This invention proposes a novel method and apparatus for managing / configuring storage of operational state data for operating the memory module controller to extended random access memory (ERRAM) within various operating modes / conditions of the memory module 20 and the host system memory (e.g., the DRAM 14). The ERAM is contained within a memory module and the host system memory (e.g., the DRAM 14). Essentially, the memory module controller functions as the master controller for data transfer described herein. The operational state data generally includes one or more status information, a logic-to-physical (L2P) mapping table, and register settings.

[0031] Upon waking from a power-off or sleep state, the memory module controller can read at least a portion of the operating state data from the extended random access memory and / or a non-volatile mass memory to restore an operating state of the memory module controller. This reading can be based on the settings of the mass memory module, or on an instruction or instruction attribute from the host device that can overwrite the settings of the mass memory module. Alternatively, the settings can overwrite an instruction or attribute from the host device.

[0032] The settings for this large memory module can be either externally visible register settings (e.g., DRAM disabled / enabled access) or internal settings visible only to the memory module controller, such as which source (extended random access memory or flash memory) is the most efficient for loading the operation status data.

[0033] It should also be noted that instructions / attributes from the host (during the initialization phase) can overwrite the internal settings of the aforementioned mass memory module, for example, by denying access to the DRAM in the host device (in a data-critical situation), or the instruction may indicate that the mass memory module can be freely initialized from any source.

[0034] Furthermore, the operational status data can be divided into at least high-priority data (e.g., at least status information and possibly some L2L mapping tables) and low-priority data (e.g., register settings), with the high-priority data stored in the DRAM portion 14G of the extended random access memory. However, more than two priority levels can also be used to classify the operational status data; for example, the lowest priority data can be stored in the non-volatile memory portion 26A.

[0035] The basic principle behind this data transfer is based on utilizing fast extended random access memory (RAM) within both the memory module 20 and the host system memory (DRAM portion 14G) of the host device 10, exceeding the relatively slow non-volatile memory 26 as much as possible. This provides advantages in terms of rapid wake-up and power saving, even when the memory module can be turned off more frequently.

[0036] Figure 6 shows a logic flowchart of a further exemplary embodiment of the invention described herein, illustrating an operating method and the execution result of computer program instructions embodied in a computer-readable memory. It should be noted that the order of steps shown in Figure 6 is not absolutely necessary, and in principle, various steps other than those shown can be executed. Some steps may be skipped, different steps may be added or replaced, or selected steps or groups of steps may be executed in a separate application.

[0037] In the method according to the exemplary embodiments shown in FIG6, a memory module controller (MMCO), such as memory module controller 22, in the first step 70 dynamically manages / configures storage for operating MMCO state data to one or more of the following: an extended random access memory (ERAM) contained in both the memory module (MM) 20 (e.g., SRAM 24) and a host system memory (or system memory, SM) 14 (e.g., a dedicated portion 14G), and an ERAM contained in a non-volatile memory (e.g., a dedicated portion 26A of NAND memory 26 in MM 20). For example, if both the MM and SM are enabled to operate under normal conditions, the storage can be configured according to predefined rules. Important (high-priority) data, such as status information, and all or part of the logic-to-entity (L2P) mapping table, can be stored (written) in the DRAM portion 14G of the ERAM, while lower-priority data is stored in the SRAM portion 24 of the ERAM. However, the lowest-priority data (such as register settings) is stored in non-volatile memory 26 (e.g., portion 26A). Some high-priority data of the operational status can be stored in the non-volatile memory 26 (and possibly in the SRAM 22) as a copy of the data stored in the DRAM portion 14G. Moreover, the storage arrangement of both MM 20 and SM 14 can be automatically configured using a predetermined preset value by MMCO 22.

[0038] In addition, the flowchart in Figure 6 shows three scenarios that could trigger the reconfiguration of the storage arrangement established in step 70 of MMCO 22.

[0039] In one of the schemes, the memory module 20 in step 71 is deactivated, for example, by entering power-off or sleep mode. In other words, the memory module can receive at least one of the following indications: a power-off indication or a sleep / hibernation mode command / state change from the host device, or automatically entering sleep / hibernation mode after some defined timeout within the memory module.

[0040] In the next step 72, the MMCO reconfigures the storage operation status data into the SM (DRAM portion 14G) and possibly into the non-volatile memory (NAND 26) of MM 20. For example, if possible, the MMCO 20 can add (write) additional operation status data to (e.g., to the maximum capacity of the DRAM portion 14G) and further back up (copy) the high-priority data in the non-volatile memory. Additionally, low-priority data, such as those set by a register, which are not stored in the DRAM portion 14G, can be stored in the non-volatile memory portion 26A. Step 72 can be automatically executed by the MMCO 22 according to a predefined procedure based on the situation described in step 71.

[0041] In the next step 73, the MM system is enabled (power on / wake up).

[0042] In the next step 74, the MMCO reads at least the operating state data stored in the DRAM portion 14G (during initialization) to restore the operating state of the MMCO 22. Additionally, the information stored in the non-volatile memory portion NAND 26A as described in step 72 may be used to restore the operating state of the MMCO 22.

[0043] In another embodiment, MMCO 22 within step 75 determines (e.g., by receiving an instruction from the host device or an attribute contained within the instruction) that the SM (DRAM portion 14G) of the host device 10 is unusable and / or disabled, and / or contains data stored in the DRAM portion 14G.

[0044] Next, in the next step 76, MMCO 22 can store 14G of operational state data from the DRAM portion into the SRAM 22 of the non-volatile memory 26A and / or MM 20 before the SM in the host device becomes unusable / disabled. If the operational state data stored in the SM is compromised, MMCO 22 can then recover / reconstruct the necessary information from the non-volatile memory (NAND 26) when the data in the SRAM 22 becomes unusable.

[0045] In the next step 77, the SM system within the host device is activated (sending a signal to the power-on / wake-up of MM 20).

[0046] In the next step 78, MMCO 22 reconfigures at least the storage of important operational status data to the storage within SM (DRAM 14), as described in step 70.

[0047] However, in another approach, both memory modules 20 and SM 14 in step 79 are deactivated, for example, by powering off or putting them to sleep. For instance, the host device could issue a command to power off completely. In the next step 80, the MMCO reconfigures the storage of the operational state data into the non-volatile memory (NAND 26) of the MM.

[0048] In the next step 81, both memory module 20 and SM 14 within the host device are enabled (power-on / wake-up). In the next step 82, the MMCO uses the information stored in the non-volatile memory (NAND 26) of the MM to configure the restoration and storage of the operating state data as in step 70. It should be further noted that this step may include a large number of memory modules initialized using all or selected of the operating state data stored in the non-volatile memory in step 80.

[0049] It should be noted that the read and write steps (e.g., steps 72, 76, 80, 74, 78, 82) can be performed by MMCO 22 based on instructions from host device 10 (or attributes within those instructions) and / or by using its own judgment.

[0050] Figures 7a-7b and 8 further illustrate different embodiments disclosed in the flowchart of Figure 6. For example, Figures 7a and 7b show examples of memory mapping of MMCO 22 in MM 20 when the use of system resources (e.g., a portion of DRAM 14G) is disabled (Figure 7a) and when the use of system resources is enabled (Figure 7b).

[0051] Figure 7a (when the DRAM section 14G is inaccessible / disabled) provides operational details of one of the volatile memory sections, such as the NAND section 26A and SRAM 24 identified in Figure 5. As shown in Figure 7a, the NAND section 26A shown on the left can store a small boot segment from which the first part of a code is loaded to initialize the memory module controller 22. The SRAM 24 provides runtime execution memory, which stores the necessary code to run MM 20 and at least a portion of metadata such as P2L mapping data. In addition, if there is not enough SRAM 24 to store the entire P2L mapping table, the NAND section 26A shown on the right can be paging memory for MMCO 22; furthermore, the NAND section 26A can be a permanent storage section for temporary registers and P2L mapping tables.

[0052] Figure 7b (with DRAM 14G accessible / enabled) provides operational details for the NAND portion 26A, SRAM 24, and DRAM portion 14G identified in Figure 5, where SRAM 24 and DRAM 14G form the extended random access memory. As shown in Figure 7b, the NAND portion 26A on the left can store a small boot segment from which the first part of a code is loaded to initialize the memory controller. Additionally, NAND portion 26A can store information that facilitates reinitialization after a power cycle. SRAM 24 (as shown in Figure 7a) provides runtime execution memory, which stores the necessary code for running MM 20 and at least the metadata portion such as P2L mapping data. The NAND portion 26A on the right can also be the main scratchpad and permanent storage portion of the P2L mapping table. The main difference from Figure 7a is that the enabled state of the DRAM portion 14G becomes an extended area of ​​SRAM 24 (forming the extended random access memory), used to store runtime data such as status information and P2L mapping table, especially the data of MMCO 22 that needs to be reinitialized as quickly as possible after the power cycle.

[0053] It should be noted that the regions 26A shown in Figures 7a and 7b can also be adjacent to each other. The left side can also be implemented, at least partially, by some boot ROM embedded in the MMCO. It should be further noted that the memory mapping of the MMCO can also be a virtual mapping rather than a physical one (as shown in Figures 7a and 7b).

[0054] Figure 8 shows another embodiment of the flowchart shown in Figure 6, which associates the operation of MMCO 22 with an instruction (or an attribute within that instruction) from the host device 10. If the host device 10 (e.g., its CPU 12) knows that the data in the DRAM portion 14G is compromised, it can send an instruction to MM 20 to refuse reading from the host system memory DRAM portion 14G, thus forcing MMCO 22 to read any settings in MM 20 from the NAND portion 26A, which is similar to non-volatile memory. The operating state of MMCO 22 is then read from the NAND portion 26A.

[0055] If the host device 10 (CPU 12) does not impose any restrictions on reading from the DRAM portion 14G, the operating state of MMCO 22 will then be read from the DRAM portion 14G, and possibly from the NAND portion 26A (for low priority data).

[0056] It should be noted that the instructions / attributes sent by the host device 10 to the memory module 20 (e.g., via interface 22a shown in FIG. 5a) can have different execution levels on the memory module controller 22. For example, an instruction to refuse reading from the host system memory (e.g., from the DRAM portion 14G in FIG. 8) can have a high execution level. Similarly, another instruction or instruction attribute in the host device that prohibits additional information related to the operation status data from being written to the host system memory (e.g., there is no available spare space) can also be a high execution level instruction that cannot be overwritten by the MMCO 22. An example of a low execution level instruction / attribute executed by the host device could be leaving the decision to the MMCO when the host device enables (or does not disable) the use of 14G. A low execution instruction / attribute could also be an indication that the host device is powered off, allowing the MMCO to decide whether to perform a read / write operation with that status data.

[0057] Figure 9 shows a non-limiting embodiment of a host device 10 used with the mass storage memory device 20. Referring to Figure 6, the mass storage memory device is simply a memory card 20. The mass storage memory device 20 may be removable or may be embedded within the device 10. In this exemplary embodiment, the host device 10 is specifically a user device (UE) and is shown in both top (left) and cross-sectional (right) views. In Figure 9, the host device (UE) 10 has a graphical display interface 120 and a user interface 122, which is shown as a keyboard, but is also understood to include touch screen technology on the graphical display interface 120 and voice recognition technology on a microphone 124. A power actuator 126 controls devices that can be turned on or off by the user. The exemplary UE 10 may have a camera 128, which is shown facing forward (e.g., for video calls), but may alternatively or otherwise face backward (e.g., for capturing images and videos for local storage). The camera 128 is controlled by a shutter actuator 30 and selectively controlled by a zoom actuator 32, which can selectively function as a sound adjustment function for the speaker 34 when the camera 128 is not in active mode.

[0058] For example, image data captured by the camera 128 can be stored in the mass storage memory 20 under the control of a camera application, thus benefiting from the use of these embodiments of the present invention. Another example is that audio data captured by the microphone 124 can be stored in the mass storage memory 20 under the control of an audio application, thus also benefiting from the use of these embodiments of the present invention.

[0059] In the cross-sectional view of Figure 9, multiple transmit / receive antennas 36, typically used for cellular communications, are visible. These antennas 36 may be multi-band for use with other wireless devices in the UE. The operable ground planes for these antennas 36 are shaded to span the entire space enclosed by the UE housing, although in some embodiments the ground planes may be confined to a smaller area, such as on a printed circuit board on which the power chip 38 is formed. The power chip 38 controls power amplification of the channels transmitted to and / or across these antennas, and amplifies the received signals, which are transmitted simultaneously on these channels. The power chip 38 outputs the amplified received signal to a radio frequency (RF) chip 40, which demodulates and down-converts the signal for baseband processing. A baseband (BB) chip 42 detects the signal converted into a bitstream and finally decoded. Similar processing occurs in reverse for use with signals generated and transmitted by the host device 10.

[0060] Signals entering and from the camera 128 can be encoded and decoded by an image / video processor 44. A separate audio processor 46 may also be present to control signals entering and from the speaker 34 and microphone 124. The graphics display interface 120 is updated from a frame memory 48 controlled by a user interface chip 50, which can process signals transmitted to and from the display interface 20, and / or additionally process user input information from the keyboard 22 and other locations.

[0061] Some embodiments of the UE 10 may also include one or more auxiliary wireless devices, such as a wireless local area network radio device WLAN 37 and a Bluetooth radio device 39, which may incorporate an antenna on-chip or be coupled to an antenna off-chip. Various memory architectures are distributed throughout the device, including, for example, random access memory (RAM) of system DRAM 14, read-only memory (ROM) 45, and, in some embodiments, removable memory (such as the memory card 20 illustrated therein, which can store various programs and data). All these components within the UE 10 are typically powered by a portable power source, such as a battery 49.

[0062] If these processors 38, 40, 42, 44, 46, and 50 are specifically implemented as separate entities within UE 10, they can operate in a subordinate relationship to the main processor (CPU) 12, which then controls them. Some embodiments may be configured across the various chips and memories illustrated, or within another processor incorporating some of the aforementioned functions, as shown in the embodiment of FIG9. Any or all of these various processors in FIG9 access one or more of these various memories, which may be on the chip with the processor or separate from the chip containing the processor. It should be noted that the various integrated circuits described above (e.g., chips 38, 40, 42, etc.) can be incorporated in even fewer quantities than described, and in the smallest possible case, can be physically embodied within a single chip.

[0063] In this exemplary embodiment, the CPU 12 of the UE 10 (the host device) operates together with the memory card 20 (mass storage memory device), as shown in Figures 5A, 5B and 5C, so that the memory card 20 can be expanded to use at least a portion of the system dynamic RAM 14 of the UE 10, as described above.

[0064] In general, various exemplary embodiments can be implemented on hardware or special-purpose circuitry, software, logic systems, or any combination thereof. For example, some embodiments can be implemented on hardware, while others can be implemented on firmware or software executable by a controller, microprocessor, or other computer device, although the invention is not limited thereto. Although various embodiments of the present invention may be shown and described as block diagrams, flowcharts, or other graphical representations, it is understood that such blocks, devices, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, special-purpose circuitry or logic systems, general-purpose hardware or controllers or other computing devices, or some combination thereof, as non-limiting embodiments.

[0065] Therefore, it should be understood that at least some of the exemplary embodiments of the present invention can be implemented in various elements, such as integrated circuit chips and modules, and that the exemplary embodiments of the present invention can be implemented on a device specifically an integrated circuit. The integrated circuit or circuit system may include circuitry (and possibly firmware) for embodying at least one or more of the following: a data processor or several data processors, a digital signal processor or several processors, baseband circuitry, and radio frequency circuitry, all of which are configurable and operate according to the exemplary embodiments of the present invention.

[0066] In view of the foregoing description, various modifications and improvements to the exemplary embodiments of the present invention will become apparent to those skilled in the art when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the non-limiting and exemplary scope of the present invention.

[0067] It should be noted that the terms "connection," "coupled," or any variation thereof refer to any connection or coupling between two or more elements, directly or indirectly, and include the presence of one or more intermediate elements between two elements that are "connected" or "coupled" together. Such coupling or connection between elements can be physical, logical, or a combination thereof. Two elements as used herein can be considered "connected" or "coupled" together by the use of one or more wires, cables, and / or printed electrical connections, or by the use of electromagnetic energy, such as electromagnetic energy wavelengths having wavelengths in the radio frequency, microwave, and optical (both visible and invisible) domains, as examples that are not limiting or exhaustive.

[0068] It should be noted that the various non-limiting embodiments described herein can be used alone, in combination, or selectively combined for a particular application.

[0069] Furthermore, some of the features in the various features of the above non-limiting embodiments can be used and benefited from without the corresponding use of other described features. Therefore, the above description should be regarded only as an illustration of the principles, teachings, and exemplary embodiments of the invention, and not as a limitation thereof.

[0070] It is understood that the above configuration is merely an application description of the principles of the present invention. Various modifications and alternative configurations can be devised by those skilled in the art without departing from the scope of the present invention, and these appendices are intended to cover such modifications and configurations.

[0071] 10: Host device / host system / host 12: Central Processing Unit / Application Processor 13: Host Controller 14: Random Access Memory / Host System Memory 14a: Operating System (OS) 14b: Application 14c: File System Cache Memory 14F: Access String 14G: Part of RAM 16: Mass Storage Bus Interface 17: Internal Busbar 18: Mass Storage Memory Bus 20: Mass storage memory / Mass storage module / Mass storage device 22: Controller / Memory Controller / Keyboard 22a: Interface 24: Volatile Random Access Memory 24A: Metadata 26: Non-volatile mass memory / NAND (mass memory) 26A: Part of the file system / non-volatile memory 27: Internal busbar 28: Mass Storage Bus Interface 30: Shutter actuator 32: Zoom actuator 34: Loudspeaker 36: Antenna 37:WLAN 38: Power supply chip 39: Bluetooth wireless equipment 40: Radio Frequency (RF) Chips 42: Baseband (BB) chip 44: Image / Video Processor 45: Read-only ROM 46: Audio Processor 48: Frame Memory 49: Battery 50: User Interface Chip 70: Steps 71: Steps 72: Steps 73: Steps 74: Steps 75: Steps 76: Steps 77: Steps 78: Steps 79: Steps 80: Steps 81: Steps 82: Steps 120: Graphical Display Interface 122: User Interface 124: Microphone 126: Electric actuator 128: Camera

Claims

1. A memory module comprising: a non-volatile memory; and a memory module controller configured to: receive an instruction to automatically enter a dormant mode after a defined timeout in the memory module, wherein the defined timeout is a period of time after which the memory module automatically enters the dormant mode; and, at least in part based on the received instruction, write operational state data into a portion of a random access memory (RAM) allocated to a host device of the memory module.

2. The memory module of request item 1, wherein the memory module controller is further configured to: automatically enter the hibernation mode in response to the received instruction, and write the operation status data into the non-volatile memory.

3. The memory module of request item 1, wherein the memory module controller is further configured to: automatically enter the hibernation mode in response to the received instruction, write low-priority data to the non-volatile memory or write high-priority data to that portion of the RAM.

4. The memory module as requested in item 3, wherein the low priority data includes register settings.

5. The memory module of claim 3, wherein the memory module controller is further configured to: recognize that the memory module has been woken up; and at least in part based on the memory module being woken up, read the low priority data from the non-volatile memory.

6. The memory module of claim 1, wherein the memory module controller is further configured to: recognize that the memory module has been woken up; and at least in part based on the memory module being woken up, read the operation status data from the portion of the RAM of the host device.

7. The memory module of request item 6, wherein the memory module controller is further configured to send a RAM READ instruction to read the operation status data from the portion of the RAM of the host device.

8. The memory module of request item 1, wherein the memory module controller is further configured to: send an instruction to the host device to deallocate one portion of the RAM of the host device.

9. The memory module of claim 1, wherein the memory module controller is further configured to send a RAM WRITE instruction to store the operating status data into the portion of the RAM of the host device.

10. The memory module of claim 1 further includes a setting, wherein the memory module controller is further configured to: send an instruction to the host device to request access to the portion of the RAM of the host device via the memory module; and update the setting of the memory module to indicate that access to the portion of the RAM of the host device is enabled.

11. The memory module of request item 1, wherein the operational state data includes a logical-to-physical mapping table.

12. A method comprising: The memory module controller of a memory module receives an instruction to automatically enter a sleep mode after a defined timeout, wherein the defined timeout is a period of time after which the memory module automatically enters the sleep mode; and at least in part based on the received instruction, the memory module controller writes operation status data into a portion of a random access memory (RAM) allocated to a host device of the memory module.

13. The method of claim 12, further comprising: In response to the received instruction, the system automatically enters the hibernation mode and writes the operation status data into one of the non-volatile memory modules of the memory module.

14. The method of claim 12, further comprising: The memory module controller identifies that the memory module has been activated; And by means of the memory module controller and at least partly based on the fact that the memory module has been woken up, the operation status data is read from the part of the RAM of the host device.

15. The method of claim 14, wherein reading the operation status data from the portion of the RAM of the host device further comprises: The memory module controller sends a RAM READ instruction to the host device.

16. The method of request item 12, wherein the operational status data includes a logical-to-entity mapping table.

17. The method of claim 12, further comprising: The memory module controller sends a command to the host device to request access to that portion of the RAM of the host device via the memory module; And by means of the memory module controller, update one of the settings of the memory module to indicate that access to that portion of the RAM of the host device has been enabled.

18. A host device comprising: A random access memory (RAM); and a processor, wherein the host device is configured to: allocate a portion of the RAM to a memory module; receive an instruction from a memory module controller of the memory module and in response to the memory module to automatically enter a sleep mode after a defined timeout in the memory module; receive operation status data to store in the portion of the RAM, wherein the defined timeout is a period of time after which the memory module automatically enters the sleep mode; and write the operation status data into the portion of the RAM.

19. The host device of claim 18, wherein the host device is further configured to: receive a RAM READ instruction from the memory module controller; read the operation status data from the portion of the RAM in response to the RAM READ instruction; and send the operation status data to the memory module in response to the RAM READ instruction.

20. The host device of claim 18, wherein the host device is further configured to: receive an instruction from the memory module controller to request access to the portion of the RAM of the host device via the memory module, wherein the allocation of the portion of the RAM to the memory module is at least in part based on the instruction requesting access.

Images