Method and device to distribute code and data stores between volatile memory and non-volatile memory

A method, device, and system to distribute code and data stores between volatile and non-volatile memory are described. In one embodiment, the method includes storing one or more static code segments of a software application in a phase change memory with switch (PCMS) device, storing one or more static data segments of the software application in the PCMS device, and storing one or more volatile data segments of the software application in a volatile memory device. The method then allocates an address mapping table with at least a first address pointer to point to each of the one or more static code segments, at least a second address pointer to point to each of the one or more static data segments, and at least a third address pointer to point to each of the one or more volatile data segments.

FIELD OF THE INVENTION

The invention relates to allocating a combination of volatile memory and non-volatile memory for storage of code and data sections of a software application.

DESCRIPTION OF THE RELATED ART

Memory performance and capacity requirements continue to increase across many aspects of the computing industry. In addition, memory power requirements and memory cost have become a significant component of the overall power and cost, respectively, of a given computing system ranging from a smart phone to a server. Memory and storage subsystems can increase or decrease the overall performance of a computing device depending on implementation specifics. Because it is generally desirable to have faster performing computing devices that utilize less power and cost less, a wide variety of designs of the memory and storage subsystems exist that attempt to maximize end user perceived performance while minimizing cost and power consumption.

Current operating systems provide an application programming interface (API) to allow for applications and drivers to request memory from paged and non-paged pools. Non-paged pools are typically used for data that must not be paged to a mass storage drive (e.g., pages that hardware is expected to access during execution of the application). Since currently all allocated pages are accessed when in DRAM so there is no additional information required at page allocation time whether the data that is going to be stored within an allocated buffer is expected to be for just reading versus read-and-write.

DETAILED DESCRIPTION

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

FIG. 1illustrates an embodiment of a memory arrangement that allows a computer system to utilize a hybrid memory structure for code and data storage for processors as well as for embedded systems.

A central processing unit (CPU), a graphics processing unit (GPU), and an embedded processor may be provided access to both volatile and non-volatile forms of memory according to several embodiments. The CPU and GPU can also be referred to as “processors” throughout this document. These different nomenclatures are utilized.

FIG. 1shows a number of logic units which may or may not be located on the same or different semiconductor dies or the same or different semiconductor package. Logic units inFIG. 1include a CPU that has one or more cores and a cache, a GPU that also has one or more cores and a cache, a memory subsystem, and an I/O subsystem. These units are separated by dotted lines to show the possibility that each of these logic blocks may or may not be located in the same semiconductor die and/or package.

Turning now to the detailed elements ofFIG. 1, a CPU100is present. This CPU includes one or more cores102. 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 that are not shown, the system may include multiple CPUs, each with its own set of logic units that are displayed inFIG. 1.

The CPU100includes at least one lower level cache, such as cache104. This may be a general purpose cache that is capable of storing a significant amount of data retrieved from memory locations in volatile memory106and/or an NVRAM108. In different embodiments, cache104may be shared among all cores or each core may have its own lower level cache.

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

According to several embodiments, the computer system inFIG. 1additionally includes a GPU110. The GPU110also may include one or more core(s)112. Each core may include one or more execution units and one or more instruction and data caches utilized to feed the execution units with information to process. Additionally the GPU110may contain other graphics logic units that are not shown inFIG. 1, such as one or more vertex processing units, rasterization units, media processing units, and codecs among others. For sake of simplicity, the specific logic within the core(s)112as well as other graphics-related logic units within the GPU110are not shown.

There may be one or more lower level caches in GPU110as well, such as cache114. This cache may be utilized 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, though in some embodiments multiple caches like cache114exist within GPU110.

According to many embodiments, a display controller116is communicatively coupled to the GPU110. The display controller124receives information to be displayed upon a display device (e.g., a monitor, a television, a projector, etc.). In many embodiments, the display controller116specifically receives frame buffers. Each frame buffer consists of an image comprising pixels that is then interpreted by the display controller and the image is fed to the display device for viewing. Depending on the refresh frequency of the display device, frame buffers may be fed to the display controller116a certain number of times per second. For example, a 60 Hz refresh rate utilizes 60 images (frame buffers of image information) per second. Different display devices may utilize higher frequency refresh rates and simply re-sample the same frame buffer two or more times prior to utilizing anew frame buffer of information to display.

A memory subsystem118is also present inFIG. 1. There is a volatile memory controller120, which may be utilized to provide access to volatile memory106. Volatile memory controller120, which is integrated into the CPU package or discrete from the CPU package in different embodiments, may receive a memory access request from a CPU core102or a GPU core112and route that request to volatile memory106. Likewise, non-volatile (NV) memory controller122may receive a memory access request from a CPU core102or a GPU core112and route that request to NVRAM108. In some embodiments, the volatile memory controller120and non-volatile memory controller122are integrated into one large memory controller. In other embodiments they are separate controllers.

In many embodiments, an input/output (I/O) subsystem124is present in the system inFIG. 1to communicate with I/O devices, such as I/O device(s)126. Within the I/O subsystem124, one or more I/O adapter(s)128are present to translate a host communication protocol utilized within the CPU100to a protocol compatible with particular I/O devices. Some of the protocols that adapters may be utilized 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.

Additionally, there may be one or more wireless protocol I/O adapters. Examples of wireless protocols, among others, are used in 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.

A Basic Input/Output System (BIOS) flash130device may additionally be present in the system to provide a set of boot instructions when the system powers on or reboots. For BIOS flash130device, some of the protocols that I/O adapters128may translate include Serial Peripheral Interface (SPI) and Microwire among others.

Returning to the NVRAM108, an overview of the NVRAM is provided below.

1. Non-Volatile Random Access Memory Overview

There are many possible technology choices 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), universal memory, Ge2Sb2Te5, programmable metallization cell (PMC), resistive memory (RRAM), RESET (amorphous cell, SET (crystalline) 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).

NVRAM has the following characteristics:

It maintains its content even if power is removed, similar to FLASH memory used in solid state disks (SSD), and different from SRAM and DRAM which are volatile;

it has lower overall power consumption than volatile memories such as SRAM and DRAM;

it has random access similar to SRAM and DRAM (also known as randomly addressable);

it is rewritable and erasable at a lower level of granularity (e.g., byte level) than FLASH found in SSDs (which can only be rewritten and erased a “block” at a time—minimally 64 Kbyte in size for NOR FLASH and 16 Kbyte for NAND FLASH);

it is used as a system memory and allocated all or a portion the system memory address space;

it is capable of being coupled to the CPU over a bus (also interchangeably referred to as an interconnect or link) using a transactional protocol (a protocol that supports transaction identifiers (IDs) to distinguish different transactions so that those transactions can complete out-of-order) and allowing access at a level of granularity small enough to support operation of the NVRAM as system memory (e.g., cache line size such as 64 or 128 byte). 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 is run a transactional protocol as opposed to the non-transactional protocol that is normally used. As another example, the bus may one over which is normally run a transactional protocol (a native transactional protocol), such as a PCI express (PCIE) bus, desktop management interface (DMI) bus, or any other type of bus utilizing a transactional protocol and a small enough transaction payload size (e.g., cache line size such as 64 or 128 byte); and

it also has one or more of the following characteristics:

it has faster write speed than non-volatile memory/storage technologies such as FLASH;

it has very high read speeds (faster than FLASH and near or equivalent to DRAM read speeds);

it is directly writable (rather than requiring erasing (overwriting with 1s) before writing data like FLASH memory used in SSDs); and/or

it allows a greater number of writes before failure (more than boot ROM and FLASH used SSDs).

As mentioned above, in contrast to FLASH memory, which must be rewritten and erased a complete “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 implementations where NVRAM is used as system memory, the NVRAM may be accessed at the granularity of a cache line (e.g., a 64-byte or 128-Byte cache line), notwithstanding an inherent ability to be accessed at the granularity of a byte, because cache line is the level at which the memory subsystem accesses memory. Thus, when NVRAM is deployed within a memory subsystem, it may be accessed at the same level of granularity as DRAM used in the same memory subsystem. Even so, the level of granularity of access to the NVRAM by the memory controller and memory bus or other type of bus is smaller than that of the block size used by Flash and the access size of the I/O subsystem's controller and bus.

NVRAM may also incorporate wear leveling algorithms to account for the fact that the storage cells begin to wear out after a number of write accesses, especially where a significant number of writes may occur such as in a system memory implementation. Since high cycle count blocks are most likely to wear out in this manner, wear leveling spreads writes across the far memory cells by swapping addresses of high cycle count blocks with low cycle count blocks. Note that most address swapping is typically transparent to application programs because it is handled by hardware, lower-level software (e.g., a low level driver or operating system), or a combination of the two.

The NVRAM is distinguishable from other instruction and data memory/storage technologies in terms of its characteristics and/or its application in the memory/storage hierarchy. For example, NVRAM is different from:

static random access memory (SRAM) which may be used for level 0 and level 1 internal processor caches dedicated to each core within a processor and lower level cache (LLC) shared by cores within a processor;

dynamic random access memory (DRAM) configured as a cache internal to a processor die (e.g., on the same die as the processor), configured as one or more caches external to a processor die (e.g., in the same or a different package than the processor die), or general system memory external to the processor package; and

FLASH memory/magnetic disk/optical disc applied as mass storage; and

memory such as FLASH memory or other read only memory (ROM) applied as firmware memory (which can refer to boot ROM, BIOS Flash, and/or TPM Flash).

InFIG. 1, NVRAM108may be used as instruction and data storage that is directly addressable by a CPU100and is able to sufficiently keep pace with the CPU100in contrast to FLASH/magnetic disk/optical disc applied as mass storage. 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 standard DRAM (e.g., through standard memory store and load commands). Moreover, as discussed above and described in detail below, NVRAM108may be placed on a memory bus and may communicate directly with a memory controller that, in turn, communicates directly with the processor100.

NVRAM108may be combined with other instruction and data storage technologies (e.g., DRAM) to form hybrid memories (also known as Co-locating PCM and DRAM; first level memory and second level memory; FLAM (FLASH and DRAM)). Note that at least some of the above technologies, including PCM/PCMS may be used for mass storage instead of, or in addition to, system memory, and need not be random accessible, byte addressable or directly addressable by the processor when applied in this manner.

For convenience of explanation, most of the remainder of the application will refer to “NVRAM” or, more specifically, “PCM,” or “PCMS” as the technology selection 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 realized, as discussed above, that different technologies may also be utilized.

2. Volatile Memory Overview

“Volatile memory”106is an intermediate level of memory configured in conjunction with NVRAM108that has lower read/write access latency relative to NVRAM108and/or more symmetric read/write access latency (i.e., having read times which are roughly equivalent to write times). In some embodiments, the volatile memory106has significantly lower write latency than the NVRAM108but similar (e.g., slightly lower or equal) read latency; for instance the volatile memory106may be a volatile memory such as volatile random access memory (VRAM) and may comprise a DRAM or other high speed capacitor-based memory. Note, however, that the underlying principles of the invention are not limited to these specific memory types. Additionally, the volatile memory106may have a relative lower density and/or may be more expensive to manufacture than the NVRAM108.

In some embodiments, volatile memory106is configured between the NVRAM108and the internal processor caches. In some of the embodiments described below, volatile memory106is utilized to mask the performance and/or usage limitations of the NVRAM108including, for example, read/write latency limitations and memory degradation limitations. In these implementations, the combination of volatile memory106and NVRAM108operates at a performance level which approximates, is equivalent or exceeds a system which uses only DRAM as system memory.

In different embodiments, volatile memory106can be located on the processor die, located external to the processor die on a separate die located on the CPU package, located outside the CPU package with a high bandwidth link to the CPU package, for example, on a memory dual in-line memory module (DIMM), a riser/mezzanine, or a computer motherboard). InFIG. 1, volatile memory106is shown being located external to the CPU package. The volatile memory106may be communicatively coupled with the CPU100using a single or multiple high bandwidth links, such as DDR or other transactional high bandwidth links. A communicative coupling of devices refers to being coupled through an electrical, optical, wireless, or other form of link or combination of links to allow information to be passed back and forth between the devices that are coupled to one another. In some embodiments, the coupling is direct and allows information to pass directly from the first device to the second and, potentially, vice versa. In other embodiments, the coupling is indirect and requires the information to pass through one or more additional devices that reside along the route the information takes while being transferred between the two communicatively coupled devices in question.

3. Hybrid Memory Code and Data Storage for Processors

According to many embodiments, a hybrid memory solution in a computer system combining DRAM and PCMS storage or another type of NVRAM may be utilized to access both the code and data sections of a software application being executed is disclosed. As mentioned above, although other forms of NVRAM may be applicable to these solutions, the technical specifications of PCMS make it a quality candidate technology for non-volatile memory/storage. Thus, the examples shown will make use of PCMS memory, although in other embodiments, another form of NVRAM may be utilized.

In a computer system that includes an amount of PCMS memory/storage. Software applications and an operating system running on the computer system may both take advantage of a PCMS device's fast read capability. The fast reads may allow software application and operating system to execute code directly from PCMS on the processor.

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

The operating system will build an interface for the software application and any driver software running on the operating system. According to many embodiments, the application and/or the driver will 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 software application's and/or driver's allocated memory address space. Because the binaries in these buffers are not modified, there is generally an explicit indication/designation originated by the software, driver, and/or the operating system to make the buffers unmodifiable.

The operating system running on the system may treat the PCMS storage as a physical DRAM and map portions of the files that make up the operating system and software application into a memory management unit (MMU). When in the MMU, these file locations can be translated and stored similar to translation lookaside buffer (TLB) entries and addressed as if they were standard DRAM memory locations. From an operating system's logical address space to a physical PCMS device address location there may be multiple page walks to first get from a logical address that the operating system utilizes, to a platform physical address (PPA) that the underlying general memory management hardware utilizes for main DRAM memory, and finally to a direct physical PCMS device address. There may be one or more address mapping tables132(also known as address indirection tables) to accomplish this. In many embodiments, the address mapping tables132are stored in DRAM (volatile memory106).

Apart from binary code storage in PCMS, there are other portions of software application, driver, and operating system information that may be stored adequately in physical PCMS space. Specifically, certain data (as opposed to code) sections of the software also may be storable in PCMS when that data is static or nearly static. Thus, in many embodiments there is at least a bit designation per data element that signifies whether the particular data element to be stored is or is not static. The static designated data elements may be stored in static (i.e., unmodifiable) buffers, whereas the non-static designated data elements may be stored in volatile (i.e. modifiable) buffers. This particular designation per buffer allows the OS to:Determine when to allocate a buffer in actual DRAM vs. PCMS storage, wherein the buffer is allocated in DRAM if the buffer is designated as volatile and allocated in PCMS when the buffer is designated as static.When allocating a buffer in DRAM, the operating system may simply follow a legacy page allocation procedure.When allocating a buffer in PCMS (i.e., a buffer not requiring modification), the operating system may map physical PCMS device address space into its page tables to allow direct memory accesses to the PCMS device.Optionally, the operating system may enforce the read only characteristics of a buffer by setting only read permissions for the PCMS buffer.

FIG. 2describes an embodiment of volatile and non-volatile memory spaces when utilizing a software application hybrid code and data storage system.

InFIG. 2a DRAM memory space200(e.g., 4 GB of space) and an NVRAM memory space202(e.g., 64 GB of space) are present. There may be additional memory spaces, including a logical memory space in which the operating system controls, but those are not shown for sake of clarity. An operating system204is resident in DRAM memory space200and is being executed on the CPU100. In many embodiments, driver software206is also resident in DRAM memory space200and is executing on the CPU100in conjunction with the operating system204. At some point during operation, the operating system204loads a software application208into DRAM memory space200. The load operation includes the operating system204reserving memory space for the software application208. The reserved memory space includes space that is utilized to store the software application's binary executable code (“code”) as well as space that is utilized to store any modifiable data (“data”) the software application208uses to run.

As mentioned above, according to many embodiments, the code is generally static, as the binary files do not change during execution. On the other hand, data may change or it may not change, depending on a type of data. For example, static data (e.g., constants) will not change but volatile data (e.g., a stored variable that is recalculated based on continually changing input) does change. Thus, code and static data can be placed in a read-only section of memory, whereas volatile data would generally be placed in a read/write section of memory. In many embodiments, the software application208may be given the opportunity to preset portions of data and code with a storage-type bit. For example, if a structure that is defined by the software application as volatile (meaning data in the structure is modifiable), the software application may expressly relay that by setting a “volatile” bit for that structure. Then when the operating system204is allocating memory space to store the structure, it will see the “volatile” bit as set and know to allocate the structure in the volatile data section of DRAM memory space. Alternatively, if a data variable is declared as a constant value, the software application may clear the “volatile” bit to tell the operating system to allocate the data as static.

In a PCMS-based system, it is entirely plausible to store the code and static data in PCMS (i.e., NVRAM) memory space while still storing volatile data in DRAM memory. Thus, according to many embodiments, the operating system sets up an address mapping table132that stays resident in DRAM memory space200. The operating system, while loading the software application208, specifically stores the code (e.g., code 1 (210) and code 2 (212)) and static data214into NVRAM memory space202while storing the volatile data216in DRAM memory space200. Once loaded, the operating system creates a group of code pointers218in the address mapping table132to point to each block of code stored in the NVRAM memory space202. The operating system204also creates a group of data pointers220in the address mapping table132to point to each block of data stored in the NVRAM memory space202as well as each block of data stored in the DRAM memory space200.

FIG. 3is a flow diagram of an embodiment of a process to allocate volatile and non-volatile memory for code and data sections of a software application. The process is performed by processing logic which may comprise hardware, software, firmware, or a combination of two or more of these listed forms of processing logic.

The process begins with processing logic receiving a request to allocate memory for a portion of a software application (processing block300). The request may come in the form of an automated or user-initiated decision to execute the software application. Once it is requested to launch and execute the software application, processing logic receives code (such as a binary executable file) and data (such as a data file) elements of the software application to load into one or more forms of memory to have access during execution of the software application.

For a given portion of the software application to be allocated, processing logic then determines whether that portion comprises code or data (processing block302). If the portion comprises code, then processing logic allocates a segment of NVRAM memory space for storage of the code (processing block304). If the portion comprises data, then processing logic next determines whether the data is volatile (processing block306).

In many embodiments, there is a “volatile” bit that may be set or cleared for any given portion of the data to inform the processing logic whether the data may change during execution of the software application. In other embodiments that are not shown, there is not a volatile bit available but instead processing logic loads all data originally into NVRAM memory space and whenever a portion of the data is re-written over, processing logic then determines that portion is volatile and moves that element of data from an NVRAM allocated storage location to a DRAM allocated storage location.

Returning to block306, if the volatile bit is not set, then processing logic allocates a segment of NVRAM memory space for storage of the portion of the static data (processing block308). Alternatively, if the volatile bit is set, then processing logic allocates a segment of DRAM memory space for storage of the volatile data (processing block310).

In any event, once memory space is allocated (from any of processing blocks304,308, or310), then processing logic updates the address mapping table resident in DRAM with a pointer to the allocated memory segment in one of the three allocated sections of memory (i.e., the volatile data section, the static data section, or the code section).

Although application software is utilized as the example, this particular hybrid use of NVRAM and DRAM is not limited to application software. The operating system and driver binaries may also be similarly divided up and the static portions be placed in NVRAM while the volatile portions are placed in DRAM. This provides significant benefit in terms of reducing the amount of time required to resume from low power states—portions of the operating system and/or drivers would no longer need to be copied back into DRAM when resuming from a hibernate-to-disk state.

4. Hybrid Memory Code and Data Storage for Embedded Controllers

Many computing platforms have a number of embedded processors that are used for a wide range of applications. An embedded processor can also be referred to as a “microcontroller.” Examples of embedded processors include manageability engines (which manage a computer system's security and out-of-band communications) and graphics embedded controllers, among others. These embedded controllers use firmware during runtime as instructions to execute many of their core functionalities. This firmware is typically stored on the computer system's flash memory (e.g., BIOS) or mass storage drive (e.g., hard drive, solid state drive, etc.). At system boot, the firmware is generally loaded into an internal SRAM in the embedded controller for execution.

There are significant issues with storing the firmware externally on the system flash memory hard drive such as:The firmware can be tampered with, so embedded microcontrollers generally are required to perform an authentication at load time to verify the integrity of the firmware before execution.Firmware stored either in the system flash memory or hard drive are subject to corruption, which can cripple the functionality of the embedded microcontrollers.Execution must be preceded by a copy of the firmware into the local SRAM which is time consuming.

To address these limitations of embedded controllers, according to many embodiments, a PCMS-based storage is packaged with the embedded controller. The logic utilized to effectively replace system flash and/or a hard drive with a localized portion of PCMS memory would include:A small amount of PCMS-based storage inside the component accessible to the embedded controller.A segment of the PCMS-based storage set aside for the firmware code.A segment of the PCMS-based storage set aside for storing persistent data that an application might want to store across boot sessions (e.g., digital rights management keys, offline movie usage records, etc.)A cryptographic verification module that allows the PCMS firmware image to be overwritten only if the image is authentic.An optional SRAM can be added to the embedded engine for runtime data storage (e.g., local variables, a stack, etc.) if the PCMS write latency adversely affects performance.During boot of the computer system, the embedded controller may execute the firmware code directly out of the internal PCMS storage. This execute from PCMS directly is made possible because PCMS read latency matches DRAM unlike system flash or a hard drive.

FIG. 4illustrates an embodiment of a computer system that includes an embedded controller which has direct access to a PCMS device internal to an I/O subsystem.

The computer system shown inFIG. 4may be generally equivalent to the computer system described inFIG. 1, outside of changes in the I/O subsystem124. Thus, for detailed descriptions of other components, please refer toFIG. 1. Within the I/O subsystem124, there is an embedded controller400and an internal PCMS memory402present inFIG. 4. The internal PCMS402stores static information related to firmware that the embedded controller400executes. During boot, the embedded controller400may directly execute firmware code from a read only (R-O) code region404stored in the internal PCMS402. Additionally, the internal PCMS402may also store other information406, such as fixed (i.e., static) data, keys for security applications (e.g., digital rights management), as well as usage information to be saved for a later time (e.g., number of times a user watches a given movie on the computer system). This stored information406is data that is either entirely static or rarely updated and also may include data that requires non-volatility through power cycling the computer system.

Furthermore, in many embodiments, the embedded controller400has an internal SRAM408portion of memory for storage of local variables, a stack, and/or other information that dynamically changes throughout the execution of the firmware. Thus, this information benefits from the fast write capabilities of the SRAM, as opposed to being limited to PCMS write speeds.

According to many embodiments, there is additionally a cryptographic verification (CV) hardware module410present in the I/O subsystem124. The CV module is able to utilize hardware security verification key technology to require any updates/overwrites to any region of the stored firmware on the PCMS to be authenticated through any implemented form of security verification (e.g., public and private authentication modules using keys).

FIG. 5describes an embodiment of volatile and non-volatile memory spaces in an I/O subsystem when utilizing a hybrid firmware code and data storage system.

InFIG. 5, the embedded controller400has an internal SRAM memory space500that stores runtime data storage502. The embedded controller400is additionally communicatively coupled to internal PCMS memory space504, which stores a firmware code region506and other storage508that stores fixed/static data, keys, and required non-volatile usage information.