Method and apparatus for distributing code and data storage between volatile and non-volatile memory

Abstract

Method for using volatile and non-volatile memory, the method comprising: Storing one or more static code segments of an executable application in a non-volatile storage device; Storing one or more static data segments of the application in the non-volatile storage device; Storing one or more volatile data segments of the application in a volatile storage device; Assigning an address mapping table having at least a first address pointer for pointing to each of the one or more static code segments, at least a second address pointer for pointing to each of the one or more static data segments, and at least a third address pointer for pointing to each of the one or more volatile data segments; initially storing all data segments of the software application in the non-volatile storage device, for a given data segment within all of the data segments; Transferring the given data segment to the volatile storage device when a rewrite request for the given data segment is received during execution of the application; and Updating the address mapping table using the respective address pointer to a memory section allocated in the volatile memory device.

Description

FIELD OF THE INVENTION

[0001] The invention relates to allocating a combination of volatile memory and non-volatile memory for storing code and data sections of a software application. DESCRIPTION OF THE STATE OF THE ART

[0002] Memory performance and capacity requirements are becoming increasingly stringent across many aspects of the computing industry. Furthermore, memory power requirements and storage costs have become a significant component of the total power and cost of a given computing system, which can range from a smartphone to a server. Memory and storage subsystems can increase or decrease the overall performance of a computing device depending on design details. Because of the universal desirability of having computing devices that perform faster, consume less power, and cost less, a wide variety of memory and storage subsystem designs exist that attempt to maximize end-user perceived performance while minimizing cost and power consumption.

[0003] From "Benavides," we know how to distribute data segments with different encodings across different memory types. From "Xie," we know how to use phase-change memory as non-volatile storage.

[0004] Current operating systems provide an application programming interface (API) to allow applications and drivers to request memory from paged and non-paged pools. Non-paged pools are typically used for data that does not require paging to a mass storage device (e.g., pages expected to be accessed by the hardware during application execution). Since all allocated pages are currently accessed when they are in DRAM, no additional information is required at page allocation time regarding whether the data stored in an allocated buffer is expected to be used for read-only or, conversely, for both read and write purposes.

[0005] The invention aims to provide a method that allows more efficient access to data segments in different memory types. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The following description and the accompanying drawings are used to illustrate embodiments of the invention. They show: Fig. 1 illustrates an embodiment of a memory arrangement that enables a computer system to use a hybrid memory structure for code and data storage for processors as well as for embedded systems. Fig. 2 a description of an embodiment of volatile and non-volatile memory spaces when using a hybrid software application code and data storage system. Fig. 3 is a flow diagram of an embodiment of a method for allocating volatile and non-volatile memory for code and data portions of a software application. Fig. 4 is an illustration of a computer system including an embedded controller having direct access to an internal PCMS device in an I / O subsystem. Fig. 5 a description of an embodiment of volatile and non-volatile memory spaces in an I / O subsystem when using a hybrid firmware code and data storage system. DETAILED DESCRIPTION

[0007] Many embodiments described below solve code and data usage challenges introduced in the memory and storage subsystems of a computing device by partitioning the performance and capacity requirements between different memory technologies. The focus of this approach is on providing performance with a relatively small amount of higher-speed memory, such as dynamic random access memory (DRAM), while implementing the bulk of the system memory using significantly cheaper and denser non-volatile memory.Various embodiments described below define platform configurations that enable hierarchical memory subsystem organizations for the use of a particular type of non-volatile memory, specifically referred to as non-volatile random access memory (NVRAM), to augment the volatile memory by one or more graphics processors in a computing device. The use of NVRAM in the memory hierarchy additionally enables non-volatile mass storage implementations as replacements for standard mass storage drives.

[0008] Fig. 1 illustrates one embodiment of a memory arrangement that enables a computer system to use a hybrid memory structure for code and data storage for processors as well as for embedded systems.

[0009] A central processing unit (CPU), graphics processing unit (GPU), and an embedded processor may be provided with access to both volatile and non-volatile forms of memory according to various embodiments. The CPU and GPU may also be referred to as "processors" throughout this document. These different terms will be used.

[0010] Fig. 1 shows a number of logic units that can be located on the same or different semiconductor dies or the same or different semiconductor packages. The logic units in Fig. 1 include a CPU having one or more cores and a cache, a GPU also having one or more cores and a cache, a memory subsystem, and an I / O subsystem. These units are separated by dashed lines to indicate the possibility that each of these logic blocks may or may not be located in the same semiconductor die and / or package.

[0011] Now referring to the detailed elements of Fig. 1, a CPU 100 is present. This CPU includes one or more cores 102. Although not shown, each core may internally include one or more instruction / data caches, execution units, prefetch buffers, instruction queues, branch address calculation units, instruction decoders, floating point units, retirement units, etc. In other embodiments not shown, the system may include multiple CPUs, each with its own set of logic units implemented in Fig. 1 are shown.

[0012] CPU 100 includes at least one lower-level cache, such as cache 104. This may be a general-purpose cache capable of storing a significant amount of data retrieved from locations in volatile memory 106 and / or NVRAM 108. In various embodiments, cache 104 may be shared by all cores, or each core may have its own lower-level cache.

[0013] The CPU 100 may also include additional logic, not shown, that operates at least the core(s) 102. In some embodiments, this additional logic may be referred to as a home agent. The home agent may, for example, include a power control unit (PCU). The PCU may include logic and components necessary for regulating the power state of the core(s) 102, among other tasks.

[0014] According to various embodiments, the computer system in Fig. 1 additionally includes a GPU 110. The GPU 110 may also include one or more cores 112. Each core may include one or more execution units and one or more instruction and data caches used to feed information to be processed into the execution units. In addition, the GPU 110 may include other graphics logic units not included in Fig. 1, such as, among others, one or more vertex processing units, rasterization processing units, media processing units, and codecs. For simplicity, the specific logic within core(s) 112, as well as the other logic units within GPU 110 associated with graphics, are not shown.

[0015] One or more lower-level caches may also be present within GPU 110, such as cache 114. This cache may be used as a general-purpose cache or a cache specific to one or more particular types of graphics data (e.g., vertex data). Other lower-level caches are not shown, although in some embodiments, multiple caches, such as cache 114, are present within GPU 110.

[0016] According to many embodiments, a display controller 116 is communicatively coupled to the GPU 110. The display controller 116 receives information to be displayed on a display device (e.g., a monitor, a television, a projector, etc.). In many embodiments, the display controller 116 specifically receives frame buffers. Each frame buffer consists of an image comprising pixels, which is then interpreted by the display controller, and the image is fed to the display device for viewing. Depending on the refresh rate of the display device, frame buffers may be fed to the display controller 116 a certain number of times per second. For example, a refresh rate of 60 Hz uses 60 frames (frame buffers containing image information) per second.Different display devices may use higher frequency refresh rates and simply resample the same frame buffer two or more times before using a new frame buffer with information to be displayed.

[0017] A memory subsystem 118 is also included in Fig. 1. A volatile memory controller 120 is present, which can be used to provide access to the volatile memory 106. The volatile memory controller 120, which in various embodiments is integrated into the CPU package or separate from the CPU package, can receive a memory access request from a CPU core 102 or a GPU core 112 and direct that request to the volatile memory 106. Similarly, a non-volatile (NV) memory controller 122 can receive a memory access request from a CPU core 102 or a GPU core 112 and direct that request to the NVRAM 108. In some embodiments, the volatile memory controller 120 and the non-volatile memory controller 122 are integrated into a large memory controller.In other embodiments, they are separate control devices.

[0018] In many embodiments, an input / output (I / O) subsystem 124 is included in the system in Fig. 1 to communicate with I / O devices, such as I / O device(s) 126. Within I / O subsystem 124, one or more I / O adapters 128 are present to translate the host communication protocol used within CPU 100 into a protocol compatible with particular I / O devices. Some of the protocols that adapters may use for translation include Peripheral Component Interconnect (PCI)-Express (PCI-E) 3.0; Universal Serial Bus (USB) 3.0; Serial Advanced Technology Attachment (SATA) 3.0; Small Computer System Interface (SCSI) Ultra-640; and Institute of Electrical and Electronics Engineers (IEEE) 1394 "Firewire," among others.

[0019] Additionally, one or more wireless protocol I / O adapters may be present. Examples of wireless protocols include personal area networks, such as IEEE 802.15 and Bluetooth 4.0; wireless local area networks, such as IEEE 802.11-based wireless protocols; and cellular protocols.

[0020] A Basic Input / Basic Output System (BIOS) flash device 130 may also be present in the system to provide a set of boot commands when the system is powered on or rebooted. For the BIOS flash device 130, some of the protocols that the I / O adapters 128 can translate may include, among others, Serial Peripheral Interface (SPI) and Microwire.

[0021] Referring again to the NVRAM 108, an overview of the NVRAM is provided below. 1. Overview of Non-Volatile Random Access Memory

[0022] Many technological choices exist for NVRAM, including PCM, Phase Change Memory and Switch (PCMS) (the latter being a more specific implementation of the former), Byte-Addressable Persistent Memory (BPRAM), Storage Class Memory (SCM), General Purpose Memory, Ge2Sb2Te5, Programmable Metallization Cell (PMC), Resistive Memory (RRAM) (amorphous) RESET cell, (crystalline) SET cell, PCME, Ovshinsky memory, ferroelectric memory (also known as polymer memory and poly(N-vinylcarbazole)), ferromagnetic memory (also known as spintronics, SPRAM (Spin-transfer Torque RAM)), STRAM (Spin Tunneling RAM), magnetoresistive memory, magnetic memory, Magnetic Random Access Memory (MRAM), and Semiconductor-Oxide-Nitride-Oxide-Semiconductor (SONOS, also known as dielectric memory).

[0023] The NVRAM has the following properties: It retains its contents even when the power is turned off, similar to the FLASH memory used in solid state disks (SSD), and unlike SRAM and DRAM, which are volatile;

[0024] It has lower overall power consumption than volatile memories such as SRAM and DRAM;

[0025] It has random access similar to SRAM and DRAM (also known as random addressable); it is rewritable and erasable at a lower granularity level (e.g., byte level) than FLASH found in SSDs (which can only be rewritten and erased one "block" at a time—at least 64 KB for NOR FLASH and 16 KB for NAND FLASH);

[0026] It is used as a system memory and is assigned all or part of the system memory address space;

[0027] It is capable of being coupled to the CPU via a bus (also interchangeably referred to as an interconnect or link) using a transaction protocol (a protocol that supports transaction identifiers (IDs) to distinguish different transactions so that these transactions can be completed out of order), and provides access at a granularity level small enough to support the operation of NVRAM as system memory (e.g., cache line size, such as 64 or 128 bytes). For example, the bus / interconnect may be a memory bus (e.g., a Double Data Rate (DDR) bus, such as DDR3, DDR4, etc.) over which a transaction protocol is executed, as opposed to the non-transactional protocol normally used.As another example, the bus may be one over which a transaction protocol (a native transaction protocol) is normally executed, such as a PCI express (PCIE) bus, Desktop Management Interface (DMI) bus, or any other type of bus that uses a transaction protocol and a sufficiently small transaction payload size (e.g., cache line size, such as 64 or 128 bytes); and.

[0028] It also has one or more of the following characteristics: It has a faster write speed than non-volatile memory / storage technologies such as FLASH; It has very high read speeds (faster than FLASH and close to or equivalent to DRAM read speeds); It is directly writable (instead of requiring erasure (overwriting with 1s) before writing data, like FLASH memory used in SSDs); and / or It allows a greater number of write operations before failure (more than Boot ROM and FLASH used in SSDs).

[0029] As previously mentioned, unlike FLASH memory, which requires rewriting and erasing an entire "block" at a time, the level of granularity at which NVRAM is accessed in any given implementation may depend on the particular memory controller and the particular memory bus or other type of bus to which the NVRAM is coupled. For example, in some embodiments where NVRAM is used as system memory, NVRAM may be accessed at the granularity of a cache line (e.g., a 64-byte or 128-byte cache line), despite its inherent ability to be accessed at the granularity of one byte, since the cache line is the level at which the memory subsystem accesses memory.Therefore, when NVRAM is deployed within a memory subsystem, it can be accessed at the same granularity level as DRAM used in the same memory subsystem. However, the granularity level of access to NVRAM by the memory controller and the memory bus or other type of bus is smaller than the block size used by Flash and the access size of the I / O subsystem controller and bus.

[0030] NVRAM may also incorporate wear-leveling algorithms to account for the fact that memory cells begin to wear out after a number of write accesses, especially when a significant number of write operations may occur, such as in a system memory implementation. Since blocks with high cycle counts are most likely to experience such wear, wear-leveling distributes write operations across the removed memory cells by swapping addresses of blocks with high cycle counts with blocks that have low cycle counts. It should be noted that most of the address swapping is typically transparent to application programs, being handled by hardware, lower-level software (e.g., a lower-level driver or operating system), or a combination of both.

[0031] NVRAM can be distinguished from other instruction and data storage technologies in terms of its properties and / or its application in the memory / storage hierarchy. For example, NVRAM differs from: Static Random Access Memory (SRAM), which can be used for internal processor level 0 and level 1 caches dedicated to each core within a processor, and lower-level caches (LLC) shared by cores within a processor;

[0032] Dynamic Random Access Memory (DRAM) configured as a cache within a processor die (e.g., on the same die as the processor), as one or more caches outside a processor die (e.g., in the same or a different package as the processor die), or general system memory outside the processor package; and

[0033] FLASH memory / magnetic disk / optical disk used as mass storage; and

[0034] Memory, such as FLASH memory or other read-only memory (ROM), used as firmware storage (which may be referred to as boot ROM, BIOS flash, and / or TPM flash).

[0035] In Fig. 1, NVRAM 108 can be used as instruction and data memory that is directly addressable by a CPU 100 and, unlike FLASH / magnetic disk / optical disk applied as mass storage, is capable of sufficiently keeping pace with the CPU 100. Direct addressability refers to a processor, such as a CPU or GPU, being able to send memory requests to the NVRAM as if it were a standard DRAM (e.g., through standard memory store and load instructions). Furthermore, as discussed previously and described in detail below, NVRAM 108 can be located on a memory bus and communicate directly with a memory controller, which in turn communicates directly with the processor 100.

[0036] NVRAM 108 can be combined with other instruction and data storage technologies (e.g., DRAM) to form hybrid memories (also known as co-location of PCM and DRAM; first-level and second-level memory; FLAM (FLASH and DRAM)). It should be noted that at least some of the foregoing technologies, including PCM / PCMS, can be used for mass storage instead of or in addition to system memory, and they do not need to be randomly accessed, byte-addressable, or directly addressable by the processor when applied in this manner.

[0037] For ease of explanation, most of the remainder of the application concerns "NVRAM" or, more specifically, "PCM" or "PCMS" as the technology choice for the non-volatile memory. As such, the terms NVRAM, PCM, and PCMS may be used interchangeably in the following discussion. However, it should be understood that, as previously discussed, different technologies may also be used. 2. Overview of volatile memory

[0038] The "volatile memory" 106 is an intermediate level of memory configured in conjunction with the NVRAM 108 that has a lower read / write access latency and / or a more symmetric read / write access latency (i.e., read times roughly equivalent to write times) compared to the NVRAM 108. In some embodiments, the volatile memory 106 has a significantly lower write latency than the NVRAM 108 but a similar (e.g., slightly lower or equal) read latency; for example, the volatile memory 106 may be a volatile memory, such as Volatile Random Access Memory (VRAM), and may include DRAM or other high-speed capacitor-based memory. It should be noted, however, that the underlying principles of the invention are not limited to these specific memory types.Additionally, the volatile memory 106 may have a relatively lower density and / or may be more expensive to manufacture than the NVRAM 108.

[0039] In some embodiments, volatile memory 106 is configured between NVRAM 108 and the internal processor caches. In some embodiments described below, volatile memory 106 is used to mask the performance and / or usage limitations of NVRAM 108, including read / write latency limitations and memory degradation limitations. In these embodiments, the combination of volatile memory 106 and NVRAM 108 operates at a performance level that approaches, is equivalent to, or exceeds a system using only DRAM as system memory.

[0040] In various embodiments, the memory 106 may be located on the processor die, located outside the processor die on a separate die located on the CPU package, located outside the CPU package with a high-bandwidth connection to the CPU package, for example, on a memory dual in-line memory module (DIMM), a riser / mezzanine card, or a computer motherboard. In Fig. 1, the volatile memory 106 shown is located outside the CPU housing. The volatile memory 106 may be communicatively coupled to the CPU 100 using a single or multiple high-bandwidth interconnects, such as DDR or other high-bandwidth transaction interconnects. Communicative coupling of devices means that they are coupled by an electrical, optical, wireless, or other form of connection or combination of connections to enable the passing of information in a reverse and forward direction between the coupled devices. In some embodiments, the coupling is direct, allowing information to be passed directly from the first device to the second, and possibly vice versa.In other embodiments, the coupling is indirect and requires that the information traverse one or more additional devices located along the route along which the information travels when transmitted between the two communicatively coupled devices in question. 3. Hybrid memory code and data storage for processors

[0041] According to many embodiments, a hybrid memory solution in a computing system is disclosed that combines DRAM and PCMS storage or another type of NVRAM and can be used to access both the code and data portions of a software application being executed. As previously mentioned, while other forms of NVRAM may be applicable to these solutions, the technical specifications of PCMS make it a candidate technology of quality for non-volatile memory / storage. Therefore, the examples shown use PCMS memory, although in other embodiments, a different form of NVRAM may be used.

[0042] In a computer system that includes a large amount of PCMS memory / storage, both software applications and an operating system running on the computer system can take advantage of the fast read capability of a PCMS device. These fast read operations can allow the software application and the operating system to execute code directly from the PCMS on the processor.

[0043] In many embodiments, the operating system executing on the computer system may be aware of the PCMS memory and will execute the operating system binaries directly from the physical PCMS address space. This execution differs from other forms of non-volatile memory, such as mass storage solutions, which instead require loading code (binaries) into volatile memory, such as DRAM, before the code is executed.

[0044] The operating system establishes an interface for the software application and any driver software executing on the operating system. According to many embodiments, the application and / or driver send requests to the operating system for buffers to store binary executable code that will not be modified during execution. The operating system then grants these buffers and provides pointers to them in the allocated memory address space of the software application and / or driver. Since the binaries in these buffers are not modified, there is generally an explicit designation provided by the software, driver, and / or operating system to make these buffers immutable.

[0045] The operating system running on the system can treat the PCMS memory as physical DRAM and map sections of the files that comprise the operating system and software applications into a memory management unit (MMU). Once located in the MMU, these file locations can be translated and stored similarly to entries in the translation lookaside buffer (TLB), and they can be addressed as if they were standard DRAM locations.From the logical address space of an operating system to a physical PCMS device address location, there may be multiple page walks, first from a logical address used by the operating system, to a Platform Physical Address (PPA) used by the underlying general purpose memory management hardware for the main DRAM memory, and finally to a direct physical PCMS device address. One or more address mapping tables 132 (also known as address indirection tables) may be present to accomplish this. In many embodiments, the address mapping tables 132 are stored in DRAM (the volatile memory 106).

[0046] In addition to binary code storage in PCMS, there are other sections of software application, driver, and operating system information that can be conveniently stored in the physical PCMS space. In particular, certain data sections (as opposed to code sections) of the software may also be storable in PCMS if that data is static or nearly static. Thus, in many embodiments, at least one bit designation is present per data element that indicates whether the particular data element to be stored is static or not. The data elements designated as static may be stored in static (i.e., immutable) buffers, while the data elements designated as non-static may be stored in volatile (i.e., mutable) buffers. This special designation per buffer allows the operating system to: • determine when to allocate a buffer in actual DRAM versus PCMS memory, allocating the buffer in DRAM if the buffer is designated as volatile and allocating it in PCMS if the buffer is designated as static. • When allocating a buffer in DRAM, the operating system can simply follow an old page allocation procedure. • When allocating a buffer in PCMS (ie, a buffer that does not require modification), the operating system can map physical PCMS device address space into its page tables to enable direct memory accesses to the PCMS device. • Optionally, the operating system can enforce the read-only properties of a buffer by setting read-only permissions for the PCMS buffer.

[0047] Fig. 2 describes an embodiment of volatile and non-volatile memory spaces when using a hybrid software application code and data storage system.

[0048] In Fig. 2, a DRAM memory space 200 (e.g., 4 GB of space) and an NVRAM memory space 202 (e.g., 64 GB of space) are present. Additional memory spaces, including a logical memory space where the operating system controls, may be present, but these are not shown for clarity. An operating system 204 is resident in the DRAM memory space 200 and executes on the CPU 100. In many embodiments, driver software 206 is also resident in the DRAM memory space 200 and executes on the CPU 100 in conjunction with the operating system 204. At some point during operation, the operating system 204 loads a software application 208 into the DRAM memory space 200. The load operation includes the operating system 204 reserving memory space for the software application 208.The reserved memory space includes space used to store the executable binary code ("Code") as well as space used to store any mutable data ("Data") that the software application 208 uses to execute.

[0049] As previously mentioned, according to many embodiments, the code is generally static because the binary files do not change during execution. On the other hand, the data may or may not change depending on a data type. For example, static data (e.g., constants) will not change, but volatile data (e.g., a stored variable that is recalculated based on a constantly changing input) will change. Thus, code and static data may be placed in a read-only portion of memory, while volatile data is generally placed in a read / write portion of memory. In many embodiments, the software application 208 may be given the opportunity to preset portions of data and code with a storage type bit.For example, if a structure is defined by the software application as volatile (meaning that the data in the structure is changeable), the software application can explicitly communicate this by setting a "volatile" bit for that structure. Then, when the operating system 204 allocates memory space to store the structure, it will see that the "volatile" bit is set and know that the structure is to be allocated in the volatile data area of the DRAM memory space. Alternatively, if a data variable is declared as a constant value, the software application can clear the "volatile" bit to tell the operating system that the data is to be allocated as static.

[0050] In a PCMS-based system, it is entirely plausible to store the code and static data in the PCMS (i.e., NVRAM) memory space, while still storing volatile data in DRAM memory. Thus, according to many embodiments, the operating system establishes an address mapping table 132 that remains resident in the DRAM address space 200. The operating system, while loading the software application 208, specifically stores the code (e.g., Code 1 (210) and Code 2 (212)) and static data 214 in the NVRAM memory space 202, while storing the volatile data 216 in the DRAM memory space 200. After loading, the operating system creates a set of code pointers 218 in the address mapping table 132 to point to each block of code stored in the NVRAM memory space 202.The operating system 204 also creates a set of data pointers 200 in the address mapping table 132 to point to each block of data stored in the NVRAM memory space 202 as well as each block of data stored in the DRAM memory space 200.

[0051] Fig. Figure 3 is a flow diagram of one embodiment of a method for allocating volatile and non-volatile memory for code and data portions of a software application. The method is performed by processing logic that may include hardware, software, firmware, or a combination of two or more of these listed forms of processing logic.

[0052] The method begins with processing logic receiving a request to allocate memory for a portion of a software application (processing block 300). The request may be in the form of an automated or user-initiated decision to execute the software application. After requesting to start and run the software application, the processing logic receives code (such as an executable binary file) and data elements (such as a data file) of the software application for loading into one or more forms of memory for access during execution of the software application.

[0053] For a given section of the software application to be allocated, the processing logic then determines whether the section comprises code or data (processing block 302). If the section comprises code, the processing logic allocates a segment of NVRAM memory space to store the code (processing block 304). If the section comprises data, the processing logic next determines whether the data is volatile (processing block 306).

[0054] In many embodiments, a "volatile" bit is present that can be set or cleared for any given section of data to inform the processing logic whether the data may change during execution of the software application. In other embodiments, not shown, no volatile bit is available; instead, the processing logic initially loads all data into NVRAM memory space, and whenever a section of data is overwritten, the processing logic then determines that the section is volatile and moves that piece of data from an assigned NVRAM memory location to an assigned DRAM memory location.

[0055] Referring again to block 306, if the volatile bit is not set, the processing logic allocates a segment of NVRAM memory space to store the portion of static data (processing block 308). Alternatively, if the volatile bit is set, the processing logic allocates a segment of DRAM memory space to store the volatile data (processing block 310).

[0056] In any case, after memory space has been allocated (by any of the processing blocks 304, 308, or 310), the processing logic then updates the address mapping table resident in DRAM with a pointer to the allocated memory segment in one of the three allocated memory sections (i.e., the volatile data section, the static data section, or the code section).

[0057] Although application software is used as an example, this particular hybrid use of NVRAM and DRAM is not limited to application software. The operating system and driver binaries can also be partitioned in a similar manner, with the static sections placed in NVRAM and the volatile sections placed in DRAM. This provides significant advantages in terms of reducing the time required to resume from low-power states—sections of the operating system and / or drivers would no longer need to be copied back to DRAM when resuming from a hibernate-to-disk state. 4. Hybrid memory code and data storage for embedded control devices

[0058] Many computing platforms have several embedded processors used for a wide range of applications. An embedded processor may also be referred to as a "microcontroller." Examples of embedded processors include manageability engines (which manage a computing system's security and out-of-band communications) and embedded graphics controllers. These embedded controllers use firmware as instructions during runtime to execute many of their core functionalities. This firmware is typically stored in the computer's flash memory (e.g., BIOS) or mass storage device (e.g., hard disk, solid state drive, etc.). When the system boots, the firmware is generally loaded into internal SRAM in the embedded controller for execution.

[0059] Storing the firmware externally on the system's flash memory hard drive involves significant problems, such as: • Firmware tampering can occur and so embedded microcontrollers are generally required to perform authentication at load time to verify the integrity of the firmware before execution. • Firmware stored either in the system's flash memory or on its hard disk may become corrupted, which may harm the functionality of the embedded microcontrollers. • Execution must be preceded by a copy of the firmware into the local SRAM, which is time consuming.

[0060] To address these limitations of embedded controllers, according to many embodiments, PCMS-based memory is packaged with the embedded controller. The logic used to effectively replace system flash and / or hard drives with a localized portion of PCMS memory would include: • A small amount of PCMS-based memory within the component that is accessible to the embedded controller. • A segment of PCMS-based memory dedicated to firmware code. • A segment of PCMS-based memory dedicated to storing persistent data that an application wants to retain across boot sessions (e.g., digital rights management keys, offline movie usage records, etc.). • A cryptographic verification module that allows overwriting the PCMS firmware image only if the image is authentic. • Random SRAM can be added to the embedded machine for runtime data storage (e.g., local variables, a stack, etc.) when PCMS write latency adversely affects performance. • During system boot, the embedded controller can execute firmware code directly from the internal PCMS memory. This direct execution from the PCMS is possible because PCMS read latency matches DRAM, unlike system flash or a hard disk.

[0061] Fig. 4 illustrates an embodiment of a computer system including an embedded controller having direct access to a PCMS device within an I / O subsystem.

[0062] The Fig. 4, except for the changes in the I / O subsystem 124, can generally be compared to the Fig. 1 described computer system. Therefore, for the detailed descriptions of other components, Fig. 1. Within the I / O subsystem 124, Fig. 4, an embedded controller 400 and an internal PCMS memory 402 are present. The internal PCMS 402 stores static information related to the firmware executing the embedded controller 400. During boot-up, the embedded controller 400 can directly execute firmware code from a read-only code region (RO) 404 stored in the internal PCMS 402. In addition, the internal PCMS 402 can also store other information 406, such as fixed (i.e., static) data, keys for security applications (e.g., digital rights management), and usage information to be saved for later use (e.g., a number of times a user views a particular movie on the computing system).This stored information 406 is data that is either completely static or rarely updated and may also include data that requires non-volatility during power-off and power-on of the computer system.

[0063] Furthermore, in many embodiments, the embedded controller 400 includes an internal SRAM portion 408 of memory for storing local variables, a stack, and / or other information that dynamically changes throughout firmware execution. Therefore, this information takes advantage of the fast write capabilities of SRAM and, in contrast, is not limited to PCMS write speeds.

[0064] According to many embodiments, a hardware cryptographic verification (CV) module 410 is additionally present in the I / O subsystem 124. The CV module is capable of using hardware security verification key technology to require that any updates / overwrites to any region of the stored firmware on the PCMS be authenticated by some form of implemented security verification (e.g., public and private authentication modules using keys).

[0065] Fig. 5 describes an embodiment of volatile and non-volatile memory spaces in an I / O subsystem when using a hybrid firmware code and data storage system.

[0066] In Fig.5, the embedded controller 400 includes an internal SRAM memory space 500 that stores runtime data storage 502. The embedded controller 400 is additionally communicatively coupled to the internal PCMS memory space 504, which includes a firmware code region 506 and other memory 508 that stores fixed / static data, keys, and required non-volatile usage information.

[0067] In the following description, numerous specific details are set forth, such as logical implementations, means for specifying operands, implementations for partitioning / sharing / duplicating resources, types and interrelationships of system components, and logical partitioning / integration choices, in order to provide a more thorough understanding of the present invention. However, those skilled in the art will understand that the invention may be practiced without such specific details. In other instances, control structures, gate-level circuitry, and complete software instruction sequences have not been shown in detail in order not to obscure the invention. One of ordinary skill in the art will be able to implement appropriate functionality without undue experimentation given the included descriptions.

[0068] When reference is made in the specification to "the embodiment," "an embodiment," an "exemplary embodiment," etc., it means that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include that particular feature, structure, or characteristic. Moreover, such expressions do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with one embodiment, it is understood that, within the skill of one skilled in the art, it is possible to implement such feature, structure, or characteristic in connection with other embodiments, whether or not expressly described.

[0069] In the following description and claims, the terms "coupled" and "connected" may be used together with derivatives thereof. It is understood that these terms are not synonymous. "Coupled" is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact, cooperate or interact with each other. "Connected" is used to indicate the establishment of a connection between two or more elements that are coupled together.

[0070] Embodiments of the invention may also be provided as a computer program product, which may comprise a non-transitory machine-readable medium having stored thereon instructions that can be used to program a computer (or other electronic device) to perform a method. The non-transitory machine-readable medium may include, but is not limited to, floppy disks, optical disks, CD-ROMs and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media, or other types of media / machine-readable media suitable for storing electronic instructions. Embodiments of the invention may also be downloaded as a computer program product, wherein the program is transmitted from a remote computer (e.g., a server) to a requesting computer (e.g.,a client) via data signals embodied in a carrier wave or other propagation medium over a communications link (e.g., a modem or network connection).

[0071] Although the invention has been described with reference to various embodiments, those skilled in the art will recognize that the invention is not limited to the described embodiments and may be practiced with modifications and variations within the spirit and scope of the appended claims. Thus, the description is to be considered illustrative and not restrictive.

Claims

[1] A method for using volatile and non-volatile memory, the method comprising: Storing one or more static code segments of an executable application in a non-volatile storage device; Storing one or more static data segments of the application in the non-volatile storage device; Storing one or more volatile data segments of the application in a volatile storage device; Assigning an address mapping table having at least a first address pointer for pointing to each of the one or more static code segments, at least a second address pointer for pointing to each of the one or more static data segments, and at least a third address pointer for pointing to each of the one or more volatile data segments; initially storing all data segments of the software application in the non-volatile storage device, for a given data segment within all of the data segments; Transferring the given data segment to the volatile storage device when a rewrite request for the given data segment is received during execution of the application; and Updating the address mapping table using the respective address pointer to a memory section allocated in the volatile memory device. [2] The method of claim 1, wherein storing the static code segments, the static data segments and the volatile data segments is performed during loading of the software application for execution. [3] The method of claim 1, further comprising: Reading a volatile bit variable for each of a set of data segments, wherein when the volatile bit is clear, a given data segment of the set of data segments is stored as a static data segment, and wherein when the volatile bit is set, the given data segment of the set of data segments is stored as a volatile data segment. [4] The method of claim 1, further comprising: Execute each static code segment and static data segment directly from the non-volatile storage device without transferring it to the volatile storage device. [5] The method of any one of claims 1 to 4, wherein the application comprises firmware and the volatile storage device comprises a Static Random Access Memory (SRAM) device integrated into an embedded controller. [6] Device comprising: an embedded control device for: Executing one or more static code segments of a firmware directly from a non-volatile memory device, in particular a PCMS device; Executing one or more static data segments of the firmware directly from the PCMS device; and Executing one or more volatile data segments of the firmware from a static random access memory device integrated into the embedded controller. [7] The apparatus of claim 6, further comprising: a cryptographic verification module for authenticating a new firmware code or data segment received from an external source; wherein the embedded controller requests authentication before allowing execution of the new firmware code or data segment. [8] System comprising: a processor; a volatile memory device for storing memory allocation logic; and a Phase Change Memory with Switch (PCMS) device; wherein the memory allocation logic, when executed by the processor, causes a method according to claims 1-5.

Images