US20160232103A1

Block storage apertures to persistent memory

Claim Score by NHIP

Abstract

Apparatus and methods for accessing a non-volatile memory (NVM) device in a computer system that includes at least one host processor and at least one memory bus. The NVM device is communicably coupleable to the memory bus through an NVM device controller, thereby allowing the host processor to access persistent data storable within the NVM device by issuing one or more memory load/store commands to the NVM device controller over the memory bus. Because the NVM device controller includes at least one block window or aperture that defines at least one address range for accessing the persistent data storable within the NVM device, the computer system can exploit the full capacity of the NVM device without being unduly constrained by physical addressing limits imposed by the host processor, or by limits imposed by an operating system executed by the host processor.

US20160232103A1, drawing sheet 1 — Sheet 1 of 11

Term

Projected expiry 26 September 2033.

20 claims: 3 independent, 17 dependent

26
Broadest claimClaim Score 55, average(NHIP)A method of accessing block data storable within a non-volatile memory (NVM) device in a computer system, the computer system including at least one host processor and at least one memory bus, the method comprising:receiving, at a controller over the memory bus, at least one first command from the host processor, the first command including one of a memory load command and a memory store command, the first command further including a logical address, the controller including at least one block window defining at least one address range for accessing the block data storable within the NVM device;translating, by the controller, the logical address included in the first command to a physical address within the NVM device, the logical address conforming to at least a portion of the address range defined by the block window;andaccessing, by the controller, the block data at the physical address within the NVM device.
40
A controller for accessing block data storable within a non-volatile memory (NVM) device, the controller being communicably coupleable to at least one host processor over at least one memory bus, comprising:a least one block window defining at least one address range for accessing the block data storable within the NVM device;at least one command register, the command register being operative to receive, over the memory bus, at least one first command from the host processor, the first command including one of a memory load command and a memory store command, the first command having a logical address including a logical offset address;a plurality of control registers including at least a plurality of base address registers, the plurality of base address registers containing a plurality of logical base addresses, respectively, each of the respective logical base addresses corresponding to a predetermined portion of the address range defined by the block window;andat least one internal processor operative to execute at least one program out of at least one memory: to select one of the plurality of base address registers based at least on the logical address from the first command;to translate the logical base address contained in the selected base address register and the logical offset address to a physical address within the NVM device;andto access the block data at the physical address within the NVM device.
45
A computer-readable storage medium including executable instructions for accessing block data storable within a non-volatile memory (NVM) device in a computer system, the computer system including at least one host processor and at least one memory bus, the computer-readable storage medium comprising executable instructions:to receive, over the memory bus, at least one first command from the host processor, the first command including one of a memory load command and a memory store command, the first command further including a logical address, at least one block window defining at least one address range for accessing the block data storable within the NVM device;to translate the logical address to a physical address within the NVM device, the logical address conforming to at least a portion of the address range defined by the block window;andto access the block data at the physical address within the NVM device.

Independent claims3

51 paragraphs in 3 sections, as filed

BACKGROUND

In a conventional computer system, a block storage device including non-volatile memory can be communicably coupled to a block storage device controller, which, in turn, can be communicably coupled to a processor by a system bus. Such a system bus is typically implemented as a Peripheral Component Interconnect express (PCIe) bus, allowing the processor to access block data storable within the block storage device by issuing one or more input/output (I/O) commands to the block storage device controller over the PCIe bus. Having received an I/O command from the processor over the PCIe bus, the block storage device controller can perform I/O processing including one or more direct memory access (DMA) operations to access the block data storable in the block storage device, and ultimately send a signal to the processor over the PCIe bus to signal completion of the I/O processing. However, such I/O processing performed by the block storage device controller in conjunction with the PCIe bus can cause latency in the processing of block write/read operations in such a conventional computer system.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute part of this specification, illustrate one or more embodiments described herein, and, together with the Detailed Description, explain these embodiments. In the drawings:

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an exemplary apparatus for accessing, in a computer system, at least one non-volatile memory (NVM) device, which, in conjunction with an NVM device controller, can he collectively viewed by the computer system as a block storage device, in accordance with the present application;

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating the NVM device controller included in the apparatus of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram illustrating an exemplary block window, a plurality of exemplary control registers, an exemplary address translation component, and an exemplary media management translation table included in the NVM device controller of <figref idref="DRAWINGS">FIG. 2</figref>;

<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram illustrating an exemplary method of operating the NVM device controller of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram of an exemplary computer system in which the NVM device controller of <figref idref="DRAWINGS">FIG. 2</figref> may be employed;

<figref idref="DRAWINGS">FIG. 6a </figref>is a block diagram illustrating an exemplary alternative embodiment of the NVM device controller of <figref idref="DRAWINGS">FIG. 2</figref>, including an exemplary mailbox for use by a host processor in issuing and monitoring one or more commands, such as memory load/store commands, sent by the host processor to the NVM device controller over a memory bus;

<figref idref="DRAWINGS">FIG. 6b </figref>is a diagram illustrating an exemplary op-code format associated with a respective command, an exemplary write protect bit associated with the op-code format, and an exemplary input payload format for use b a host processor in issuing the respective command to an NVM device controller us in the mailbox of <figref idref="DRAWINGS">FIG. 6</figref>a;

<figref idref="DRAWINGS">FIG. 6c </figref>is a diagram illustrating an exemplary status code format associated with respective command, and an exemplary output payload format for use by a host processor in monitoring completion of the respective command using the mailbox of <figref idref="DRAWINGS">FIG. 6</figref>a; and

<figref idref="DRAWINGS">FIGS. 7a-7b </figref>depict a flow diagram illustrating an exemplary method of issuing a command to an NVM device controller over a memory bus, and monitoring a status of completion of the command by a host processor using the mailbox of <figref idref="DRAWINGS">FIG. 6</figref>a.

DESCRIPTION OF EMBODIMENTS

Apparatus and methods are disclosed for accessing at least one non-volatile memory (NVM) device computer system that includes it least one host processor and at least one memory bus. In the disclosed apparatus and methods, the NVM device is communicably coupleable to the memory bus through an NVM device controller, thereby allowing the host processor to access persistent data storable within the NVM device by issuing one or more memory load/store commands to the NVM device controller over the memory bus. The computer system in conjunction with the host processor can implement a block storage driver, and the NVM device in conjunction with the NVM device controller can be collectively viewed by the computer system as a block storage device. Because the NVM device controller includes at least one block window (such a block window is also referred to herein as an “aperture”) that defines at least one address range for accessing one or more blocks of the persistent data storable within the NVM device, the computer system can as exploit, with reduced la envy full capacity of the NVM device without being unduly constrained by physical addressing limits imposed by the host processor, or by limits imposed by an operating system (OS) executed by the host processor.

<figref idref="DRAWINGS">FIG. 1</figref> depicts an illustrative embodiment of an exemplary apparatus 100 for accessing at least one NVM device in a computer system, in accordance with the present application. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the apparatus 100 includes a host processor 101, and one or more NVM device controllers 102.1-102.n (also referred to herein as “NVM controllers”) communicably coupled to the host, processor 101 by one or more memory buses 103.1-103.n, respectively As further shown in <figref idref="DRAWINGS">FIG. 1</figref>, one or more NVM devices can be communicably coupled to each of the NVM controllers 102.1-102.n. For example, one or more NVM devices 104.1-104.m can be communicably coupled to the NVM controller 102.1, which, in turn, is communicably coupled to the host processor 101 via the memory bus 103.1. Likewise, one or more NVM devices 106.1-106.p can be communicably coupled to the NVM controller 102.n, which, in turn, is communicably coupled to the host processor 101 via the memory bus 103.n.

In the exemplary apparatus 100 of <figref idref="DRAWINGS">FIG. 1</figref>, the host processor 101 can he implemented using one or more processors, one or more multi-core processors, and/or any other suitable processor or processors. Further, each of the NVM devices 104.1-104.m, 106.1-106.p can include non-volatile memory (NVM) such as NAND or NOR flash memory that uses a single bit per memory cell, multi-level cell (MLC) memory, for example, NAND flash memory with two bits per cell, polymer memory, phase-change memory (PCM), nanowire-based charge-trapping memory, ferroelectric transistor random access memory (FeTRAM), 3-dimensional cross-point memory, non-volatile memory that uses memory resistor (memristor) technology, or any other suitable non-volatile memory, NVM device, or persistent data storage medium.

<figref idref="DRAWINGS">FIG. 2</figref> depicts an exemplary NVM controller 202 that can be employed in the apparatus 100 of <figref idref="DRAWINGS">FIG. 1</figref>. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the NVM controller 202 includes at least one block window (aperture) 208, a plurality of control registers 212, an address translation component 214, a media management translation table 216, an optional encryption component 218, and an optional decryption component 220. As further shown in <figref idref="DRAWINGS">FIG. 2</figref>, an NVM device 204 is communicably coupled to the NVM controller 202, which, in turn, is communicably coupleable to the host processor 101 (see <figref idref="DRAWINGS">FIG. 1</figref>) via a memory bus 203.

In the exemplary NVM controller 202 of <figref idref="DRAWINGS">FIG. 2</figref>, the aperture 208 defines an address range for accessing one or more blocks of persistent data storable within the NVM device 204. The plurality of control registers 212 can include a plurality of command registers 0-q, a plurality of status registers 0-q, and a plurality of memory-mapped base address registers 0-q containing a. plurality logical base addresses, respectively. Each of the plurality of memory-mapped base address registers 0, 1, . . . q corresponds to a predetermined portion of the address range defined by the aperture 208. Further, the plurality of status registers 0-q are associated with the plurality of command registers 0-q, respectively, and the status register/command register pairs 0,0, 1,1, . . . q,q are, in turn, associated with the plurality of memory-mapped base address registers 0-q, respectively.

The address translation component 214 is operative to translate one or more logical addresses within the address range defined by the aperture 208 to actual physical addresses within a valid address range for a block write to (or a block read front) the NVM device 204, based at least on information provided by the host processor 101. The NVM controller 202 can employ the media management translation table 216 for performing wear leveling operations and/or enforcing endurance limits for the NVM device 204 (e.g., an NVM device including flash memory). The NVM controller 202 can further employ the encryption component 218 for encrypting block data to be written to the NVM device 204, as well as the decryption component 220 for decrypting block data to be read from the NVM device 204.

In an exemplary mode of operation, the host processor 101 (see <figref idref="DRAWINGS">FIG. 1</figref>) can access persistent data storable within the NVM device 204 (see <figref idref="DRAWINGS">FIG. 2</figref>) by issuing one or more memory load/store commands to the NVM controller 202 (see <figref idref="DRAWINGS">FIG. 2</figref>) over the memory bus 20$ (see <figref idref="DRAWINGS">FIG. 2</figref>). In this exemplary mode of operation, the host processor 101 can configure the NVM controller 202 for performing a block write (BW) to the NVM device 204 by translating a specified BW address within its address space to a logical SW address within the address range defined by the aperture 208 (see <figref idref="DRAWINGS">FIG. 2</figref>). The logical BW address can be expressed in terms of a logical BW base address and a logical SW offset address. The host processor 101 can select an available aperture within the NVM controller 202 such as the aperture 208) by addressing the respective aperture 208 directly over the memory bus 203.

Having configured the NVM controller 202 for performing the desired block write operation to the NVM device 204, the host processor 101 can issue a memory store command over the memory bus 203 to the NVM controller 202. The memory store command provides at least the logical SW base address and the logical SW offset address, which defines a relative offset from the logical SW base address. The host processor 101 writes the memory store command to a selected one of the plurality of command registers 0-q, based at least on the logical BW base/offset address provided via the memory store command. In response to the memory store command issued. by the host processor 101, the NVM controller 202 selects the memory-mapped base address register 0, 1, . . . q associated with the status register/command register pair 0,0, 1,1, . . . q,q that includes the selected command register 0, 1, . . . q. Further, the NVM controller 202 receives block data to be written to the NVM device 204 at the relative offset from the logical SW base address within the address range of the aperture 208.

The address translation component 214 (see <figref idref="DRAWINGS">FIG. 2</figref>) within the NVM controller 202 receives the logical base address contained in the selected base address register 0,1, . . . , q, receives the block data received at the relative offset from the logical 8W base address within the address range of the aperture 208, and translates the logical base address and the logical BW offset address to an actual physical address of a block (the block 204a) within the NVM device 204. The NVM controller 202 can check the translated address to determine, whether it conforms to a valid address range for a block write to the NVM device 204. In the event the translated address does not conform to a valid address range for a block write to the NVM device 204, the NVM controller 202 can set an error flag in the status register 0, 1, . . . , q associated with the selected command register 0, 1, . . . , q. In the event the translated address conforms to a valid address range for a block write to the NVM device 204, the NVM controller 202 is successfully configured for performing the desired block, write operation to the NVM device 204.

The NVM controller 202 can employ the media management translation table 216 to perform wear-leveling operations, and to enforce endurance limits for the NVM device 204, as desired and/or required. The NVM controller 202 can further employ the encryption component 218 to encrypt the block data to be written to the block 204a of the NVM device 204, as desired and/or required. The NVM controller 202 can then write the block data to the actual physical address of the block 204a. At the completion of the block write to the NVM device 204, the host processor 101 can read, over the memory bus 203, the status register 0, 1, . . . , q associated with the selected command register 0, 1, . . . , q to check the error status of the block write Operation.

In this exemplars mode of operation, the host processor 101 (see <figref idref="DRAWINGS">FIG. 1</figref>) can further configure the NVM controller 202 (see <figref idref="DRAWINGS">FIG. 2</figref>) for performing a block read (BR) from Me NVM device 204 (see <figref idref="DRAWINGS">FIG. 2</figref>) by translating a specified BR address within its address space to a logical BR address within the address range defined by the aperture 208. The logical BR address can be expressed in terms of a logical BR base address and a logical BR offset address. As described herein with reference to the block write operation, the host processor 101 can select an available aperture within the NVM controller 202 (such as the aperture 208) by addressing the respective aperture 208 directly over the memory bus 203.

Having configured the NVM controller 202 for performing the desired block read operation from the NVM device 204, the host processor 101 can issue a memory load command over the memory bus 203 to the NVM controller 202. The memory load command provides at least the logical BR base address and the logical BR offset address, which defines a relative offset from the logical BR base address. The host processor 101 writes the memory load command to a selected one of the plurality of command registers 0-q, based at least on the logical BR base/offset address provided via the memory load command. In response to the memory load command issued by the host processor 101, the NVM controller 202 selects the memory-mapped base address register 0, 1, . . . , q associated with the status register/command register pair 0,0, 1,1, . . . , q,q that includes the selected command register 0, 1, . . . , q.

The address translation component 214 receives the logical base address from the selected base address register 0, 1, . . . , q, receives the logical BR offset address provided via the memory load command, and translates the logical base address and logical BR offset address to an actual physical address of a block (e.g., the block 204a) within the NVM device 204. The NVM controller 202 can check the translated address to determine whether it conforms to a valid address range for a block read from the NVM device 204. In the event the translated address does not conform to is valid address range for a block read from the NVM device 204, the NVM controller 202 can set an error flag in the status register 0, 1, . . . , q associated with the selected command register 0, 1, . . . , q. In the event the translated address conforms to a valid address range for a block read from the NVM device 204, the NVM controller 202 is successfully configured for performing the desired block read operation from the NVM device 204.

The NVM controller 202 can employ the decryption component 220 to decrypt the block data to be read from the block 204a of the NVM device 204, as desired and/or required.

The NVM controller 202 can then read the block data from the actual physical address of the block 204a. At the completion of the block read from the NVM device 204, the host processor 101 can read, over the memory bus 203, the status register 0, 1, . . . , q associated with the selected command register 0, 1, . . . , q to check the error status of the block read operation.

By allowing the host processor 101 to access persistent data storable within the

NVM device 204 by issuing one or more memory load/store commands to the NVM controller 202 over the memory bus 203, in which the NVM controller 202 includes the aperture 208 that defines an address range for accessing one or more blocks of the persistent data storable within the NVM device 204, a computer system can advantageously exploit, with reduced latency, the full capacity of the NVM device 204 without being unduly constrained by physical addressing limits of the host processor 101, or by limits imposed by the OS executed by the host processor 101.

The operation of an NVM controller for translating one or more logical addresses within an address range defined by an aperture to actual physical addresses of one or more blocks within an NVM device will he further understood with reference to the following illustrative example and <figref idref="DRAWINGS">FIG. 3</figref>. As shown in <figref idref="DRAWINGS">FIG. 3</figref>, an NVM controller 302 can include a Monk window (aperture) 308, a plurality of control registers 312 including a plurality of command registers 0-31, a plurality of status registers 0-31, and a plurality of memory-Mapped base address registers 0-31 containing a plurality logical base addresses, respectively, an address translation component 314, and a media management translation table 316. Each of the plurality of memory-mapped base address registers 0, 1, . . . , 31 corresponds to a predetermined portion of the address range defined by the aperture 308. Further, the plurality of status registers 0-31 are associated with the plurality of command registers 0-31, respectively, and the status register/command register pairs 0,0, 1,1, . . . , 31,31 are, in turn, associated with the plurality of memory-mapped base address registers 0-31, respectively.

In this illustrative example, the aperture 308 is configured to support a block size of 256 kilobytes (KB). It is noted, however, that the aperture 308 may alternatively be configured to support a block size of 16 KB, 64 KB, 128 KB, 512 KB, 1 megabyte (MB), 2 MB, 4 MB, or any other suitable block size. Each sub-block within the block size of 256 KB is defined herein as 1/32 of the block size of 256 KB (i.e., 8 KB), or any other suitable sub-block size. Each of the plurality of memory-mapped base address registers 0-31 is therefore configured to correspond to 8 KB of the address range 0-256 KB) defined by the aperture 308. Specifically, the base address register 0 is configured to contain a 0th logical base address covering 0-8 KB of the address range defined b the aperture 308, the base address register 1 is configured to contain a logical base address covering 8-16 KB of the address range defined by the aperture 308, the base address register 2 is configured to contain a 2nd logical base address covering 16-24 KB of the address range defined by the aperture 308, and so on up to the base address register 31, which is configured to contain a logical base address covering 248-256 KB of the address range defined by the aperture 308.

With reference to this illustrative example, a memory load/store command issued by the host processor 101 (see <figref idref="DRAWINGS">FIG. 1</figref>) to the NVM controller 302 (see <figref idref="DRAWINGS">FIG. 3</figref>) over a memory bus 303 (see <figref idref="DRAWINGS">FIG. 3</figref>) can provide a logical base address and a logical offset address for use in writing block data to or reading block data from, a block within the NVM device 204 (see <figref idref="DRAWINGS">FIG. 2</figref>). Such a logical base address can be represented by the logical base address “X”, and therefore the address range defined by the aperture 308 can be expressed as ranging from the logical base address X to the logical address X+256 KB (see <figref idref="DRAWINGS">FIG. 3</figref>). Further, an exemplary relative offset from the logical base address X can be expressed as “8 KB” (plus a cache line offset, if any), or an other suitable relative offset. Such a cache line can correspond to 64 bytes (B), or any other suitable number of bytes.

For example, the host processor 101 can configure the N \TM controller 302 for performing a block write. (BW) to the NVM device 204 by issuing an exemplary command that conforms to the following format: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0033">Store 0x0000 1200 0008 1000 to 0x8804 1000, in which “0x0000 1200 0008 1000” corresponds to the block address that is to he accessed through the, aperture 308, “0x8804 0000” corresponds to the base address of the command registers 0-31, and “0x1000” is the offset corresponding to the command register 1, which is associated with the base address register 1. The host processor 101 can hen access the block address by issuing one or more memory load/store commands, specifying one or more accesses to the following: </li><li id="ul0002-0002" num="0034">0x0000 0000 4800 2000, in which “0x0000 0000 4800 0000” corresponds to the logical base address “X” of the aperture 308, and “0x2000” corresponds to the 1st logical base a(dress contained in the base address register 1. As noted above, in this illustrative example, the 1st logical base address, namely, 0x2000, covers 8-16 KB of the address range define by the aperture 308. </li></ul></li></ul>

Accordingly, the memory load/store command issued by the host processor 101 to the NVM controller 302 over the memory bus 303 can provide a logical base/offset address that can be represented by the term “X+8 KB” (plus a cache line offset, if any), which conforms to the address range, “X” to “X+256 KB”, defined by the aperture 308. The host processor 101 can write the memory load/store command to a selected one of the plurality or command registers 0-31, e.g., the command register 1, based at least on the logical base offset address, X+8 KB (plus a cache line offset if any), provided via the memory load/store command.

The address translation component 314 receives the 1st logical base address from the selected base address register 1, receives an indication of the cache line offset, if any, from the aperture 308, and translates the 1st logical base address and the cache line offset, if any, to the actual physical address of the block within the NVM device 204. The NVM controller 302 can then write the block data to, or read the block data from, the actual physical address of the respective block.

An exemplary method of operating an NVM controller for writing block data to, or reading block data from, one or more blocks within NVM device is described below with reference to <figref idref="DRAWINGS">FIG. 4</figref>. As depicted in block 402, a memory load/store command is received at the NVM controller over a memory bus, in which the memory load/store command includes a logical address conforming to at least a portion of an address range defined by a block window (aperture) included in the NVM controller. As depicted in block 404, a representation of the logical address is translated to an actual physical address of the block within the NVM device. As depicted in block 406, a determination is made as to whether the translated address conforms to a valid address range for accessing the block within the NVM device. In the event the translated address conforms to a valid address range for accessing the block within the NVM device, the block data is written to, or read from, the actual physical address of the block within the e NVM device, as depicted in block 408. Otherwise, a status error flag is set, as depicted in block 410, and the exemplary method of operating the NVM controller ends.

<figref idref="DRAWINGS">FIG. 5</figref> depicts an exemplary computer system 500 that can be configured to implement apparatus and methods of the claimed invention. As shown in <figref idref="DRAWINGS">FIG. 5</figref>, the computer system. 500 can include at least one host processor 502 communicably coupled to at least one memory 504 by a system bus 514, and communicably coupled to an NVM device controller 520 by a memory bus 515. The computer system 500 can further include a keyboard 516 and a display 518 communicably coupled to the system bus 514, and at least one NVM device 512 communicably coupled to the NVM device controller 520. The NVM device controller 520 includes at least one processor 520a operative to execute at least one program out of at least one non-transitory storage medium, such as a memory 520b or any other suitable storage medium, to access persistent data storable in one or more blocks within the NVM device 512. The host processor 502 is operative to execute instructions stored on at least one non-transitory storage medium, such as the memory 504 or any other suitable storage medium, for performing various processes within the computer system 500, including one or more processes for controlling operations of the NVM device controller 520 The memory 504 can include one or more Memory components such as a volatile memory 510, which may be implemented as dynamic random access memory (DRAM) or any other suitable volatile memory. The memory 504 can also be configured to store an operating system (OS) 506 executable by the host processor 502, as well as one or more applications 508 that may be run by the OS 506. In response to a request generated by one of the applications 508, the host processor 502 can execute the OS 506 to perform desired data write/read operations on the volatile memory 510, and/or desired block write/read operations on the NVM device 512 via the NVM device controller 520.

It is noted that <figref idref="DRAWINGS">FIG. 5</figref> illustrates an exemplary embodiment of the computer system 500, and that other embodiments of the computer system 500 may include more apparatus components, or fewer apparatus components, than the apparatus components illustrated in <figref idref="DRAWINGS">FIG. 5</figref>. Further, the apparatus components may be arranged differently than as illustrated in <figref idref="DRAWINGS">FIG. 5</figref>. For example, in some embodiments, the NVM device 512 may be located at a remote site accessible to the computer system 500 via the Internet or any other suitable network. In addition, functions performed by various apparatus components contained in other embodiments of the computer system 500 may be distributed among the respective components differently than as described herein.

Having described the above exemplary embodiments of the disclosed apparatus and methods, other alternative embodiments or variations may be made. For example, it was described herein that an NVM device controller can include at least one block window (aperture) that defines at least one address range for accessing persistent data storable in one or more blocks within an NVM device. In an alternative embodiment, such an aperture can be implemented as a block window for reading block data from the NVM device, a block window for writing block data to the NVM device, and/or a write combining buffer for writing data to the NVM device with atomic write support.

It was also described herein that an NVM device controller can be configured to perform a block write operation to an NVM device by translating a logical block write address within an address range defined by an aperture to an actual physical address of a block within the NVM device. In an alternative embodiment, such a block write operation can be performed to copy data from volatile in such as dynamic random access memory (DRAM) to the NVM device over a memory bus with reduced latency.

It was further described herein that a host processor could access persistent data storable within an NVM device by issuing one or more memory load/store commands to an NVM device controller over a memory bus. As depicted in <figref idref="DRAWINGS">FIG. 6</figref>a, in one embodiment, such an NVM device controller 620 can include a processor 609, as well as at least one payload data storage 608 (also referred to herein as a/the “payload mailbox”), at least one command register 510.1, and at least one status register 610.2, which collectively can be employed to provide a cacheable, bidirectional, memory-mapped access path between the host processor 101 (see <figref idref="DRAWINGS">FIG. 1</figref>) and the NVM device controller 620 over a memory bus 603. For example, the NVM device controller 620 can be incorporated in a DIMM, a double data rate (DDR) DIMM, and/or a non-volatile (NV) DIMM. In this embodiment, the host processor 101 can issue commands and access payload data and status information (e.g., the status of command execution) over the memory bus 603 via a command interface, which is implemented in the NVM device controller 620 by the command register 610.1 (also referred to herein as the “mailbox command register”), the status register 610.2 (also referred to herein as the “mailbox status register”), and at least one address range 607 (also referred to herein as the “mailbox address range”) defined by the payload mailbox 608. The host processor 101 can issue such commands, as well as access such payload data and status information, via such a command interface using cacheable memory load/store commands issued in-band over the bidirectional access path implemented by the memory bus 603, which is configured to support slave operations performed by the NVM device controller 620.

<figref idref="DRAWINGS">FIG. 6b </figref>depicts an exemplary op-code format 660 associated with a respective memory load/store command, an exemplary write protect bit 662 associated with the respective memory load/store command, and an exemplary input payload format 664 for use by the host processor 101 (see <figref idref="DRAWINGS">FIG. 1</figref>) in issuing the respective memory load/store command, using the mailbox command register 610.1 and the mailbox address range 607 of <figref idref="DRAWINGS">FIG. 6</figref>a. As shown in <figref idref="DRAWINGS">FIG. 6</figref>b, the op-code format 660 can include a command code 660.1 (e.g., memory load command, memory store command), a payload type 660.2 (e.g., small payload, large payload), and an interrupt type 660.3 (e.g., low priority, high priority).

<figref idref="DRAWINGS">FIG. 6c </figref>depicts an exemplary status code format 670 associated with a respective memory load/store command, and an exemplary output payload format 672 for use by the host processor 101 (see <figref idref="DRAWINGS">FIG. 1</figref>) in monitoring completion of the execution of the respective memory load/store command, using the mailbox status register 610.2 and the mailbox address range 607 of <figref idref="DRAWINGS">FIG. 6</figref>a. As shown in <figref idref="DRAWINGS">FIG. 6</figref>c, the status code format 670 can include a status code 670.1 (e.g., command failure status code, command success results, error status), a command progress status 670.2 (e.g., command has started, command has completed, command is aborted), and a command success/failure status 670.3 (e.g., command was successful, command has failed, error flag).

An exemplary method of issuing a memory load/store command and monitoring completion of the memory load/store command, by a host processor using a mailbox, is described below with reference to <figref idref="DRAWINGS">FIGS. 7a</figref>-7b, as well as <figref idref="DRAWINGS">FIGS. 6a</figref>-6c. In one embodiment, this exemplary method may be initiated by a system management interrupt (SMI), and may therefore be implemented in a system management mode (SMM) as an OS independent mechanism.

As depicted in block 702 (see <figref idref="DRAWINGS">FIG. 7a</figref>), a determination is made, by the host processor 101, as to whether the memory load/store command to be issued by the host processor 101 requires data (e.g., block data) to be sent to the NVM device controller 620. In the event the memory load/store command requires data to he sent to the NVM controller 620, such data is sent, by the host processor 101 over the memory bus 603 using the input payload format 664, to at least a portion of the mailbox address range 607 defined by the payload mailbox 608, as depicted in block 704. As depicted in block 706 the memory load/store command is issued, by the host processor 101 over the memory bus 603 using the op-code format 660, to the NVM device controller 620, by writing the memory load/store command to the mailbox command register 610.1. As further depicted in block 706, the write protect bit 662 is set, by the host processor 101, to conform to a predetermined logic level (e.g., the write protect bit 662 may be set to a logical high level). As depicted in block 708, in response to the write protect hit 662 being set to a logical high level by the host processor 101, an SMI is generated by the NVM device controller 620 and subsequently handled by the SMM of the processor 609. For example, the SMM may be embodied as one or more basic input/output system (BIOS) services of the processor 609. It is noted that, once the write protect bit 662 is set by the host processor 101, the NVM device controller 620 write-protects one or more registers for the input payload from being further written to by the host processor 101.

While the NVM device controller 620 executes the memory load/store command, the input payload is copied by the NVM device controller 620 to its internal memory, the mailbox status register 610.2 is updated by the NVM device controller 620 using the status code format 670 to indicate that the input payload is being processed (e.g., the command progress status 670.2 indicates that the command has started), and the write protect bit 662 is cleared by the NVM device controller 620, as depicted in block 710. It is noted that, once the write protect bit 662 is cleared by the NVM device controller 620. the input payload register(s) are no longer write-protected from being written to by the host processor 101, thereby allowing the host processor 101 to issue another command, over the memory bus 603 to the NNW device controller 620 using the op-code format 660, before the execution of the current command has completed.

As depicted in block 712, the status of the execution of the memory load/store command is monitored by the host processor 101 by reading the mailbox status register 610.2, using the status code format 670. In the event the mailbox status register 610.2 has been updated by the NVM device controller 620 to indicate that the execution of the memory load/store command has completed (e.g., the command progress status 670.2 indicates that the command has completed), a determination is made, by the host processor 101 using the output payload format 672, as to whether the memory load/store command requires data (e.g., block data) to be accessed from the NVM device 204 via the NVM device controller 620, as depicted in block 714. In the event the memory load/store command requires data to be accessed by the host processor 101 via the NVM device controller 620, such data is accessed, by the host processor 101 over the memory bus 603 using the output payload format 672, from at least a portion of the mailbox address range 607 defined by the payload mailbox 608, as depicted in block 716. As depicted in block 718, a determination is made, by the host processor 101, as to whether the execution of the memory load/store command has completed successfully (e.g., the command progress status 670.2 indicates that the command was successful). In the event the memory load/store command has completed successfully, the data accessed using the output payload format 672 is processed by the host processor 101, as depicted in block 720. As depicted in block 722, upon completion of the processing of the data by the host processor 101, the processor 609 within the NVM device controller 620 exits the SMM.

Although illustrative examples of various embodiments of the disclosed subject matter are described, herein, one of ordinary skill in the relevant art will appreciate that other manners of implementing the disclosed subject matter may alternatively be used. In the preceding description, various aspects of the disclosed subject matter have been described. For purposes of explanation, specific systems, apparatus, methods, and configurations were set forth in order to provide a thorough understanding of the disclosed subject matter. However, it will be apparent to one skilled in the relevant art having the benefit of this disclosure that the subject matter may he practiced without the specific details described herein. In other instances, well-known features, components, and/or modules were omitted, simplified, or combined in order not to obscure the disclosed subject matter.

It is noted that the term “operative to”, as employed herein, means that a corresponding device, system, apparatus, etc., is able to operate, or is adapted to operate, for its desired functionality when the device, system, or apparatus is in its powered-on state. Moreover, various embodiments of the disclosed subject matter may be implemented in hardware, firmware, software, or some combination thereof, and may be described by reference to, or in conjunction with, program code such as instructions, functions, procedures, data structures, logic, application programs, design representations, and/or formats for simulation, emulation, and/or fabrication of a design, which when accessed by a machine results in the machine performing tasks, defining abstract data types or low-level hardware contexts, or producing a result.

It is further noted that the techniques illustrated in the drawing figures can be implemented using code and/or data. stored and/or executed on one or more computing de ices, such as general-purpose computers or computing devices. Such computers or computing devices store and communicate code and/or data (internally and/or with other computing devices over a network) using machine-readable media such as machine readable storage media (e.g., magnetic disks, optical disks, random access memory (RAM), read only memory (ROM), flash memory devices, phase-change memory) and machine readable communication media (e.g., electrical, optical, acoustical, or other form of propagated signals such as carrier waves, infrared signals, digital signals, etc.).

No element, operation, or instruction employed herein should be construed as critical or essential to the application unless explicitly described as such. Also, as employed herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is employed. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

It is intended that the invention not be limited to the particular embodiments disclosed herein, but that the invention will include any and all particular embodiments and equivalents falling within the scope of the following appended claims.

Contents3

Every citation, both ways

Citations
Document	Relation	Office	Cited during
US10891239B2	Cited by	United States of America	Applicant
US10402112B1	Cited by	United States of America	Applicant
US11042307B1	Cited by	United States of America	Applicant
US10503409B2	Cited by	United States of America	Applicant
US11385833B2	Cited by	United States of America	Applicant
US11416365B2	Cited by	United States of America	Applicant
US10564856B2	Cited by	United States of America	Applicant
US11556277B2	Cited by	United States of America	Applicant
US11734115B2	Cited by	United States of America	Applicant
US10664181B2	Cited by	United States of America	Applicant
US11494115B2	Cited by	United States of America	Applicant
US10523743B2	Cited by	United States of America	Applicant
US11200337B2	Cited by	United States of America	Applicant
US11200114B2	Cited by	United States of America	Applicant
US11422931B2	Cited by	United States of America	Applicant
US11068409B2	Cited by	United States of America	Applicant
US11768709B2	Cited by	United States of America	Applicant
US10795586B2	Cited by	United States of America	Applicant
US11816043B2	Cited by	United States of America	Applicant
US10908960B2	Cited by	United States of America	Applicant
US2018129437A1	Cited by	United States of America	Search report
US11132291B2	Cited by	United States of America	Applicant
US11036431B2	Cited by	United States of America	Applicant
US10509575B2	Cited by	United States of America	Search report
US11675714B2	Cited by	United States of America	Applicant
US11507499B2	Cited by	United States of America	Applicant
US10642757B2	Cited by	United States of America	Applicant
WO2018036394A1	Cited by	World Intellectual Property Organization (WIPO)	International search
US10761983B2	Cited by	United States of America	Search report
US10923156B1	Cited by	United States of America	Applicant
US11354200B2	Cited by	United States of America	Applicant
US10698686B2	Cited by	United States of America	Applicant
US10558366B2	Cited by	United States of America	Applicant
US2017206030A1	Cited by	United States of America	Search report
US11144250B2	Cited by	United States of America	Applicant
US10552070B2	Cited by	United States of America	Applicant
US10303601B2	Cited by	United States of America	Applicant
US11169873B2	Cited by	United States of America	Applicant
US10496548B2	Cited by	United States of America	Applicant
US11061751B2	Cited by	United States of America	Applicant
US11263132B2	Cited by	United States of America	Applicant
US11150986B2	Cited by	United States of America	Applicant
US11461262B2	Cited by	United States of America	Applicant
WO2020051531A1	Cited by	World Intellectual Property Organization (WIPO)	International search
US2019146918A1	Cited by	United States of America	Search report
US11106490B2	Cited by	United States of America	Applicant
US2019073132A1	Cited by	United States of America	Search report
CN113515414A	Cited by	China	Search report
US10496829B2	Cited by	United States of America	Applicant
US10871921B2	Cited by	United States of America	Applicant
US10789011B2	Cited by	United States of America	Applicant
US11061735B2	Cited by	United States of America	Applicant
US11372774B2	Cited by	United States of America	Applicant
US11126561B2	Cited by	United States of America	Applicant
US10642522B2	Cited by	United States of America	Applicant
US10921992B2	Cited by	United States of America	Applicant
US11567817B2	Cited by	United States of America	Applicant
CN111095223A	Cited by	China	Search report
US11461173B1	Cited by	United States of America	Applicant
US10977122B2	Cited by	United States of America	Applicant
US11099782B2	Cited by	United States of America	Applicant
US11218165B2	Cited by	United States of America	Applicant
US10496437B2	Cited by	United States of America	Applicant
US10976931B2	Cited by	United States of America	Applicant
US10761751B2	Cited by	United States of America	Applicant
US11783876B2	Cited by	United States of America	Applicant
US2017177496A1	Cited by	United States of America	Pre-grant
US11476874B1	Cited by	United States of America	Applicant
US11354233B2	Cited by	United States of America	Applicant
US10996886B2	Cited by	United States of America	Applicant
US10852948B2	Cited by	United States of America	Applicant
US11281575B2	Cited by	United States of America	Applicant
US11289137B2	Cited by	United States of America	Search report
US11080210B2	Cited by	United States of America	Applicant
US10423508B2	Cited by	United States of America	Applicant
US10067879B2	Cited by	United States of America	Search report
US11449455B2	Cited by	United States of America	Applicant
WO2019050613A1	Cited by	World Intellectual Property Organization (WIPO)	International search
US2019147923A1	Cited by	United States of America	Search report
US11487465B2	Cited by	United States of America	Applicant
US11093145B2	Cited by	United States of America	Applicant
US11579806B2	Cited by	United States of America	Applicant
US10872622B1	Cited by	United States of America	Applicant
US11726699B2	Cited by	United States of America	Applicant
US11693588B2	Cited by	United States of America	Search report
US11379127B2	Cited by	United States of America	Applicant
US11379155B2	Cited by	United States of America	Applicant
US10359954B2	Cited by	United States of America	Applicant
US10592164B2	Cited by	United States of America	Applicant
US11782843B2	Cited by	United States of America	Applicant
US2019146918A1	Cited by	United States of America	Search report
US11556462B2	Cited by	United States of America	Applicant
US10635602B2	Cited by	United States of America	Applicant
US10877898B2	Cited by	United States of America	Applicant
US11221956B2	Cited by	United States of America	Search report
US10678443B2	Cited by	United States of America	Applicant
US10831404B2	Cited by	United States of America	Applicant
US10303241B2	Cited by	United States of America	Applicant
US10922234B2	Cited by	United States of America	Applicant
US10884926B2	Cited by	United States of America	Applicant

Showing 100 of 114

8 members in 5 offices

This recordMember, by publication datePriority claim

Priority claims4

Priority claims
Document	Office	Kind	Date
2013061841	United States of America	W	2013-09-26
2013061841	United States of America	W	2013-09-26
PCTUS2013061841	–	–	–
WO2013US61841	–	–	–

Members8

Family members, oldest first
Document	Office	Kind
WO2015047266A1	World Intellectual Property Organization (WIPO)	A1	2015-04-02
KR20160024995A	Republic of Korea	A	2016-03-07
CN105706071A	China	A	2016-06-22
EP3049944A1	European Patent Office (EPO)	A1	2016-08-03
US2016232103A1	United States of America	A1	2016-08-11
EP3049944A4	European Patent Office (EPO)	A4	2017-06-14
KR101842621B1	Republic of Korea	B1	2018-03-27
EP3049944B1	European Patent Office (EPO)	B1	2022-01-12

82 transactions on the USPTO file

Abandoned after 2 non-final rejections, 2 final rejections and 1 RCE.

Non-final rejections: 2
Final rejections: 2
RCEs: 1
Appeals: 0

Over time

Point at a mark for the transaction

Transactions

Prosecution transactions, newest first
	Event	Code
2018-09-06	Mail Abandonment for Failure to Respond to Office ActionAbandonedMABN2	MABN2
2018-08-31	Aband. for Failure to Respond to O. A.AbandonedABN2	ABN2
2018-05-14	Electronic Information Disclosure StatementEIDS.	EIDS.
2018-05-14	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2018-05-01	Email NotificationEML_NTR	EML_NTR
2018-05-01	Mail Advisory Action (PTOL - 303)MCTAV	MCTAV
2018-04-25	Advisory Action (PTOL-303)CTAV	CTAV
2018-04-25	Information Disclosure Statement consideredIDSC	IDSC
2018-03-28	Date Forwarded to ExaminerFWDX	FWDX
2018-03-23	Response after Final ActionA.NE	A.NE
2018-02-14	Electronic Information Disclosure StatementEIDS.	EIDS.
2018-02-14	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2018-01-29	Email NotificationEML_NTR	EML_NTR
2018-01-29	Filing Receipt - CorrectedFLRCPT.C	FLRCPT.C
2018-01-26	Electronic ReviewELC_RVW	ELC_RVW
2018-01-25	Email NotificationEML_NTF	EML_NTF
2018-01-25	Mail Final Rejection (PTOL - 326)Final rejectionMCTFR	MCTFR
2018-01-22	Final RejectionFinal rejectionCTFR	CTFR
2018-01-08	Information Disclosure Statement consideredIDSC	IDSC
2017-12-04	Date Forwarded to ExaminerFWDX	FWDX
2017-11-20	Response after Non-Final ActionA...	A...
2017-10-27	Electronic Information Disclosure StatementEIDS.	EIDS.
2017-10-27	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2017-08-19	Electronic ReviewELC_RVW	ELC_RVW
2017-08-18	Email NotificationEML_NTF	EML_NTF
2017-08-18	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2017-08-11	Non-Final RejectionNon-final rejectionCTNF	CTNF
2017-08-10	Information Disclosure Statement consideredIDSC	IDSC
2017-08-01	Date Forwarded to ExaminerFWDX	FWDX
2017-08-01	Disposal for a RCE / CPA / R129AbandonedABN9	ABN9
2017-07-28	Electronic Information Disclosure StatementEIDS.	EIDS.
2017-07-28	Request for Continued Examination (RCE)RCEX	RCEX
2017-07-28	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2017-07-28	Workflow - Request for RCE - BeginBRCE	BRCE
2017-06-21	Email NotificationEML_NTR	EML_NTR
2017-06-21	Mail Advisory Action (PTOL - 303)MCTAV	MCTAV
2017-06-14	Interview Summary - Examiner Initiated - TelephonicEXET	EXET
2017-06-14	After Final Consideration Program Additional Consideration and/or updated searchAFAC	AFAC
2017-06-14	Advisory Action (PTOL-303)CTAV	CTAV
2017-06-07	Email NotificationEML_NTR	EML_NTR
2017-06-07	Email NotificationEML_NTR	EML_NTR
2017-06-07	Filing Receipt - ReplacementFLRCPT.R	FLRCPT.R
2017-06-07	Change in Power of Attorney (May Include Associate POA)PA..	PA..
2017-06-05	Correspondence Address ChangeC.AD	C.AD
2017-05-16	Date Forwarded to ExaminerFWDX	FWDX
2017-05-08	PILOT- Request for After Final Consideration ProgramRAFC	RAFC
2017-05-08	Response after Final ActionA.NE	A.NE
2017-03-06	Electronic ReviewELC_RVW	ELC_RVW
2017-03-06	Email NotificationEML_NTF	EML_NTF
2017-03-06	Mail Final Rejection (PTOL - 326)Final rejectionMCTFR	MCTFR
2017-02-09	Final RejectionFinal rejectionCTFR	CTFR
2016-12-05	Date Forwarded to ExaminerFWDX	FWDX
2016-11-28	Response after Non-Final ActionA...	A...
2016-11-28	Request for Extension of Time - GrantedXT/G	XT/G
2016-08-12	Email NotificationEML_NTR	EML_NTR
2016-08-11	Application ready for PDX access by participating foreign officesCCRDY	CCRDY
2016-08-11	PG-Pub Issue NotificationPG-ISSUE	PG-ISSUE
2016-06-29	Electronic ReviewELC_RVW	ELC_RVW
2016-06-28	Email NotificationEML_NTF	EML_NTF
2016-06-28	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2016-06-23	Non-Final RejectionNon-final rejectionCTNF	CTNF
2016-06-10	Information Disclosure Statement consideredIDSC	IDSC
2016-06-02	Case Docketed to Examiner in GAUDOCK	DOCK
2016-05-31	Application Is Now CompleteCOMP	COMP
2016-05-31	Application Dispatched from OIPEOIPE	OIPE
2016-05-05	Email NotificationEML_NTR	EML_NTR
2016-05-05	Email NotificationEML_NTR	EML_NTR
2016-05-05	Notice of DO/EO Acceptance MailedM903	M903
2016-05-05	Filing ReceiptFLRCPT.O	FLRCPT.O
2016-05-04	Sent to Classification ContractorPGPC	PGPC
2016-05-04	FITF set to YES - revise initial settingFTFS	FTFS
2014-09-17	Reference capture on IDSRCAP	RCAP
2014-09-17	Information Disclosure Statement (IDS) FiledM844	M844
2014-09-17	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2013-12-19	Incoming Letter Pertaining to the DrawingsLTDR	LTDR
2013-12-19	Preliminary AmendmentA.PE	A.PE
2013-12-19	371 Completion Date371COMP	371COMP
2013-12-19	Patent Term Adjustment - Ready for ExaminationPTA.RFE	PTA.RFE
2013-12-19	Applicants have given acceptable permission for participating foreignAPPERMS	APPERMS
2013-12-19	Cleared by OIPE CSRL194	L194
2013-12-19	Entity status set to undiscounted (initial default setting or status change)BIG.	BIG.
2013-12-19	Initial Exam Team nnIEXX	IEXX

2 legal events, as the office reported them to INPADOC

Over the term

Point at a mark for the event

Events

Legal events, newest first
	Event	Code
2018-08-31	Information on status: application discontinuationABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTIONSTCB	STCB
2015-01-05	AssignmentAS	AS