Logical memory address regions

Systems, apparatuses, and methods for implementing logical memory address regions in a computing system. The physical memory address space of a computing system may be partitioned into a plurality of logical memory address regions. Each logical memory address region may be dynamically configured at run-time to meet changing application needs of the system. Each logical memory address region may also be configured separately from the other logical memory address regions. Each logical memory address region may have associated parameters that identify region start address, region size, cell-level mode, physical-to-device mapping scheme, address masks, access permissions, wear-leveling data, encryption settings, and compression settings. These parameters may be stored in a table which may be used when processing memory access requests.

BACKGROUND

Technical Field

Embodiments described herein relate to computer systems and more particularly, to systems and methods of managing memory address ranges in a memory device.

Description of the Related Art

Memory devices, such as double data rate (DDR) devices, dynamic random access memory (DRAM) devices, high bandwidth memory (HBM) devices, and Hybrid Memory Cube (HMC) devices are used for short-term data access in computing systems. These memory devices include a single, contiguous physical address space that is configured at startup and is managed uniformly.

Each type of memory technology (e.g., DRAM, phase-change memory and NAND Flash) includes a variety of physical properties, such as a size (e.g., row size, column size) and counts (e.g., channel count, bank count, rank count, row count), that may differ from sizes and counts of other types of memory technology. Some memory devices using the same technology may also include different physical properties of devices using the same technology. For example, some DRAM devices may include 1 kilobyte (KB) row buffer sizes and other DRAM devices may include 2 KB row buffer sizes.

SUMMARY

Systems, apparatuses, and methods for managing address ranges with different properties within a physical memory address space are contemplated.

Embodiments described herein provide memory systems, apparatuses, and methods to support diverse memory technologies and devices with different internal partitions (e.g., channels, ranks, banks, rows, columns and bits). Embodiments provide systems, apparatuses, and methods to support memory devices using the same technology but having different physical properties (e.g., multiple striping patterns (device address mappings) for incoming physical address ranges for different applications). Embodiments disclosed herein also provide physical device mapping functions based on a particular (e.g., target) memory technology or device.

Embodiments disclosed herein describe managing address range properties and device mappings in different memory technologies by using physical address spaces of memory devices that are divided into multiple logical memory address regions (or logical regions, for short) of non-overlapping, contiguous address ranges of the physical memory address space. In various embodiments, the address ranges of a memory device may be dynamically created and managed. Access patterns, permissions, and properties of each address range may be optimized independent of other address ranges. In addition, the number of bits per cell in the non-volatile memory address ranges may also be managed.

Embodiments may also include different application-specific mapping functions that facilitate efficient performance and energy consumption depending on memory access patterns. In various embodiments, physical address to device address mapping functions may be dynamically configured at run-time (as opposed to setting a function at start up), thereby providing a mechanism to adapt the mapping function to the application kernel's memory access patterns. Memory accesses for the logical memory address regions may further be optimized based on the application kernel that accesses each region. A physical-to-device address mapping function may be selected for a region dynamically at runtime and independent of other regions.

Some non-volatile memory devices support storing multiple bits per cell. For example, PCM devices typically support storing two, three, or four bits per cell. Such multi-level cell (MLC) devices offer higher density at the expense of higher access latency, higher access energy, and lower endurance. Memory parameters (such as latency and capacity) vary between different applications. According to some embodiments, each logical memory address region may operate in either single-level cell (SLC) mode or MLC mode. For example, if a device supports storing up to three bits per cell (called Tri-level cells or 3LC), each logical memory address region can independently operate in either one bit per cell mode, two bits per cell mode, or three bits per cell mode depending on endurance, access latency, access energy, and capacity parameters.

Also contemplated are embodiments in which wear-leveling of each logical region may be managed separately using an algorithm that matches the logical region requirements and capabilities. Each logical region may utilize its own features (such as data encryption, compression) that are not enabled/supported in other logical memory address regions. Each logical region may also include its own access permissions. For example, a particular core may have only read access permission to a given logical region, while another core may have full access permission to the same region.

In various embodiments, different access priorities may be assigned to different logical regions. In such embodiments, a memory controller may manage and prioritize memory accesses based on the target logical region. For example, a logical region that contains data that is less frequently accessed than some other data can have a low access priority while other logical regions that contain latency-sensitive data may have a higher access priority. In such cases, the memory controller may service accesses to the latter region faster. Accordingly, various priorities may be known based on the target logical region without embedding priority data in each access request.

Embodiments are contemplated in which a hybrid memory device is logically divided into regions with different properties. For example, for a PCM+DRAM device, two logical regions may be defined, a DRAM logical region and a PCM logical region. While the DRAM logical region may not use a write management policy, logical regions of the PCM logical region may provide a mechanism to disable/enabled write pausing. More generally, logical memory address regions may be adapted based on the underlying memory technology.

These and other features and advantages will become apparent to those of ordinary skill in the art in view of the following detailed descriptions of the approaches presented herein.

DETAILED DESCRIPTION OF EMBODIMENTS

Referring now toFIG. 1, a block diagram of a device100in which one or more disclosed embodiments may be implemented is shown. The device100may be, for example, a computer, a gaming device, a handheld device, a set-top box, a television, a mobile phone, a tablet computer, a server, or other computing device or system. The device100includes a processor102, a memory104, a storage device106, one or more input devices108, and one or more output devices110. The device100may also optionally include an input driver112and an output driver114. It is understood that the device100may include additional components not shown inFIG. 1.

The processor102may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, wherein each processor core may be a CPU or a GPU. The processor102may be configured to execute an operating system (OS) and one or more software applications. The memory104may be located on the same die as the processor102, or may be located separately from the processor102. The memory104may include a volatile or non-volatile memory, random access memory (RAM), dynamic RAM, a cache, or other memory.

The storage device106may include a fixed or removable storage device, for example, a hard disk drive, a solid state drive, an optical disk, a flash drive, or other device. The input devices108may include a keyboard, a keypad, a touch screen, a touch pad, a detector, a microphone, an accelerometer, a gyroscope, a biometric scanner, a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals), or other device. The output devices110may include a display, a speaker, a printer, a haptic feedback device, one or more lights, an antenna, a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals), or other device.

The input driver112communicates with the processor102and the input devices108, and permits the processor102to receive input from the input devices108. The output driver114communicates with the processor102and the output devices110, and permits the processor102to send output to the output devices110. It is noted that the input driver112and the output driver114are optional components, and that the device100will operate in the same manner if the input driver112and the output driver114are not present.

In one embodiment, processor102may be configured to partition the physical memory address space of memory104into a plurality of logical memory address regions. Each logical memory address region may be configured and managed separately from the other logical memory address regions. A plurality of applications may execute on processor102, and the applications may be assigned to logical memory address regions, with each logical memory address region including a plurality of parameters which are optimized for the memory accesses and requirements of the corresponding application. In one embodiment, each application may be assigned to a different logical memory address region. In another embodiment, some applications may share a logical memory address region. In other embodiments, each application may be assigned to two or more logical memory address regions.

Turning now toFIG. 2, a diagram illustrating an exemplary physical memory address space200divided into two logical memory address regions (Region205A and Region205B) with different capacity and mapping schemes is shown. As shown inFIG. 2, Region205A has a 2 GB capacity and Region205B has a 6 GB capacity. Region205A also includes an address mapping scheme210A and Region205B includes an address mapping scheme210B.

The logical divisions (Region205A and Region205B) of the physical memory address space200may be specified to program memory controllers (e.g., memory controller310inFIG. 3) to support diverse memory types and device address mappings. The logical memory address regions (Region205A and Region205B) are non-overlapping, contiguous address ranges of the physical memory address space. The logical memory address regions (Region205A and Region205B) are utilized to optimize memory device access patterns and properties of address ranges individually and dynamically. Each logical memory address region, independent from other logical memory address regions, may adopt its own properties that provide performance, bandwidth, and energy benefits for the application that accesses the corresponding region. For example, at least a first attribute of a first plurality of attributes specified for a first logical memory address region may be different from a corresponding attribute of a second plurality of attributes specified for a second logical memory address region. Properties of each region may be optimized dynamically at runtime. Regions may be added, deleted, modified, separated, or merged dynamically. The capacity, size and number of regions shown inFIG. 2are exemplary. Embodiments may include any number of logical memory address regions having any size and any capacity.

Referring now toFIG. 3, a diagram illustrating an exemplary logical memory address range management system300in which one or more disclosed embodiments may be implemented is shown. System300may include host processor305, memory controller310, and memory array330. Depending on the embodiment, memory array330may include a single memory device or multiple memory devices. It is noted that memory array330may also be referred to as a memory device. Furthermore, depending on the embodiment, memory controller310may be physically attached to host processor305or memory controller310may be physically attached to memory array330.

As shown inFIG. 3, the system300may include a programmable logical region table320that includes information corresponding to each logical memory address region (e.g., Region Info325A, Region Info325B, Region Info325C). The logical region table320may include configuration data of each logical memory address region. For example, the table may include, for each logical memory address region, information such as region ID, start address, region size, cell-level mode for NVM (SLC/MLC2/4/8/16 bits per cell, 3 bits per cell, 5 bits per cell or otherwise), physical-to-device mapping scheme and address masks, access permissions, wear-leveling data, encryption settings, compression settings, and vendor-specific features. In some embodiments, the contents of the table may be programmed by the host processor305and read by the memory controller310. It is noted that while the term “table” is used herein, such a table may be organized or structured in any of a variety of ways.

Because properties of a logical memory address region, such as its physical address to device (physical-to-device) address mapping, may be configured at runtime, a hardware/firmware unit (e.g., region selector) in the memory controller may select and retrieve information from the table that specifies properties or settings of a logical memory address region and validates the logical memory address region against a specification of the memory device and the memory device's supported capabilities. For example, for a memory device that has 16 banks, the physical-to-device mapping of a logical region cannot specify 32 banks. In one embodiment, validation unit318of control logic315may be configured to validate the parameters of a logical memory address region against a specification retrieved from capabilities table335of the memory array330. The capabilities table335may include information specifying the underlying memory technology and the supported capabilities of memory array330.

The configuration of logical memory address regions may be added, deleted, and modified (e.g., by the host processor305) by writing into the logical region table320. The memory controller310may verify the configuration of the logical memory address regions and may send error messages (e.g., back to the host processor305) if errors (e.g., incorrect configuration) are detected. The memory controller310may also indicate completion of NVM cell level change of a region by notifying the host using a Done/Error response. For example, the host processor305might change the cell level of a region from SLC to two-bits per cell to increase the region capacity. The memory controller310may transfer data to the new cell level configuration, which in some embodiments, may require OS support.

Turning now toFIG. 4, a system flow diagram illustrating an exemplary translation of a physical address415of a memory access request410to a device address442according to an embodiment is shown. In one embodiment, the most significant bits420of a memory request address410and the address ranges422of regions may be used to determine which region corresponds to the request. A region selector435may select the region corresponding to the request. The system may validate that the physical address belongs to a valid region and the access permission is not violated. For example, requests to range addresses that are not allocated to any logical memory address region may cause an error.

A Region ID438corresponding to the selected region and the remaining least significant address bits430may be used to perform physical to device address translation440. Prior to translation, the system may also validate that the memory request accesses a valid address. For example, the capacity of a logical region varies based on the cell level mode (if supported). The system may determine if the physical address415of the memory request410is an address located outside the available capacity in the logical region. If so, the memory request410may be prevented from accessing the memory location.

The address mapping scheme corresponding to the Region ID438may read from the logical region table425to utilize a physical-to-device mapping427to translate the physical address415of the memory access request410to a device address442. After translation, the generated control signals may be sent from memory controller405to the memory array445to access data at the device address442.

Referring now toFIG. 5, a block diagram of one embodiment of a logical memory address region table500is shown. In one embodiment, the fields shown in logical memory address region table500may be included within logical region table425(ofFIG. 4). Logical memory address region table500may include a plurality of entries for a plurality of logical memory address regions which are mapped to separate portions of the physical memory address space of the host system's memory devices. Table500may include any number of entries, depending on the embodiment. As shown inFIG. 5, table500includes entries for logical memory address region IDs505A,505B and505C.

Each entry of table500may include a start address field, region size field, cell-level mode field, physical-to-device mapping scheme field, address mask field, access permissions field, wear-leveling data field, vendor-specific features, and one or more other fields. The start address field may specify the starting address of the logical memory address region in the physical memory address space. The region size may specify the total size of the logical memory address region. The cell-level mode field may specify the cell-level mode (e.g., number of bits per cell) for NVMs. The physical-to-device mapping scheme field may specify the striping pattern (e.g., coarseness) that is utilized for writing data to the memory devices. The physical-to-device mapping scheme field may also specify if mirroring or redundancy is employed and the type of mirroring or redundancy. The address mask field may specify the address bit mask to be used with memory requests targeting the logical memory address region. The access permissions field may specify the read, write, and execute permissions for accesses to the logical memory address region.

The wear-leveling data may specify a number of erase-cycles which have been performed to the region. The wear-leveling data may also include data at a finer granularity, for example, for each erase block of the corresponding region. The vendor-specific features field may include data corresponding to the vendors of the memory device(s) to which the region maps. Other fields which may be included in the entries of table500may include an encryption field to specify if encryption is enabled and which type of encryption is being utilized and a compression field to specify if compression is enabled and which type of compression is being utilized. It is noted that each entry of table500may be programmed separately from the other entries, such that the parameters and attributes of a given region are independent from the parameters and attributes of the other regions. This allows the system to configure each region to meet the needs of the application(s) which are mapped to the region.

Referring now toFIG. 6, a block diagram of a computing system600is shown. System600may include at least memory controller605and memory array635. Memory controller605may be configured to receive memory access requests from a host processor (not shown) and store the requests in queue610prior to conveying the requests to memory array635. Memory controller605may include queue610, table625, and picker logic630. Memory controller605may also include other logic which is not shown inFIG. 6to avoid obscuring the figure. Queue610may be configured to store incoming requests received from one or more host processors. In other embodiments, memory controller605may include multiple queues. For example, memory controller605may include a read queue for storing read requests and a write queue for storing write requests. However, a single queue610is shown inFIG. 6for the purposes of simplicity. As shown in queue610, the request ID and the region which is being targeted by the request are stored as fields in queue610. In other embodiments, the address may be stored in queue610, and the memory controller may be configured to determine which logical memory address region (or region, for short) is targeted by the address from a mapping table. When multiple memory access requests are pending at a given time, memory controller605may arbitrate between these requests.

In one embodiment, requests sent to memory controller605may not include an assigned priority. Rather, the requests may include an address targeted by the request, and then memory controller605may determine the region targeted by the request using the request's address. Next, picker logic630of memory controller605may determine a priority of a request from table625by mapping the region ID of a request to a priority assigned to the region. For example, queue610is shown as including two requests615A and615B. Request615A targets region620A of memory array635, and picker logic630may determine from table625that requests to region620A should be processed with a low priority. Also, request615B targets region620B of memory array635, and picker logic630may determine from table625that requests to region620B should be processed with a high priority. Accordingly, picker logic630may select request615B prior to request615A to be conveyed to memory array635.

Referring now toFIG. 7, one embodiment of a method700for implementing logical memory address regions is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. However, it should be noted that in various embodiments, one or more of the steps described may be performed concurrently, in a different order than shown, or may be omitted entirely. Other additional steps may also be performed as desired. Similarly, other methods described herein may be presented with steps in a particular sequence. However, those methods may likewise vary as noted above. Any of the various systems or apparatuses described herein may be configured to implement method700.

In various embodiments an operating system may be configured to partition the physical memory address space of one or more memory devices into one or more logical memory address regions (block705). The operating system may also be configured to assign a software application (or processes, or threads, etc.) to a given logical memory address region of the plurality of logical memory address regions (block710). It is noted that a given logical memory address region may be shared among multiple processes. The operating system may further determine a given set of parameters, based on the characteristics of the application and the characteristics of the targeted memory device(s), to apply to the given logical memory address region (block715). The given set of parameters may include at least a region ID, start address, region size, cell-level mode for NVM (SLC/MLC2/4/8/16 bits per cell), physical-to-device mapping scheme, address masks, access permissions, wear-leveling data, encryption settings, compression settings, vendor-specific features, and other parameters.

Subsequent to determining the parameters, the operating system may program the memory controller to use the parameters (block720). For example, the parameters may be stored in a table that is used by the memory controller. The memory controller may then utilize the given set of parameters for processing memory requests targeting the given logical memory address region (block725). For example, a first application may generate a first memory request and convey the first memory request to the memory controller. In response to receiving the first memory request, the memory controller may identify the region targeted by the first memory request. Then, the memory controller may retrieve parameters corresponding to the identified region from the table and process the first memory request based on the values of the retrieved parameters. After block725, method700may end.

Turning now toFIG. 8, one embodiment of a method800for changing the cell level mode of a logical memory address region is shown. Any of the various systems or apparatuses described herein may be configured to implement method800. An operating system may detect a first condition for changing the cell level mode of a first logical memory address region (block805). In one embodiment, the first condition may be a change in the characteristics of a first software application which is mapped to the first logical memory address region. For example, the first application may request a reduction in latency for a plurality of memory requests. Alternatively, the first application may request an increase in the size of the first logical memory address region. Other conditions for changing the cell level mode of the first logical memory address region are possible and contemplated.

Responsive to detecting the first condition, the processor may change the cell level mode of the first logical memory address region (block810). For example, the processor may increase the number of bits per cell (e.g., from 1 to 2). Alternatively, the processor may decrease the number of bits per cell (e.g., from 4 to 2). Responsive to changing the cell level mode, the processor may calculate a new size of the first logical memory address space (block815). For example, if the number of bit cells is increased from 1 to 2, then the size of the first logical memory address space may double. Next, the processor may program a logical memory address region table in the memory controller with the new size of the first logical memory address space (block820). After block820, method800may end.

Referring now toFIG. 9, one embodiment of a method900for modifying a logical memory address region is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. It should be noted that in various embodiments of the method described below, one or more of the elements described may be performed concurrently, in a different order than shown, or may be omitted entirely. Other additional elements may also be performed as desired. Any of the various systems or apparatuses described herein may be configured to implement method900.

A host operating system (OS) may generate a change request to change one or more parameters of a logical memory address region (block905). The change request may involve changing one or more of the start address, region size, cell-level mode, physical-to-device mapping scheme, address masks, access permissions, wear-leveling data, encryption settings, compression settings, or other parameters of the logical memory address region. The host OS may send the change request to the memory controller (block910). The validation unit of the memory controller's control logic may determine if the change request is valid based on characteristics of the underlying memory device (conditional block915). For example, if the change request specifies changing the cell level mode to 4 bits per cell but the underlying memory device does not support 4 bits per cell, then the change request is invalid. Or, if the change request specifies a physical-to-device mapping that utilizes 32 banks, but the underlying memory device has 16 banks, then the change request is invalid.

If the validation unit determines that the change request is valid (conditional block915, “yes” leg), then the memory controller may perform the change(s) specified in the change request (block920). Then, the memory controller may notify the host OS that the change(s) were performed (block925). If the validation unit determines that the change request is invalid (conditional block915, “no” leg), then the memory controller may prevent the change(s) from being performed (block930). Then, the memory controller may notify the host OS that the change request was invalid (block935). After blocks925and935, method900may end.

Turning now toFIG. 10, one embodiment of a method1000for determining the priorities of requests is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. It should be noted that in various embodiments of the method described below, one or more of the elements described may be performed concurrently, in a different order than shown, or may be omitted entirely. Other additional elements may also be performed as desired. Any of the various systems or apparatuses described herein may be configured to implement method1000.

A memory controller may receive a plurality of requests from one or more processors (block1005). The memory controller may store the plurality of requests in one or more queues (block1010). Next, for each request, the memory controller may determine which logical memory address region is targeted by the request (block1015). Then, for each logical memory address region targeted by a request, the memory controller may determine the priority of the logical memory address region from the logical memory address region table (block1020). Next, the memory controller may assign a priority to each request based on the priority of the region targeted by the request (block1025). Then, the memory controller may process the requests in an order determined by the assigned priorities (block1030). After block1030, method1000may end.

Referring now toFIG. 11, one embodiment of a method1100for assigning a logical memory address region to a memory device is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. It should be noted that in various embodiments of the method described below, one or more of the elements described may be performed concurrently, in a different order than shown, or may be omitted entirely. Other additional elements may also be performed as desired. Any of the various systems or apparatuses described herein may be configured to implement method1100.

An operating system (OS) may receive a signal indicating that the installation of a new memory device has been detected (block1105). In response to receiving the signal, the OS may retrieve a capabilities table from the new memory device (block1110). The capabilities table may include information specifying the underlying memory technology and the supported capabilities of the new memory device. Next, the OS may map one or more logical memory address region(s) to the new memory device (block1115). Then, the OS may generate a plurality of attributes for the one or more logical memory address region(s) mapped to the new memory device based on the retrieved capabilities table (block1120). Next, the OS may program a logical memory address region table with the plurality of attributes generated for the one or more logical memory address region(s) (block1125). Then, the OS may assign one or more applications to each of the one or more logical memory address region(s) based on one or more attributes of the plurality of attributes (block1130). After block1130, method1100may end.

Turning now toFIG. 12, another embodiment of a method1200for changing the cell level mode of a logical memory address region is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. It should be noted that in various embodiments of the method described below, one or more of the elements described may be performed concurrently, in a different order than shown, or may be omitted entirely. Other additional elements may also be performed as desired. Any of the various systems or apparatuses described herein may be configured to implement method1200.

An operating system may detect a first condition for changing the cell level mode of a first logical memory address region (block1205). Next, the operating system may prepare an empty target region for storing the existing data of the first logical memory address region (block1210). Then, the data may be copied from the first logical memory address region to the new region (block1215).

Next, the processor may change the cell level mode of the first logical memory address region (block1220). Responsive to changing the cell level mode, the processor may calculate a new size of the first logical memory address space (block1225). Next, the processor may program a logical memory address region table in the memory controller with the new size of the first logical memory address space (block1230). Then, the operating system may optionally copy the data back to the first logical memory address region from the new region (block1235). Alternatively, the operating system may just maintain the data in the new region and access the data from the new region rather than copying the data back to the first logical memory address region. In a further embodiment, the operating system may maintain a first portion of the data in the new region and copy a second portion of the data back to the first logical memory address region. After block1235, method1200may end.

In various embodiments, program instructions of a software application may be used to implement the methods and/or mechanisms previously described. The program instructions may describe the behavior of hardware in a high-level programming language, such as C. Alternatively, a hardware design language (HDL) may be used, such as Verilog. The program instructions may be stored on a non-transitory computer readable storage medium. Numerous types of storage media are available. The storage medium may be accessible by a computing system during use to provide the program instructions and accompanying data to the computing system for program execution. The computing system may include at least one or more memories and one or more processors configured to execute program instructions.