US 12,650,928 B1Grant

Cooperative storage device with host-accessible subdivisions

Issue Date:2026-06-09

•27 Claims

•11 Drawing Sheets

Abstract

This disclosure provides techniques hierarchical address virtualization within a memory controller and configurable block device allocation. By performing address translation only at select hierarchical levels, a memory controller can be designed to have predictable I/O latency, with brief or otherwise negligible logical-to-physical address translation time. In one embodiment, address transition may be implemented entirely with logical gates and look-up tables of a memory controller integrated circuit, without requiring processor cycles. The disclosed virtualization scheme also provides for flexibility in customizing the configuration of virtual storage devices, to present nearly any desired configuration to a host or client.

Metadata

Assignee

Radian Memory Systems, ILLC

Inventors

Robert Lercari
Alan Chen
Mike Jadon
Craig Robertson
Andrey V. Kuzmin

Application Information

Application Number:US 19/407,858

Filing Date:2025-12-03

Priority Date:2014-09-09

Art Unit:2135

Classifications

IPC:

G06F12/1009G06F3/06G06F12/02G06F12/109

Field of Search:

G06F 12/1009G06F 3/0616G06F 12/0246G06F 3/0688G06F 3/064G06F 12/109G06F 3/0662G06F 2212/7201G06F 3/0659G06F 2212/7202G06F 2212/1016G06F 2212/7205

Patent Drawings (11 sheets)

Description

Priority/Incorporation by Reference

[0001] This document is a continuation of U.S. Utility patent application Ser. No. 19/001,292, filed on Dec. 24, 2024, on behalf of first-named inventor Robert Lercari, which is a continuation of U.S. Utility patent application Ser. No. 18/412,906, filed on Jan. 15, 2024, on behalf of first-named inventor Robert Lercari (now U.S. patent Ser. No. 12/306,766), which in turn is a continuation of U.S. Utility patent application Ser. No. 18/140,938, filed on Apr. 28, 2023, on behalf of first-named inventor Robert Lercari (now U.S. patent Ser. No. 11/914,523), which in turn is a continuation of U.S. Utility patent application Ser. No. 17/377,754, filed on Jul. 16, 2021, on behalf of first-named inventor Robert Lercari (now U.S. patent Ser. No. 11/675,708), which in turn is a continuation of U.S. Utility patent application Ser. No. 17/213,015, filed on Mar. 25, 2021 (now U.S. patent Ser. No. 11/086,789), on behalf of first-named inventor Robert Lercari, which in turn is a continuation of U.S. Utility patent application Ser. No. 16/841,402, filed on Apr. 6, 2020, on behalf of first-named inventor Robert Lercari, which in turn is a continuation of U.S. Utility patent application Ser. No. 15/690,006, filed on Aug. 29, 2017 (now U.S. patent Ser. No. 10/642,748), which in turn is a continuation of U.S. Utility patent application Ser. No. 15/074,778, filed on Mar. 18, 2016 (now U.S. Pat. No. 9,785,572), which in turn is a continuation of U.S. Utility patent application Ser. No. 14/880,529, filed on Oct. 12, 2015 (now U.S. Pat. No. 9,542,118). U.S. Utility patent application Ser. No. 14/880,529 in turn claims the benefit of: U.S. Provisional Patent Application No. 62/199,969, filed on Jul. 31, 2015, on behalf of first-named inventor Robert Lercari for “Expositive Flash Memory Control;” U.S. Provisional Patent Application No. 62/194,172, filed on Jul. 17, 2015, on behalf of first-named inventor Robert Lercari for “Techniques for Memory Controller Configuration;” and U.S. Provisional Patent Application No. 62/063,357, filed on Oct. 13, 2014, on behalf of first-named inventor Robert Lercari for “Techniques for Memory Controller Configuration.” U.S. Utility patent application Ser. No. 14/880,529 is also a continuation in-part of U.S. Utility patent application Ser. No. 14/848,273, filed on Sep. 8, 2015, on behalf of first-named inventor Andrey V. Kuzmin for “Techniques for Data Migration Based On Per-Data Metrics and Memory Degradation,” which in turn claims the benefit of U.S. Provisional Patent Application No. 62/048,162, filed on Sep. 9, 2014, on behalf of first-named inventor Andrey V. Kuzmin for “Techniques for Data Migration Based On Per-Data Metrics and Memory Degradation.” The foregoing patent applications are each hereby incorporated by reference, as are US Patent Publication 2014/0215129, for “Cooperative Flash Memory Control,” and U.S. Utility patent application Ser. No. 14/047,193, filed on Oct. 7, 2013, on behalf of first-named inventor Andrey V. Kuzmin for “Multi-Array Operation Support And Related Devices, Systems And Software.”

Technical Field

[0002] The disclosure herein relates to non-volatile data storage and retrieval within semiconductor memory.

Brief Description of the Drawings

[0003] The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.

[0004] FIG. 1 illustrates an embodiment of a multi-modal flash memory device and its interconnection to a host system.

[0005] FIG. 2 illustrates an exemplary application and configuration of a flash device having a pseudo-expositive memory controller within a host system.

[0006] FIG. 3 illustrates an exemplary flash memory device in which discrete block devices may be configured and allocated as described in FIG. 2.

[0007] FIG. 4 illustrates an exemplary block device allocation and configuration within the flash device of FIG. 3 effected using the block device allocator described in reference to FIG. 2.

[0008] FIG. 5 illustrates a host perspective of the exemplary block device allocations and configurations presented in FIG. 4.

[0009] FIG. 6 illustrates an exemplary pair of block device configurations.

[0010] FIG. 7 illustrates exemplary generation of a physical block address in response to an incoming LBA.

[0011] FIG. 8 illustrates a conceptual implementation of an address generation module.

[0012] FIG. 9 illustrates exemplary virtualization of erase units within a four-die block device.

[0013] FIG. 10 demonstrates an exemplary sequence of operations coordinated between a pseudo-expositive flash memory controller and a host file server.

[0014] FIG. 11 illustrates forward (and reverse) compatibility between successive flash generations enable by a pseudo-expositive flash architecture provided by the teachings herein.

[0015] FIG. 12 illustrates detail regarding pseudo-physical geometry export options within a flash device having multi-plane flash dies.

[0016] FIG. 13 illustrates additional operations that may be managed by embodiments of pseudo-exposition.

[0017] FIG. 14 illustrates a memory controller integrated circuit (IC).

[0018] The subject matter defined by the enumerated claims may be better understood by referring to the following detailed description, which should be read in conjunction with the accompanying drawings. This description of one or more particular embodiments, set out below to enable one to build and use various implementations of the technology set forth by the claims, is not intended to limit the enumerated claims, but to exemplify their application to certain methods and devices. The description set out below exemplifies addressing schemes and supporting, methods, devices, structures and systems. Such techniques can be practiced in one embodiment by a host, in another embodiment by a memory controller (e.g., within a single drive or across multiple drives), in another embodiment by a flash memory device (e.g., die or integrated circuit) and in yet another embodiment by a host or memory controller cooperating with one or more other circuits. This disclosure also provides improved designs for a memory controller, host, memory devices, a memory system, a subsystem (such as a drive, e.g., a solid state drive or “SSD”), and associated circuitry, firmware and addressing methodology. The disclosed techniques can also be implemented in software or instructions for fabricating an integrated circuit (e.g., a circuit design file or field programmable gate array or “FPGA” configuration). While the specific examples are presented, particularly in the context of flash memory, the principles described herein may also be applied to other methods, devices and systems as well.

Detailed Description

[0019] A memory controller that subdivides an incoming memory address into multiple discrete address fields corresponding to respective hierarchical groups of structural elements within a target nonvolatile semiconductor memory system and in which at least one of the discrete address fields constitutes a virtual address for the corresponding physical element within the structural hierarchy is disclosed in various embodiments. Through this hierarchical subdivision, the virtual address portion of the incoming memory address is ensured to resolve to an element within the physical bounds of a larger (hierarchically-superior) structure, but may be freely mapped to any of the constituent physical elements of that larger structure. Accordingly, a host requestor may issue logical memory addresses with address fields purposefully specified to direct read, write and maintenance operations to physically distinct structures within the memory system in a manner that limits performance-degrading conflicts while the memory controller remains free, by virtue of one or more virtualized address fields within the incoming logical addresses, to virtualize localized groups of physical structures and thus mask defective structural elements and swap operational structural elements into and out of service, for example, as they wear or otherwise require maintenance.

[0020] In other embodiments presented herein, the net storage volume of a nonvolatile semiconductor memory system is subdivided into discrete performance-isolated storage regions based on specified system requirements and underlying memory system geometry and performance characteristics, with each such storage region being mapped by an independent linear range of logical addresses. Accordingly, each performance-isolated storage region may be presented to one or more host access requestors as an independent block device (i.e., mass storage unit having a continuously mapped logical address space) so that the nonvolatile memory system may be perceived by that host as being constituted by multiple discrete block devices, each having its own performance characteristics and address space. Moreover, the mapping of the logical address space within a given block device, referred to herein as “address space layout,” may vary from one block device to another (e.g., sequential addresses within logical address ranges of respective block devices may be distributed within the structural hierarchy of the memory system in different order) to yield configurable and varied block device characteristics in terms of endurance and I/O bandwidth. Further, multiple different address space layouts may be applied within different “subspaces” of a given block device (i.e., discrete portions of the block device's address range) with, for example, addresses in one subspace being sequentially applied to structural elements at different hierarchical levels of the memory system in a different order than in another subspace. Also, in a number of embodiments, system requirements specified (e.g., by a user/system designer) in terms of block device capacity and performance metrics including, without limitation, read and write bandwidth requirements and minimum data transfer size required by the block device, are automatically translated into corresponding configuration and allocation of structural elements as necessary to meet the high-level requirements, with such configuration and allocation optionally being programmed directly into the nonvolatile memory subsystem and/or corresponding block device definition reported to a host access requestor. By this approach, a system designer may configure and allocate block devices according to performance requirements of the application at hand without having to resort to the complex and error-prone task of allocating and configuring numerous physical resources within the nonvolatile memory system individually. Moreover, in a number of embodiments, high-level performance requirements specified to configure and allocate block devices within a given memory subsystem may be used to enable forward-compatible allocation and configuration of like-performance block devices within next-generation memory subsystems and thus enable seamless memory subsystem replacement (with or without data migration) and/or supplement with next-generation technologies. These and other embodiments, features and benefits are described in greater detail below in reference to exemplary drawing figures.

[0021] The nonvolatile memory subsystem in which a number of embodiments are detailed herein is presented as a flash memory device forming in whole or part a solid state disk drive (SSD); the flash memory device can be hierarchically arranged in multiple wired signaling channels each coupled to multiple flash memory dies, with each die including numerous individually erasable storage units (“erase units” or erase blocks or flash blocks) distributed in one or more access planes, and with each erase unit including numerous pages constituted by a predetermined number of single-bit or multi-bit nonvolatile storage cells (i.e., channels, dies, erase units and pages constitute, for example and without limitation, respective hierarchical physical elements within the flash memory device). For example, in one embodiment, a memory controller within the flash memory system (e.g., within the drive or SSD) subdivides each incoming “logical block address” (LBA) into respective channel, die, erase unit and page address fields, any or all of which may be virtual addresses, and resolves a commanded read or write access to a specific channel indicated by the channel address field, a specific die indicated by the die address field, a specific erase unit indicated by the erase unit field (including possible resolution to two or more erase units in the case of multi-plane command sequences) and a specific page indicated by the page address field (including possible resolution to two or more pages in the case of a multi-page operation).

[0022] Numerous specific details relating to flash memory device technology including, for example and without limitation, erase granularity limited to whole erase units (a fundamental characteristic of flash memory), usage-induced storage cell wear (i.e., as program and erase cycles involve destructive charge-carrier passage through isolating oxide layers) and finite storage cell retention times (largely due to leakage from floating storage cells which increases as feature sizes shrink in successive device generations) and disparate data write (or “program”) timing and read timing constraints, bears on implementation and/or operational details of a number of embodiments presented below. In all cases, such details may change or be omitted when not required by the underlying memory technology. Thus, while the various embodiments presented herein are described in the context of flash memory devices, the structures and techniques disclosed are not so limited and may be applied with respect to any underlying memory technology wherever beneficial including both nonvolatile and volatile memory technologies.

[0023] FIG. 1 illustrates an embodiment of a multi-modal flash memory device (“flash device”) and its interconnection to a host system or device, referred to herein as the “host.” As shown, the flash device includes multiple flash memory dies coupled to a multi-modal flash memory controller (MC). It should be understood that the memory controller is depicted in multiple locations within the figure, to illustrate different modes of operation; the memory controller itself includes a mode register or other configuration circuit which, when programmed by the host or pre-programmed during or after flash device production, enables the flash device to be selectively operated in any one of at least four different memory control modes including a physical access mode 112, a linearly virtualized mode 114, a cooperative management mode 116, and a hierarchically virtualized mode 118.

[0024] In physical access mode, shown generally at 112, the flash device takes little or no autonomous action and instead merely executes read, write and erase requests at the direction of the host. Thus, the host is fully aware of the underlying flash device geometry (shown, in this conceptual example, as three flash memory dies each having five erase units) and issues a physical block address (PBA) with each read/write request—that is a memory address having a fixed, one-for-one correspondence to a logical storage block (e.g., smallest addressable unit of data storage) within the collective storage space formed by the constituent flash dies of the flash device. An address received by the memory controller from the host is substantially identical to the address transmitted from the memory controller to memory; that is, the physical access mode enables executions of flash memory input/output operations (IOPs) with theoretically minimal latency (i.e., no address translation is needed and the host can schedule IOPs in a manner that avoids resource conflicts due to full awareness of the underlying physical hardware and limitations thereof). In this mode, however, the host is burdened with numerous complex and hardware-specific media management tasks, including discovery and avoidance of failed structural elements (especially erase units and dies), leveling otherwise disparate wear between different erase units (“wear leveling”), reducing storage fragmentation (“garbage collection”) as the ratio of partially filled erase units to available continuous storage space rises, and refreshing (i.e., re-writing in a new location) data nearing its retention time limit (“scrubbing” aged data). Thus design and implementation of a host system needed to interact with and manage the flash memory in physical access mode can become tremendously complex and, making matters worse, may require substantial and expensive re-design as new generations of flash memory devices become available.

[0025] Still referring to FIG. 1, if physical access mode represents an extreme burdening of the host in return for potentially minimized IOP latency, the linearly virtualized mode shown at 114 represents the opposite extreme. In linearly virtualized mode, a flash translation layer (FTL) and media management engine are enabled within the memory controller to present the aggregate storage of the flash device (i.e., collective storage area within the three flash memory dies) to the host as a simple linear address range in which all media management operations are executed transparently (i.e., without host visibility or responsibility). While the FTL and under-hood media management tremendously simplifies host design and implementation, the cost of that simplicity is a substantial degradation of flash device performance and capacity. For example, because every logical block address issued by the host (e.g., LBA i−1, LBA i, LBA i+1, LBA i+2 as shown in FIG. 1) may map to any storage location within the flash device (e.g., any page within any erase unit within any die on any signaling channel within the flash device), translation time tends to be substantial and increases exponentially as flash capacity grows (i.e., in new generations of flash devices). Worse, because the mapping of logical block addresses to underlying storage locations is invisible to the host, the host is unable to avoid sequential issuance of logical block addresses that resolve to the same flash die, meaning that resource conflicts may arise at random. From the host perspective, the I/O latency (i.e., time required to complete an I/O) is simply unpredictable and may, at any instant, grow many times beyond the native operational time imposed by the underlying flash die hardware. This unpredictable latency is made even worse by the memory controller's autonomous scheduling of flash maintenance operations (i.e., garbage collection, wear-leveling, data scrubbing) each of which tends to involve numerous memory-controller-initiated write operations followed by one or more relatively slow erase operations and thus may dramatically increase the I/O latency perceived by the host.

[0026] Continuing with the linearly virtualized controller mode 114, the memory controller's responsibility for flash maintenance requires that it keep substantial storage regions in reserve. Even more space is typically reserved to reduce the probability of worst-case resource conflict scenarios (i.e., limit occurrence of system-buckling long-latency I/O events). As a result, the overall flash memory capacity made available to the host in linearly-virtualized mode (i.e., the space encompassed by the linear LBA range) is generally substantially less than the physical capacity of the device. This “overprovisioning” of the physical storage space to meet a host-desired capacity and performance is exacerbated by the need for nonvolatile storage of the ever-growing FTL translation table (i.e., growing as the flash device capacity is consumed, and growing with new generations of more capacious flash devices) within the nonvolatile flash storage itself.

[0027] Still referring to FIG. 1, the cooperative management mode shown at 116 achieves the performance advantages of physical access mode by exposing the underlying flash geometry to the host, but limits the host's flash management burden by gathering statistics needed to manage flash maintenance operations and by notifying the host when maintenance is required. The general approach is enumerated in the detail view of cooperative management mode and in which the host (1) requests and receives a physical geometry description from the memory controller (referred to herein as a “geometry export”) and then (2) defines an address assignment in which the linear block address range of the host file system is mapped directly onto the physical block address within the underlying flash storage. In the particular example shown, a defective and unavailable erase unit marked by ‘B’ is reported to the host by the memory controller and noted within the LBA-to-PBA address map.

[0028] Hierarchically virtualized mode, shown for example at 118, takes cooperative management mode a significant step forward by presenting to the host an idealized view of underlying physical structures within the flash memory device. That is, as in cooperative management mode, the host requests a physical geometry description from the memory controller, but the memory controller returns, instead of a true physical description with all attendant details regarding defective storage and other realities, an idealized or pseudo-physical description of the underlying geometry that enables abstraction of the underlying flash memory structures without loss of coherence with respect to boundaries between hierarchical structures. Thus, in the hierarchically-virtualized example shown, the memory controller informs the host that the aggregate flash storage is subdivided among three flash dies and that four erase units are available within each flash die, holding in reserve some number of erase units (or dies or any other resource likely to fail over time) as necessary to maintain a static idealized perspective of the underlying flash geometry for the host. Accordingly, despite the defective erase unit (‘B’) within the center flash die or even run-time detected failure of erase units within the other two flash dies, the host perceives a defect free set of physically extant dies and erase units therein. This pseudo-physical host perspective may be appreciated by comparing the host-perceived flash device architecture (three defect-free dies, each having four erase units) shown by the LBA to pseudo-physical block address (PPBA) mapping at 121 with the memory controller mapping of the LBAs to underlying physical block addresses (PBAs) as shown at 123. Whereas the host perceives a linear address mapping to the idealized physical storage (i.e., pseudo-physical storage), the memory controller maps the LBAs discontiguously, skipping over reserved and defective erase units, and thus virtualizing the pool of erase units within each individual flash die while maintaining the physical boundary between dies as reported to the host. Contrasting the cooperative management and hierarchically virtualized operating modes shown in FIG. 1, the controller fully exposes the physical flash hardware in the cooperative management mode and exposes a pseudo-physical hardware set in the hierarchically virtualized mode and is thus referred to herein alternately as an expositive or pseudo-expositive memory controller when operating in those respective modes, with the pseudo-expositive memory controller being a specialized instance of the more general expositive memory controller.

[0029] Note that in the cooperative management mode 116 and the hierarchically virtualized mode 118, some limited amount of address translation can be performed at the memory controller, e.g., by translating the address of one block in the hierarchy (e.g., erase unit) while preserving logical location level at other address levels (e.g., preserving page ordering within a remapped erase unit); in the cooperative management mode 116, such remapping can be temporary (e.g., with the host ultimately being informed for example of bad block remappings, for example), and in the hierarchically virtualized mode 118, such remapping can be transparent, with a memory controller deriving for example, any of erase unit, page, die, plane, device, channel or other hierarchical address distinctions while preserving address-space division (e.g., logical order) at other levels. Among other advantages, this architecture provides for greatly simplified address translation (e.g., which can optionally be implemented entirely in hardware), and facilitates configurable and predictable I/O latency, and greatly shortens address translation time and associated complexity.

[0030] FIG. 2 illustrates an exemplary application and configuration of a flash device having a pseudo-expositive memory controller (i.e., multi-mode memory controller operating in a pseudo-expositive mode, or memory controller having only a pseudo-expositive operating mode) within a host system. In the particular embodiment shown, an interactive block-device designer/allocator is executed within either the flash device, host system and/or separate computing device to obtain flash device geometry and performance characteristics and interact with a system designer (i.e., user, system architect or other human operator or programmed intelligence) to define and allocate one or more discrete performance-isolated storage regions within the flash device. The block device designer/allocator (“block device allocator” for short) supplies parameterized descriptions of each allocated flash storage region to a host file system (i.e., one or more threads or processes executed on a host computing system to carry out file storage, retrieval and maintenance operations with respect to files and other data objects) which, accordingly perceives each such flash storage region as a linear range of logical block addresses and thus as an independent block device.

[0031] Still referring to FIG. 2, and more specifically to the exemplary operational flow at 151, the block device allocator initially requests and receives geometry and performance data from the flash device and/or a device library at 155. In the embodiment shown and a number of embodiments described below, the geometry information includes hierarchical topology information including, for example and without limitation, (1) the number of independent flash-die access channels (also referred to herein as “signaling channels” or simply “channels”) coupled to or otherwise accessible by the memory controller, (2) the number of discrete flash dies coupled to each access channel, (3) the number of erase-unit planes (or “planes” for short) within each flash die, (4) the number of erase units within each plane, (5) the number of pages per erase unit and (6) the storage capacity of each page. In general, each of the device geometry parameters may be a physical (i.e., actual) or pseudo-physical representation of the corresponding underlying hierarchical structure (e.g., channels, dies, planes, erase units or pages). Performance data, which may be viewed as part of the geometry export, may include for example and without limitation, (a) the nominal programming time of a physical page within the erase unit of a flash die (i.e., “t_PROG” also referred to herein as the page write time), (b) the nominal read time of the physical page (t_READ), (c) the nominal time required to erase contents within an erase unit (t_ERASE), (d) the data transfer bandwidth over an individual access channel (Chan BW), (e) the data transfer bandwidth of the host interface (H-Intf BW), (f) various performance enhancement/optimization functions that may be available (e.g., multi-page functionality, read caching, write caching, etc.), and so forth.

[0032] At 157, the block device allocator determines the available block device profiles (i.e., physical and performance characteristics of different configurations of physical resources within the flash device) accounting for any pre-existing allocations. Assuming that no block devices have been allocated at this point and thus that resources sufficient for further block device definition remain within the flash device (i.e., negative determination at decision 159), then the block device allocator displays (e.g., in a visible display or other user interface of the computing device in which the block device allocator is instantiated) available block device profiles and the allocable quantities of each as shown at 161, prompting the user/designer to select one or more block device profiles and their desired allocation quantities. Upon receiving user input specifying a quantity of block devices having a given profile (and possibly multiple different profiles and respective quantities) at 163, the block device allocator prompts the user/designer to specify, for each block device to be allocated, whether the LBA range of the block device is to be uniformly sequenced among the hierarchical structures of the flash storage region to be allocated (e.g., channels, dies, erase units, pages) thus establishing a uniform address space layout (ASL) for the block device, or whether the address space layout is to be varied within one or more “subspaces” of the block device (i.e., “sub-ranges” of the overall LBA range for the block device). If subspace ASL is desired (affirmative determination at 165), the user is prompted to specify one or more specialized LBA ranges (i.e., LBA ranges having ASLs different from the otherwise uniform ASL corresponding to the block device profile). After receiving subspace ASL specifications, if any, for each user-requested block device, the block device allocator programs block device configuration registers 169 within the flash device (thereby allocating individually configured block devices within the flash device) and notifies the host file system of the block device allocation, supplying, for example a parameterized description of each block device that informs the host file system of the block device capacity (thus establishing the LBA range of the block device for a given LBA granularity), write bandwidth, read bandwidth and minimum data transfer size.

[0033] Note that the LBA granularity (i.e., size of a logical block of data—not to be confused with a block device which will typically hold millions of logical blocks of data each having a respective LBA) may be programmed within the block device configuration registers or other configuration storage of the flash device to enable a variable user-specified number of LBAs to span each physical page of storage within the flash device. Similarly, as discussed in greater detail below, the size of a logical quantum of data, referred to herein as a “host data segment” or “segment” and that constitutes a fundamental unit of storage allocation operated upon by the host file system, may be programmed within the block device configuration register to enable the memory controller to associate discrete sets of physical storage structures (e.g., an integer number of erase units within a given block device) with respective segments and thereby facilitate coordinated file-system and flash device management operations.

[0034] Continuing with the block device allocator flow, after programming the block device configuration registers and exporting corresponding block device parameters to the host file system at 169, the block device allocator returns to the space availability evaluation at 157, and determines the block device profiles and quantities thereof that remain available for allocation after accounting for any prior allocations at 169. If all available block devices are determined to have been allocated (i.e., all resources reported to be available by the flash memory device and/or library description of the flash memory device have been allocated in a block device definition or respective block device definitions), then the block device design/allocation operation is deemed complete and the block device allocator terminates. Though not specifically shown, the designer/user of the block device allocator may also terminate the block device allocation sequence without allocating all flash resources.

[0035] Reflecting on the block device allocation sequence shown in FIG. 2, it should be noted that numerous additional provisions and or options may be implemented in various embodiments. For example, instead of executing the flash memory/file system configuration operation at 169 in each loop iteration, the block device allocator may accumulate an internal set of flash device and flash memory configuration parameters in each loop iteration, prompting the user/designer to review a comprehensive allocation plan before proceeding with flash device programming and/or file system notification. Also, instead of issuing configuration commands/parameters to the flash memory device and/or host file system, the block device allocator may write configuration information to one or more configuration files (or other data objects) for later delivery to actual flash memory devices or host file systems. Further, instead of iteratively prompting a user to select from among available block device profiles (which selection constitutes an implied or explicit user/designer specification of block device characteristics, including logical block size, read bandwidth, write bandwidth, capacity, transfer size, endurance metric, etc.), the block device allocator may initially receive desired block device performance parameters from a user/designer and thus proceed from the user's initial performance specification to resolve block device allocations. In yet other embodiments, the quantity of block devices and/or their individual characteristics may be determined in whole or part by user/designer specification of aggregate read or write bandwidth within the flash device as a whole (together with other “overall device” requirements, such as a minimum segment size, logical block size and/or transfer size), with the block device allocator allocating and configuring, for example, a minimum or maximum number of block devices as necessary to meet those aggregate requirements. Accordingly, the iterative block device allocation sequence shown in FIG. 2 should be understood as but one of many possible block device allocation schemes which may be deployed in different embodiments or configurations.

[0036] FIG. 3 illustrates an exemplary flash memory device in which discrete block devices may be configured and allocated as described in FIG. 2. For purposes of explanation and understanding only, a specific flash device geometry and set of performance metrics are shown in FIG. 3 and carried forward in a number of embodiments described in reference to following figures of the drawing. In all such cases, the specific geometries (e.g., numbers of physical elements at each hierarchy within the flash device structure including, without limitation, access channels, flash dies per channel, planes per flash die, erase units per plane, pages per erase unit, page size, page read and write times (t_READand t_PROG), channel bandwidth and host interface bandwidth, number of host interfaces, etc.) may be different from those shown in FIG. 3.

[0037] With that understanding, it can be seen that the exemplary flash device in FIG. 3 includes a memory controller coupled to 16 access channels (ch0 . . . ch16), with each access channel coupled to eight flash dies, each flash die having two planes, and each plane containing 1124 erase units (2248 erase units per die), and each erase unit containing 256 pages each containing a number of flash memory cells (e.g., NAND memory cells, though NOR or flash memory cell configurations may be deployed in alternative embodiments) sufficient to store 16 kilobytes (kB) of data. As an aside, references to volumes of data herein are generally intended to mean a power of two quantity so that KB, MB, GB, TB, etc. refer respectively to 2¹⁰, 2²⁰, 2³⁰, 2⁴⁰, etc. byte of data (sometimes designated by KiB, MiB, GiB, TiB and so forth).

[0038] Continuing with the flash memory embodiment shown in FIG. 3, for purposes of example, it is assumed that the geometry exported to the block device allocator accurately reflects the underlying structural/physical hierarchy in all aspects but one—that the number of erase units per plane is reported pseudo-physically as 1024 (i.e., 2¹⁰and thus 2¹¹or 2048 erase units per die) instead of 1124, meaning that 100 erase units per plane and thus 200 erase units per die are held in reserve. As explained below, this erase unit reservation or “spare pool” enables the memory controller to virtualize the available erase units within each die and thus mask defective erase units from host visibility and swap erase units into and out of service as storage for respective LBA ranges of an allocated block device without impacting the host perspective of the block device or the flash device as a whole. Also, it bears emphasis that each virtualized collection of erase units is confined to the individual flash die (or even the individual planes, depending on block device configuration) containing the corresponding physical erase units. That is, while a given LBA that resolves to a flash die may include a virtualized erase-unit address field (an example of a discrete address field within the LBA corresponding to a group of physical elements within a structural hierarchy—erase units in this case), the LBA is nonetheless guaranteed by design to resolve to a physical erase unit with the LBA-specified physical die on the LBA-specified physical channel. More generally, as discussed in greater detail below, while any address fields (i.e., contiguous or discontiguous ranges of bits within an incoming LBA) corresponding to a hierarchical group of structures (e.g., channels, dies, erase units, pages) may be virtualized such that one or more of the corresponding hierarchical structures may be held in reserve, the address-space division between the hierarchical structures is maintained. Thus, once the channel field of an LBA is resolved to a particular channel, it is assured that, despite possible virtualization of the sub-hierarchical fields (i.e., die field, erase unit field and/or page field within the LBA), the LBA will ultimately resolve to a physical page on a physical die on that particular channel. This principle holds true for each level of the structural hierarchy so that once the LBA is resolved to a particular die, it is assured that the remaining erase unit and page fields, even if one or both are virtualized, will resolve to a physical page within that die, and likewise an LBA resolved to a particular erase unit is assured to specify a physical page within that erase unit, despite possible virtualization of the LBA's page field. Through this arrangement, it becomes possible to virtualize physical structures at each hierarchical level within the flash device while guaranteeing access to discrete subdivisions of the flash storage and thereby permitting, for example, specification of discrete subsets of dies and channels (or even finer-grained hierarchical elements where it makes sense to do so) to respective block devices specified within the block device configuration storage.

[0039] FIG. 4 illustrates an exemplary (and not necessarily complete) block device allocation and configuration within the flash device of FIG. 3 effected, for example, using the block device allocator described in reference to FIG. 2. As shown, five block devices, BD0-BD4, are allocated, with each block device being constituted by one or more flash dies that are collectively associated with one or more memory channels (i.e., in this example, the smallest allocable block device is a single flash device). The block device configuration storage (BD Config) includes a block device lookup table (BD LUT) that is indexed by a block device identifier (BDid which may be, for example, a namespace or other handle or identifier) and holds, for example and without limitation, a specification of the one or more channels spanned by the block device (i.e., “constituent channels”) and the one or more dies on the constituent channels. For instance, block device 0 (BD0) spans channels 0 and 1, and includes dies 0 and 1 on the constituent channels and thus includes four flash dies in all. Block device 1 is similarly defined as encompassing a 2×2 set of flash dies, but spans channels 2 and 3 instead of 0 and 1 and thus forms an entirely discrete storage area (i.e., no physical overlap) with respect to block device 0. Block device 2 spans a single channel (channel 0) and flash dies 2-5 on that channel, and thus also constitutes a four-die block device, but without the channel parallelism of block devices 0 and 1 (i.e., a 1×4 block device instead of a 2×2 block device). Block device 3 is also a four-die 1×4 block device, but is constituted by allocation of dies 2-5 on channel 1 instead of channel 0. Lastly, block device 4 is a 16-die block device that includes a single die (die 6) all 16 channels—that is, a 16×1 block device. Thus, of the overall set of five allocated block devices, four block devices (BD0-BD3) include discrete sets of four constituent dies and thus have a 32 GB pseudo-physical storage capacity (i.e., each die includes a pseudo physical count of 2048 erase units, each containing 256 16 KB pages and thus 2¹¹*2⁸*2¹⁴bytes or 8 GB) and the fifth block device (BD4) includes a discrete set of sixteen dies and thus a 128 GB pseudo physical storage capacity. Also, in this particular example, the channel and die identifiers recorded within the block device lookup table correspond one-for-one with underlying physical channels and dies within the flash device as neither of those elements of the structural hierarchy are virtualized. In alternative embodiments or configurations of the flash device, either or both of those elements may be virtualized.

[0040] Continuing with FIG. 4, each entry within the block device lookup table additionally includes an index to a respective set of one or more entries within an ASL lookup table (ASL LUT), with each ASL lookup table entry including ASL (address space layout) parameterizations and feature control settings for the complete or partial LBA range of the corresponding block device. In the particular example shown, ASL/feature-control parameter settings for three different block devices are illustrated, including a uniform ASL/feature-control parameterization within block device 0 (i.e., parameterization applies uniformly to the entire LBA range of the block device—there are no subspace definitions), another uniform ASL/feature-control parameterization with block device 2, and another multi-subspace ASL/feature-control parameterization within block device 4, with separate ASLs defined for each of multiple LBA ranges within the block device, only two of which are shown. Entries for block devices 1 and 3 are also present in the ASL lookup table, but not specifically shown in FIG. 4.

[0041] As discussed above, the ASL parameters define the manner in which sequential LBAs are distributed within the structural hierarchy of the block device and thus indicate the number of pages within the same erase unit (i.e., “seqPg”) to which sequential LBAs apply before progressing to page(s) in the next erase unit, and then the number of erase units to be sequentially accessed within a given die (“seqEU”) before progressing to the next die, and then the number of dies to be accessed on a given channel (“seqDie”) before progressing to the next channel. The feature control parameters include, for example and without limitation, whether read caching and write caching are to be enabled (independently settable via the rdC and wrC fields of the ASL lookup table entry) for the block device or subspace thereof, the number of pages that may be simultaneously or concurrently written to or read from within the same erase unit (nPa), and the number of erase-unit planes to be concurrently accessed in a given write or read command sequence (nPI). In general, read caching is a double-buffering construct that enables data retrieved from an address-selected storage page and stored within the flash die's page register (i.e., a buffer element that temporarily holds outbound page-read data and inbound page-write data) to be output from the flash die concurrently with transfer of subsequently selected storage-page data to the page register, and write caching is a similar double-buffering arrangement that enables concurrency during page-write operations. Thus, the read and write page caching features, when enabled, reduce net latency of a sequence of read or write operations, respectively. In general, page caching scales (e.g., multiples according to cache depth) the effective size of the page register and thus correspondingly raises the minimum data transfer size imposed on the host in a given page read or write operation. For simplicity of understanding, page caching in both the read and write directions is disabled (i.e., “off”) within the exemplary ASL lookup table entries shown. Multi-page operation (i.e., nPA set to a value greater than one) and multi-plane operation (nPI set to a value greater than 1) likewise raise the minimum data transfer size between the host and memory controller. In the specific examples shown in the ASL lookup table of FIG. 4, multi-page operation is disabled at least within block devices 0, 2 and 4, and multi-plane operation is disabled at least within block devices 2 and 4. By contrast, dual-plane operation (nPI=2) is specified for block device 0, thus doubling the number of concurrently written pages (a block device characteristic referred to herein as a “stripe size” or “frontier width”) as compared to a physically-comparable block device (e.g., block device 1) configured for single-plane operation.

[0042] Still referring to FIG. 4, the singular values (‘1’) recorded for the LBA-sequencing ASL parameters within the ASL lookup table entry for block device 0 dictate that LBAs are to be distributed widely through the structural hierarchy of the flash device with, for example, each page of a sequentially addressed set of four pages (and thus a sequential range of 16 LBAs given the sLB=4 KB logical block size setting) being read or written within a different one of the four constituent dies of the block device, thus effecting 4× (“multiplied-by-four”) parallelism in the page read or write operation and thus approximately a 4× bandwidth increase over a configuration that directs four sequential page read or write accesses to the same erase unit within a given die. In actuality, the dual plane setting within block device 0 doubles the number of concurrently accessed pages within each of the four constituent flash memory dies of block device 0, thus establishing an 8-page stripe size and thus read and write bandwidths that are approximately eight times the baseline single page read and write bandwidths of a given flash die. By contrast, block device 1 which otherwise constitutes the same 2×2 die-layout as block device 0, is configured with a deep (rather than wide) address space layout and with only single-plane access throughout its LBA range. Thus, pages falling within a sequential LBA range of block device 1 are mapped to physical pages within an erase unit until the end of that erase unit is reached (i.e., “Pg/EU”), with the LBA range thereafter continuing through the physical pages of a next erase unit and then the next until the final erase unit (EU/Die) within the die has been traversed, with the LBA range thereafter continuing through the pages and erase units of the next die on the same channel before carrying over to EUs and dies on an adjacent channel. In general because the stripe size is very narrow (i.e., a single page and thus as narrow as possible in the exemplary flash memory die shown), only a single erase unit is impacted by each page write operation and thus, despite the relatively low write bandwidth (i.e., 16 KB/t_PROGin contrast to the 8*16 KB/t_PROGbandwidth achieved by the 8× wider stripe size in block device 0), write-induced wear resulting from, for example, storage of a 16 MB host segment, will occur in only a relatively small number of erase units and dies—four 4 MB erase units within the same die in this example—in contrast to the storage of each of the 1024 16 KB pages within a respective one of the 1024 erase units of block device 0 (i.e., each of the 256 erase units within each of the four dies is written to and thus worn to some degree). Conceptually, while the total page wear is equivalent in both block die configurations (the same number of pages is written), the wear within narrower-stripe-size (i.e., deeper, but lower bandwidth) block device 1 is concentrated within a much smaller number dies (and potentially erase units as well), simplifying wear-leveling operations and thus raising endurance of the block device as compared to wider, higher-bandwidth block device 0. In general, all these considerations are made available to the user/system designer in configuring the block devices, as the designer is able to directly, or with the aid of the block device allocator, specify ASL and feature-control parameters that strike a design balance between endurance and bandwidth requirements of a given application, potentially configuring block devices having widely varying performance characteristics within the same flash memory device, as illustrated by block devices 0-4 in FIG. 4.

[0043] Concluding with FIG. 4, the ASL lookup table includes multiple entries (and thus multiple subspace definitions) for block device 4, with an initial entry specifying a 4K LBA range (0-4095) mapped for high I/O bandwidth (i.e., 16-page stripe size as the write frontier spans all sixteen of the flash dies within the block device) and another entry specifying a subsequent 4K LBA range mapped for endurance (single-page stripe size). One or more other subspace definitions (not shown) complete the LBA range mapping of block device 4.

[0044] FIG. 5 illustrates a host perspective of the exemplary block device allocations and configurations presented in FIG. 4, showing relative block device capacities by the area/footprint of the block devices (as will be the case within the physical flash storage media) and illustrating relative block device bandwidths according to block device width (left-to-right across the drawing figure). Thus, block devices 0-3 all have the same four-die, 32 GB capacity and thus have the same footprint (i.e., spanning an equivalent area within the figure), while block device 4, encompassing four times as many flash dies as each of the other block devices has a correspondingly larger 128 GB capacity. Also, block devices 0, 1, 2, 3 and 4 are depicted with respective widths according to their nominal maximum I/O bandwidths of 8×, 1×, 1×, 2× and 16×, respectively, where each non-unity multiplier scales the baseline read and write bandwidths (i.e., 1/t_READand 1/t_PROG). As shown in detail view 251, the signaling bandwidth of block device 4 varies according to subspace, having a high (16×) bandwidth in the initial LBA range, and a 1× bandwidth in the LBA range that follows (i.e., in accordance with the respective subspace stripe sizes of 256 KB and 16 KB). Note also that actual block device bandwidths may be constrained by peak channel and/or host interface signaling rates, particularly in the case of memory read operations. For example, because the host interface is shared between all block devices (at least in the single host-interface embodiment shown in FIGS. 3 and 4) and individual access channels may be shared by as many as eight block devices (or more or fewer according to the number of flash dies per channel), operations executed in one block device may cut into the signaling bandwidth needed for peak-rate operation within another block device, particularly where numerous high-bandwidth block devices share the same signaling access channel or a large number of block devices are allocated within the flash device (which may saturate the host interface during occasional concurrent read access within a threshold number of block devices).

[0045] FIG. 5 also presents a non-exhaustive list of flash device performance characteristics and features enabled by hierarchical address virtualization within the memory controller and configurable block device allocation, including (i) a configurable and predictable I/O latency, (ii) brief or otherwise negligible logical-to-physical (“L2P”) address translation time (or at least dramatically reduced L2P time relative to operating modes that invoke a flash translation layer), (iii) allocation of discrete defect-free block devices in user-specified quantities and capacities, (iv) host-scheduled maintenance of flash-device-identified segments (or other logical units of storage), and (v) forward compatibility/ease of migration as flash device capacities and feature sets expand in successive device generations. Each of these characteristics/features is discussed in greater detail below.

[0046] FIG. 6 illustrates an exemplary pair of block device configurations that demonstrate the configurable and predictable I/O latency enabled by the pseudo-expositive flash device described above (i.e., flash device having a pseudo-expositive memory controller) and the user-configurable block device allocation therein. These configurations will be respectively referred to as “configuration A” and “configuration B,” with it being understood that a device may be reconfigured dynamically or otherwise as desired, as indicated by the presence of a migration arrow separating these two configurations. As shown, each of the block configurations features a 2×2 disposition of four dies (i.e., two dies coupled to channel 0 and two dies coupled to channel 1) and two planes of erase units within each die. That is, the block device configurations represent physically identical geometry and capability. However, by programming a wide and shallow ASL (i.e., ASL parameters set to distribute sequential LBAs through a minimum number of physical structures at each level of the structural hierarchy) and enabling dual-plane operation, an 8-page I/O stripe width is implemented with block configuration A and thus an 8 page/t_PROGwrite bandwidth and 8 page/t_READread bandwidth, assuming sufficient overhead within the host-interface and flash-die access channels (as indicated by the 8 EU's in bold in the left-most grouping of 4 dies in FIG. 6). By contrast, block device configuration B features a narrow and deep ASL (i.e., ASL parameters set to distribute sequential LBAs through a maximum number of physical (or pseudo-physical) structures at each level of the structural hierarchy) and for single-plane operation, so that a single-page stripe size is established and thus write and read bandwidths of only 1 page/t_PROGand 1 page/t_READ, respectively. As explained above, the sequencing of LBAs through all the physical (or pseudo-physical) structures of a given die before proceeding to the next die increases endurance of the block device relative to its wider-stripe-width counterpart. Accordingly, the ASL of a given block device within the pseudo-expositive flash device may be tuned to meet endurance and bandwidth targets of a given application.

[0047] FIG. 7 illustrates an exemplary generation of a physical block address in response to an incoming LBA (i.e., logical block address provided by host in connection/association with a memory access or maintenance operation) and block device ID (BDid). As shown, the block device ID is applied to a block device lookup table (e.g., as described in reference to FIG. 4) to retrieve information identifying the channels and dies that constitute the block device (i.e., allocated to the block device) and thus, base die and base channel values that specify starting boundaries within a physical or pseudo-physical die matrix, together with parameters that indicate a number of channels and dies per channel spanned by the block device (Chans, Dies/Chan). In other embodiments, the constituent dies and channels of the block device may be specified in other ways (e.g., list of specifically identifiable dies, starting channel/ending channel together with starting die/ending die, etc.).

[0048] In the implementation shown, the block device lookup table also outputs an ASL lookup address to the ASL lookup table. The ASL lookup table, in turn, outputs the recorded ASL parameters (including logical block size if implemented as a variable parameter) to an ASL generation logic block which in turn outputs an address-space-layout value that enables the incoming LBA to be decomposed into a set of hierarchical “sub-address” values, one sub-address for the group of elements at each respective level of the structural hierarchy within the flash device (e.g., channel sub-address, die sub-address, erase-unit sub-address, page sub-address).

[0049] This LBA decomposition into sub-addresses is easiest understood by considering the special case in which each sub-address maps to a power-of-two number of corresponding hierarchical elements (e.g., 2⁴channels, 2³dies per channel, 2¹¹erase units per die, 2⁸pages per erase unit) as, in that case, the ASL indicates, in effect, the location of discrete bit fields within the incoming LBA that correspond to respective levels of the structural hierarchy. Moreover, as shown in the shaded examples of ASLs for block devices 0-4 (BD0-BD4) at, the ASL also identifies the position of each discrete bit field within the ASL—a consequence of the sequential LBA assignment parameters described above in reference to FIGS. 4 and 5. Considering the ASL for block device 0, for example, it can be seen that, except for the page offset fixed at the lowest bits of the incoming LBA, the channel sub-address field constitutes the least significant field of the BD0 ASL, followed by the die sub-address field, the erase-unit sub-address field and then the page-address sub-address field. Accordingly, assuming for example that the page offset is a two-bit field such that four logical blocks are stored within each flash page, then every fourth LBA in a linear sequence of LBAs will be written within a die on a different channel with modulo wrap around to an initial channel after a die on the final channel has been written. By contrast, the sub-address (or field) order in the block 1 ASL is exactly the opposite that of block device 0 (excepting the least-significant page offset field), such that pages are sequenced first, then erase-units, then dies, and then channels at the end.

[0050] Continuing with FIG. 7, as the ASL indicates how the individual hierarchical sub-address fields have been packed or encoded within the incoming logical block address, that value is supplied to pseudo-physical address generator and used therein to extract (or unpack or decode) or otherwise recover the individual hierarchical sub-addresses. In the particular example shown, the erase-unit sub-address (EUvirt) is assumed to be a virtual address (e.g., resolving between 2048 possible erase units within a die having, in actuality, some larger number of erase units) which is therefore supplied to a sub-address translation table (or lookup table) for un-mapping to the physical address of the erase unit to be accessed. In the particular example shown, the remaining sub-address fields are assumed to be physical addresses corresponding to respective levels of the structural hierarchy so that those sub-address fields, together with the output of the translated erase-unit address (EUphys) constitute a physical block address that may be supplied to address decoding logic to issue the necessary control and enable signals to effect access to the specified page of flash storage (at the offset specified by the page offset).

[0051] In an alternative embodiment, the channel, die, page and page-offset sub-addresses (or any subset thereof) recovered from the LBA are also virtual addresses and thus supplied to respective sub-address translation or lookup tables (Ch LUT, Die LUT, Pg LUT, PO LUT) to obtain or generate the corresponding physical sub-addresses. More generally, any or all of the sub-address fields (including the page offset) recovered from the inbound LBA may be virtual addresses that are converted to physical addresses through translation/lookup operations. Also, two or more of the lookup tables for different hierarchical levels may be merged or combined. For example, the channel and die lookup tables may be merged to enable a two-dimensional lookup, thus virtualizing the die array as a whole and enabling any die on any channel to be interchanged (i.e., through virtual-to-physical address translation) with any other die on the same channel or any other channel.

[0052] A conceptual view of an erase-unit virtual-to-physical (V2P) translation table implementation is shown conceptually in the bottom portion of FIG. 7 to demonstrate that a channel and die, selected by one of numerous constituent erase-unit lookup tables (or translation tables) is selected to yield the physical erase-unit address (i.e., to provide for independent erase-unit mapping from die to die). Various other implementations may be deployed in alternative embodiments.

[0053] A number of points bear emphasis in view of FIG. 7. First, as the individual sub-address fields are, by virtue of block device and ASL programming, modulo-encoded into the incoming logical block address (e.g., as respective bit-fields in the power-of-two example shown), the sub-address values may be deterministically (e.g., algorithmically) recovered from the logical block address extremely quickly and efficiently, avoiding altogether the generally enormous translation data storage (e.g., trie structures and the like) and extensive translation times required for FTL operating modes or implementations. Moreover, the very presence of the sub-address values within the logical block address (i.e., the logical block address may be viewed as a tuple of the hierarchical sub-address values made possible by the pseudo-physical specification of the block device and in which the sub-address values that form the tuple may be re-ordered in a variety of ways and even fragmented in accordance with the user-specified address space layout for a block device or subspace therein) effects an assurance to the host that LBAs containing the same sub-addresses down to a given hierarchical level will resolve to the same physical resource. For example, LBAs containing the same channel sub-address are ensured to access a die on the sub-address-identified channel. Similarly, LBAs containing the same channel and die sub-addresses are ensured to access an erase unit within the same die, and so forth. Moreover, any of the sub-addresses may be encoded into the LBA as a virtual address—that is a sub-address value that virtualizes the corresponding (and compartmentalized) physical resource. Thus, even though a given LBA may be assured to resolve to a desired die (virtual or physical), a virtualized erase-unit sub-address enables the underlying physical resources within that die to be swapped in and out of service as necessary, all without impacting the linear address space and performance perceived by the host.

[0054] Also note that the depicted architecture permits address translation to be reduced to relatively simple operations that can be implemented using logic gates and lookup tables, that is, in a manner that can be performed extremely fast, e.g., on an intra-cycle basis (i.e., in less than a clock cycle) or at most using only a handful of clock cycles. For example, as will be discussed below, a memory controller can offload address translation to a set of logic gates and prepopulated lookup tables, which can perform address translation without requiring processor clock cycles. On-board logic can then update the lookup tables and/or metadata as appropriate, in a manner that does not encumber I/O latency. By contradistinction, conventional flash memory tables which map a logical page address to potentially any wordline in flash memory device typically require gigabit-size translation tables, with translation only being performed using a substantial number of using processor cycles. This architecture, once again, helps streamline I/O latency, rendering it far more predictable, and reduces address translation time to a negligible quantity.

[0055] As discussed above, the exemplary ASL bit-field maps shown in FIG. 7 for the different block devices assume a power-of-two quantity of physical resources at each hierarchical level in the flash. In the more general case, the resources at any or all physical levels may not be power-of-two quantities and thus complicate the picture of sub-address encoding. For example, assuming a 3-channel, 5-die block device allocation in which each die contains 2000 pseudo-physical erase units and 400 pages per erase unit, the total LBA range (assuming four LBAs per page) will span from 0 to 3*5*2000*400*4 (where ‘*’ denotes multiplication) and thus from 0 to 48,000,000−1 and thus only part of the range represented by the smallest sufficient binary address size 2{circumflex over ( )}26. Moreover, because each element of the tuple that constitutes a given logical block address ranges between 0 and a non-power-of-2 maximum (i.e., magnitude of individual tuple elements are not, in all cases, power of 2 numbers), the sub-addresses of different hierarchical groups of structures (i.e., channels, dies, erase units, pages, etc.) do not fall within discrete bit fields. Said another way, the power-of-two ASL examples shown in FIG. 7 are a special case of a more general solution in which sub-address fields are recovered using modulo arithmetic that reflects the tuple composition of the logical block address. Once again, as depicted, such an architecture can be easily implemented entirely or primarily in hardware, thus reducing translation times to negligible levels.

[0056] FIG. 8 illustrates a conceptual implementation of an address generation module that may be used to extract (or recover) sub-address values from an inbound LBA regardless of whether the magnitude of individual tuple elements (i.e., number of channels, number of dies/channel, number of erase units/die, number of pages/erase unit) are power-of-two numbers or not. As in FIG. 7, any or all of the hierarchical sub-address values, once recovered, may be converted from virtual to physical sub-addresses to collectively form an inbound physical block address (PBA), adding offsets to reflect the base channel and base die of the block device. For reasons discussed in further detail below, the address generator is implemented bi-directionally. That is, essentially the same operations executed to yield a PBA from an inbound LBA may be executed in reverse to produce an outbound LBA from a physical block address, thus enabling status regarding a given physical resource within the flash device to be reported to the host in terms of the LBA mapping that the host understands. Note that this information can be used to provide context to a host in order for a host to schedule maintenance or data movement (e.g., data migration or garbage collection) to preselected locations (e.g., where the logical address locations corresponding to the data are matched to the wear of a destination physical location, or where logical address locations having similar age, write frequency and/or read frequency characteristics are grouped together), as discussed in the copending application “Techniques for Data Migration Based On Per-Data Metrics and Memory Degradation” which as been incorporated by reference, as noted earlier.

[0057] Referring first to the inbound LBA path, an ASL value (e.g., generated per the ASL lookup table entry as discussed in reference to FIG. 7) that describes the order of tuple elements within the inbound LBA is supplied to a pair of steering circuits that yield a set of divisors—products of individual tuple elements. More specifically, a magnitude steering circuit selects, as magnitudes of the three least significant tuple elements within the inbound LBA (a four-tuple LBA is assumed in this example, having as tuple elements, a channel sub-address, die sub-address erase-unit sub-address, and page sub-address in any order), from among the block device configuration settings for structural element quantities (i.e, number of allocated channels, number of allocated dies, number of allocated erase units, number of allocated pages) to produce divisor values that reflect strides within the LBA (after scaling to account for the page offset—the “scaled LBA” or “offset-scaled LBA”) at which boundaries between different members of the same structural group occur. Thus, in the 3-channel, 5-die, 2000 erase-unit, 400 page example above, if the tuple elements are ordered from most to least significant as channel sub-address, die sub-address, erase-unit sub-address, page sub-address, then the tuple element magnitudes will be 400, 2000, and 5, for elements 0, 1 and 2, respectively. Accordingly, the divisors supplied to the divisor steering logic will be DM1=200, DM2=400*2000=800,000 and DM3=400*2000*5=4,000,000. The divisor steering logic serves to route the divisors to the appropriate sub-address generation paths according to the tuple order specified in the ASL value and thus, continuing with the 3 channel, 5 die, 2000 erase unit, 400 page example (i.e., in tuple notation: “(3,5, 2000, 400)”), the channel sub-address path will receive the 400*2000*5 divisor (reflecting that a different channel is specified at each 4,000,000 increment in the scaled LBA), the die sub-address path will receive the 400*2000 divisor (reflecting that a different die is specified at each 800,000 increment in the scaled LBA) and the erase-unit sub-address path will receive the 400 divisor (reflecting that a different erase unit is specified at each 400 increment in the scaled LBA). The sub-address path for the least significant tuple element will receive a unity divisor (i.e., ‘1’), reflecting that a different page is specified at each increment of the scaled LBA.

[0058] Still referring to the inbound LBA path of FIG. 8, after divisors have been applied to the scaled LBA (i.e., integer division as reflected by the ‘/’ operator in divider logic elements), the results (integer-valued quotients) are subject to modulo operations (i.e., modulo 400, 2000, 5 and 3 for the respective sub-addresses) within the “mod” logic elements to yield sub-address values which, in the example shown, are assumed to be virtual sub-address values. As shown, the virtual sub-addresses are supplied to respective (or joint) lookup/translation modules to generate physical sub-address counterparts generally as described above in reference to FIG. 7. Any or all of the modulo logic outputs may be physical sub-address values in alternative embodiments.

[0059] Still referring to FIG. 8, the outbound PBA/LBA path is essentially the reverse of the inbound path, converting physical sub-address into virtual sub-addresses as necessary, multiplying by the steered divisor value (now a multiplier and hence a “divisor-multiplier”), and then summing the multiplied sub-address values to form the four-tuple LBA output (merging in the page offset to yield the full-range rather than offset-scaled LBA).

[0060] FIG. 9 illustrates an exemplary virtualization of erase units within a four-die (2 dies by 2 channels) block device that demonstrate the discrete defect-free block device exposition enabled by the various pseudo-expositive flash device embodiments described above. In the example shown, the ASL is configured similarly to that of block device in the left-most portion of FIG. 6, but with only single-plane operation, thus establishing a four-page stripe width. For purposes of example the erase units into which the first sixteen pages of data are enumerated within the erase-unit elements themselves. Further, it is assumed that the erase unit population is larger than the virtual erase unit address field within each incoming LBA such that some number of spare erase units is available within each die. Accordingly, upon determining that the erase unit shown at the bottom right corner of the fourth die is defective, the pseudo-expositive memory controller remaps the LBA that would otherwise resolve to the defective erase unit to a spare erase unit within the same die. That is, the fifth page of data that might otherwise be written to the defective erase unit is, through translation of the virtual address field within the incoming LBA to a physical address field as discussed above, re-directed to the spare page entirely transparently to the host write requestor. Impending run-time detected erase-unit failures in dies marked ‘X’ result in similar re-mapping and data move operations (i.e., prior to complete failure of the suspect erase units) again permitting the host to perceive the block device as a discrete defect-free storage entity. As discussed above, any other resources within the structural hierarchy of the flash device (including particularly those most likely to fail), such as dies, planes, pages or even channels may be virtualized and pseudo-exposed to the host in a manner that preserves one or more spares. In all such cases, the host may configure the number of structural elements reserved as spares on a flash-device-wide or block-device basis, for example, after requesting and receiving a physical geometry description from the flash device, including a reporting of the number of failed or suspect elements at each level of the structural hierarchy. Such spare-setting (or reserve pool specification) may be carried out, for example, in connection with block device programming within the block device allocator described above in reference to FIG. 2 (e.g., programming the number of spares to be reserved, percentage of spares to be reserved, size of virtual address field and thus the allocable number of structural elements, etc.) and may be assisted by receiving a default reserve pool recommendation from the memory controller (which default may be applied to allocated block devices absent host programming of a different setting.

[0061] Still referring to FIG. 9, the pseudo-physical host perspective of block device remains static and defect free, despite ongoing failure events (and/or removal of erase units or other virtualized structural elements from service for wear leveling, garbage collection, scrubbing or other maintenance or operational reasons). The remapping of address information by the memory controller using the identified translation scheme once again helps streamline I/O latency, as discussed earlier.

[0062] FIG. 10 demonstrates an exemplary sequence of operations coordinated between the pseudo-expositive flash memory controller and host file server to enable host-scheduled maintenance of flash-device-identified units of data, and more specifically segments in this example. The device tracks statistics and environmental status of the memory looking for indications that a portion of the data needs maintenance driven by a physical resource. An example of a maintenance operation might be that data has resided on a given EU for a time long enough to approach a maximum estimated safe retention time. An event could be set to trigger at a threshold of safety previously selected by to host and communicated to the device. Once that event has been triggered, the device translates the physical location though the previous block device and ASL map structures in order to identify the segment as a host LBA in which the physical resource resides. When the host has received the notification of the event, along with the associated segment LBA address, length, and event type, the host may elect to handle that event in a number of ways. Host issued instructions may garbage collect, copy, move, or discard data in manner the best benefits the overall efficiency of the system. Those instructions may be mixed into the overall system scheduling. Note that in contradistinction to conventional approaches (e.g., where an entire address space is garbage collected, in a device-wide operation delegated to a memory controller) that this approach permits the host to command specific maintenance operations to specific hierarchies, for example, by command to perform maintenance on a specific EU; to this effect, the host transmits a maintenance command with a specific block address, which the memory controller uses to perform maintenance on a host-selected or host-specified address range, conveyed by or in connection the maintenance command. Once data has been relocated or discarded, a segment of interest may be erased.

[0063] FIG. 11 illustrates a forward (and reverse) compatibility between successive flash generations that is enabled by the pseudo-expositive flash device in combination with the block device allocator discussed above in reference to FIG. 2. Assume, for example, that the block device allocator was initially executed in connection with a generation ‘A’ flash device having a page size ‘K’, to configure a block device having a four-page stripe size. For ease of illustration, the K-sized pages are assumed sufficiently large that each erase unit contains only two pages, and that each host segment spans four erase units. Thus, a first host segment (“Seg0”) is striped across the four dies of the block device and fills erase unit 0 within each die, being stored in eight pages total (pages 0-7), while a second host segment (“Seg1”) is stored within erase unit 1 of the four dies and thus in pages 8-15. Assume as a forward-compatibility example, that a next generation “GenB” flash device is to be deployed in combination with or in place of a “GenA” flash device, and that page size has doubled to 2K so that the overall flash device capacity has doubled in GenB (i.e., there are the same number of pages per erase unit, erase units per die, dies per channel and channels as in the GenA device so that the doubled page size doubles the capacity of every element in the structural hierarchy). In this case, assuming further that the page read and write times (t_READand t_PROG) have also doubled between the two flash device generations, then the user/designer may re-run the block device allocator with an unchanged set of block device specifications (i.e., in terms of read and write bandwidth, at least) to yield a block device allocation and ASL within the GenB device that matches the performance characteristics of the counterpart block device within the GenA flash device, albeit at double capacity. For example, as shown in FIG. 11, the block device allocator may define the ASL such that the stripe width still spans four pages (i.e., a page within each of the four allocated dies) so that the reduced write bandwidth (due to the 2× higher GenB tProg) is offset by the doubled page size. Thus, the two segments previously stored within the GenA drive may be written to the GenB drive with the same bandwidth, but now occupy only half the number of erase units (as their capacity has doubled) as in the GenA storage. Note that Seg1 may, through different ASL specification, be stored within dies 0 and 1 of the GenB flash device instead of dies 2 and 3, thus raising endurance of the flash device at the cost of reduced write bandwidth. Changing the example so that the tPROG and tREAD times remain unchanged in the GenB device, then the alternative segment 1 storage destination (i.e., alternative ASL specification) within dies 0 and 1 may be preferable, as the two-die stripe size in the GenB device would yield the same write bandwidth as the four-die stripe size in the GenA device. That is, sequencing more narrowly through dies 0 and 1 (instead of more broadly across all four dies) will yield a higher endurance result with approximately the same read/write bandwidth. As discussed above, the ASL may be further tuned to yield a desired balance between endurance and I/O bandwidth.

[0064] FIG. 12 illustrates more detail regarding pseudo-physical geometry export options within a flash device having multi-plane flash dies. In the particular example shown, it is assumed that each die within the flash device, exemplified by “Die 0” includes N erase units distributed evenly between even and odd erase-unit planes (i.e., N/2 erase units per plane). In general, the die may be switched on the fly, according to incoming command sequences, between single-plane and multi-plane operation. Once again, therefore, the same die (“Die 0”) is illustrated in duplicate to discuss multiple alternate configurations; the pseudo-expositive memory controller may operate the die in one of several different pseudo-physical modes including, an opportunistic single-plane mode, an exclusively multi-plane mode, and a range-split hybrid mode in which a portion of the pseudo-physical or physical erase units within the die are operated in opportunistic single-plane mode and another portion of the erase units are operated in exclusively multi-plane mode. In each of the pseudo-physical operating modes, the erase unit field of an incoming LBA resolves to fewer than N erase units. For example, the erase unit field resolves to any one of M erase units in single-plane mode, to any one of M/2 double-width erase units (i.e., logical combination of paired erase units drawn respectively from the odd and even planes) in dual plane mode and any one of K single-plane erase units or J double-width erase units in the hybrid split-range mode, where M<N and K+2J<N.

[0065] In opportunistic single-plane mode, the flash die is generally accessed one erase-unit at a time (or more accurately one page within one erase unit at a time, for reads and writes), occasionally executing a dual-plane command where a pair of successive accesses are directed respectively to erase units within the odd and even planes. By contrast, when configured for dual plane mode, each host requested memory access is translated by the memory controller into a dual plane command sequence that accesses a matched pair of erase units within each of the odd and even planes (i.e., one odd-plane erase unit and a counterpart even-plane erase unit). Accordingly, the page registers and erase units are viewed, from a pseudo-physical perspective, as double-width elements as compared to individual page registers and erase units in single-plane mode. Moreover, the total number of erase units is halved (by the effective merging of the two planes) so that the pseudo physical address range is reconfigured to account for half the number of virtually addressable erase units within the die, and double the number of logical blocks per page.

[0066] Still referring to FIG. 12, the split-range hybrid mode, due to its dual range-divided configuration, permits single-plane commands and opportunistic multi-plane command sequences within the single-plane address range (i.e., logical addresses that resolve to erase units below pseudo-physical erase unit K), and requires exclusively multi-plane command sequences within the dual-plane address range. In alternative embodiments, the ordering of the dual-plane and single-plane ranges may be reversed (i.e., dual-plane at lower rather than higher-ordered addresses) and the total number of different ranges may be greater than the two shown.

[0067] FIG. 13 illustrates additional operations that may be managed by embodiments of the pseudo-exposition. Once again, “Die 0” is shown in multiple, alternate configurations. A defective erase unit detected within a given plane of a multi-plane capable die may be mapped (logically replaced) by an otherwise reserved erase unit within the same plane as shown in the two pseudo-physical views of die zero. This enables opportunistic multi-plane operations to continue when the die is configured for single-plane operation, and permits multi-plane operations to proceed entirely transparently to the host.

[0068] FIG. 14 illustrates one embodiment of various techniques illustrated above, implemented as a memory controller integrated circuit (IC). As noted by the figure, in one version, such an IC can be implemented as a field-programmable gate array (FPGA) having logic gates and lookup tables (e.g., circuitry) configured to provide fast address translation as discussed above; this is not required for all embodiments, and in other contemplated embodiments, a memory controller can be implemented as a special purpose processor or other preconfigured integrated circuit, with or without the use of support software (e.g., firmware). As depicted by the figure, the IC includes a host interface, which for example, uses a standard communication interface framework (e.g., non-volatile memory express, or NVME or Serial ATA) for packetized communications, where packets comprise commands, address and data, as appropriate; note that this interface can be shared for commands directed to different channels or devices, i.e., the commands and data to respective channels and/or dies are typically MUX'ed over this channel for exchange between the memory controller IC and the host. Similarly, as discussed earlier, the memory controller features a flash interface, whereby one or more channels are used to communication with one or more memory devices. Each channel can consist of a set of links for address and/or data (e.g., for packetized communication of address and data over a set of eight links), or can feature separated address and databusses (as depicted by the optional, dashed-line links designated for “data”). The memory controller IC also features hardware translation circuitry as mentioned (e.g., with ASL parameters being used to configure address wrapping and distinction between hierarchical levels and with LUTs used for address mapping at selected or predetermined levels of the hierarchy) and buffers for buffering commands and/or data transfer as appropriate. In addition, the memory controller IC in this embodiment can include supervisory logic (e.g., for responding to host queries, performing LUT updates, and configuring parameters as appropriate, as well as for controlling sequencing and maintenance operations in memory), a block-device designer and allocator section as discussed earlier in connection with FIG. 2, and block device configuration elements, as appropriate. In one embodiment, some or all of these functions can be implemented in the form of instructions stored on non-transitory machine-readable media (e.g., firmware or software, for controlling one or more cores or processors).

[0069] It should be noted that, as a step in their fabrication or other reification, the various circuits disclosed herein may be described using computer aided design tools and expressed (or represented) as data and/or instructions embodied in various computer-readable media, in terms of their behavioral, register transfer, logic component, transistor, layout geometries, and/or other characteristics. Formats of files and other objects in which such circuit expressions may be implemented include, but are not limited to, formats supporting behavioral languages such as C, Verilog, and VHDL, formats supporting register level description languages like RTL, and formats supporting geometry description languages such as GDSII, GDSIII, GDSIV, CIF, MEBES and any other suitable formats and languages. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, computer storage media in various forms (e.g., optical, magnetic or semiconductor storage media, whether independently distributed in that manner, or stored “in situ” in an operating system).

[0070] When received within a computer system via one or more computer-readable media, such data and/or instruction-based expressions of the above described circuits may be processed by a processing entity (e.g., one or more processors) within the computer system in conjunction with execution of one or more other computer programs including, without limitation, net-list generation programs, place and route programs and the like, to generate a representation or image of a physical manifestation of such circuits. Such representation or image may thereafter be used in device fabrication, for example, by enabling generation of one or more masks that are used to form various components of the circuits in a device fabrication process. Any of the various methods and operational sequences herein may likewise be recorded as one or more sequences of instructions on a computer-readable medium and may be executed on a computing device to effectuate the disclosed method and/or operational sequence.

[0071] Also, as noted, many of the techniques described herein can be employed in an apparatus, a method, an integrated circuit, a system on-chip, a memory device, a memory controller, a host processor, as a circuit description (i.e., that contains data structures defining fabrication parameters for a processor, integrated circuit, device, or components of any of these things), as instructions stored on machine-readable media (e.g., firmware or software intended for execution on one or more general purpose machines), or as combinations of these things. In the case of software or other instructional logic, the instructions are typically written or designed in a manner that has certain structure (architectural features) such that, when they are ultimately executed, they cause the one or more general purpose machines or hardware to behave as special purpose machines, having structure configured by the instructions to necessarily perform certain described tasks. “Non-transitory machine-readable media” as used herein means any tangible (i.e., physical) storage medium, irrespective of how data on that medium is stored, including without limitation, random access memory, hard disk memory, optical memory, a floppy disk or CD, server storage, volatile memory and other tangible mechanisms where instructions may subsequently be retrieved by a machine. The machine-readable media can be in standalone form (e.g., a program disk) or embodied as part of a larger mechanism, for example, a storage drive, CPU, laptop computer, portable or mobile device, server, data center, “blade” device, subsystem, electronics “card,” storage device, network, or other set of one or more other forms of devices. The instructions can be implemented in different formats, for example, as metadata that when called is effective to invoke a certain action, as Java code or scripting, as code written in a specific programming language (e.g., as C++ code), as a processor-specific instruction set, or in some other form; the instructions can also be executed by the same processor or different processors, depending on embodiment. For example, in one implementation, instructions on non-transitory machine-readable media can be executed by a single computer and, in other cases as noted, can be stored and/or executed on a distributed basis, e.g., using one or more servers, web clients, or application-specific devices. Each function mentioned in the disclosure or FIGS. can be implemented as part of a combined program or as a standalone module, either stored together on a single media expression (e.g., single floppy disk) or on multiple, separate storage devices. The same is also true for a circuit description for fabricating cores, processors, devices or circuits described herein, i.e., the result of creating a design can be stored in non-transitory machine-readable media for temporary or permanent use, either on the same machine or for use on one or more other machines; for example, a circuit description or software can be generated using a first machine, and then stored for transfer to a printer or manufacturing device, e.g., for download via the internet (or another network) or for manual transport (e.g., via a transport media such as a DVD) for use on another machine. Throughout this disclosure, various processes will be described, any of which can generally be implemented as instructional logic (instructions stored on non-transitory machine-readable media), as hardware logic, or as a combination of these things. Depending on product design, such products can be fabricated to be in saleable form, or as a preparatory step for other processing that will ultimately create finished products for sale, distribution, exportation or importation.

[0072] In the foregoing description and in the accompanying drawings, specific terminology and drawing symbols have been set forth to provide a thorough understanding of the present invention. In some instances, the terminology and symbols may imply specific details that are not required to practice the invention. For example, any of the specific numbers of bits, signal path widths, signaling or operating frequencies, device geometries and numbers of hierarchical structural elements (e.g., channels, dies, planes, erase units, pages, etc.), component circuits or devices and the like may be different from those described above in alternative embodiments. Additionally, links or other interconnection between integrated circuit devices or internal circuit elements or blocks may be shown as buses or as single signal lines. Each of the buses may alternatively be a single signal line, and each of the single signal lines may alternatively be buses. Signals and signaling links, however shown or described, may be single-ended or differential. A signal driving circuit is said to “output” a signal to a signal receiving circuit when the signal driving circuit asserts (or deasserts, if explicitly stated or indicated by context) the signal on a signal line coupled between the signal driving and signal receiving circuits. The term “coupled” is used herein to express a direct connection as well as a connection through one or more intervening circuits or structures. Device “programming” may include, for example and without limitation, loading a control value into a register or other storage circuit within an integrated circuit device in response to a host instruction (and thus controlling an operational aspect of the device and/or establishing a device configuration) or through a one-time programming operation (e.g., blowing fuses within a configuration circuit during device production), and/or connecting one or more selected pins or other contact structures of the device to reference voltage lines (also referred to as strapping) to establish a particular device configuration or operation aspect of the device. The terms “exemplary” and “embodiment” are used to express an example, not a preference or requirement.

[0073] While the invention has been described with reference to specific embodiments thereof, it will be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope. For example, features or aspects of any of the embodiments may be applied in combination with any other of the embodiments disclosed herein and/or in materials incorporated by reference or in place of counterpart features or aspects thereof. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

What is claimed is:

1. A storage device comprising:

at least one namespace;

flash memory having subdivisions, the subdivisions comprising respective, non-overlapping sets of erase units; and

logic operable to cause the storage device to transmit to a host, responsive to receipt of at least one query from the host, information identifying a specific namespace of the at least one namespace, one or more of the subdivisions and, for each one of the one or more subdivisions, an associated subdivision size; and

logic operable to cause the storage device to receive write requests and, for a first one of the write requests, to:

derive, from address information associated with the first one of the write requests, a first address portion, a second address portion, and a third address portion, and

identify, from the first address portion, the specific namespace, and

identify, from the second address portion, an addressed subdivision of the one or more identified subdivisions, and

identify from the third address portion, a logical block address, and

program data associated with the first write request into a physical storage location within a specific erase unit in the set which is respective to the addressed subdivision; and

logic operable to cause the storage device to track validity status for the physical storage location; and

logic operable to cause the storage device to receive a deallocate command that specifies the logical block address and to, responsive to receipt of the deallocate command, update the validity status to indicate that the physical storage location is released; and

logic operable to cause the storage device to automatically detect a condition where (1) the specific erase unit has at least a threshold amount of storage that has been released, and (2) all storage locations of the specific erase unit, including the physical storage location, are each at least one of (2a) released, or (2b) contain no valid data, and to responsively and automatically control physical erasure of the specific erase unit; and

logic operable to cause the storage device to store metadata associated with the specific erase unit, the metadata indicating one of an erase count or wear information, and to update the metadata in association with the physical erasure of the specific erase unit; and

logic operable to cause the storage device to, in connection with the physical erasure of the specific erase unit, detect that the specific erase unit is bad, and to responsively update data tracked by the storage device to mark the specific erase unit as bad;

wherein each said logic comprises at least one of circuitry or instructions stored on a physical storage medium that, when executed, are to control circuitry of the storage device.

2. The storage device of claim 1, wherein the storage device further comprises logic operable to cause the storage device to:

track second metadata, the second metadata corresponding to the addressed subdivision;

compare the second metadata with a criterion; and

responsive to satisfaction of the criterion by the second metadata, automatically copy valid data from at least one erase unit, of the set which is respective to the addressed subdivision, to a new erase unit.

3. The storage device of claim 2, wherein the storage device further comprises logic operable to cause the storage device to:

in association with the copy of valid data from the at least one erase unit to the new erase unit, disassociate the at least one erase unit from the set which is respective to the addressed subdivision; and

automatically control physical erasure of the at least one erase unit.

4. The storage device of claim 2, wherein the storage device further comprises logic operable to cause the storage device to:

maintain a pool of free erase units; and

select the new erase unit from the pool of free erase units, and assign the new erase unit to the set which is respective to the addressed subdivision.

5. The storage device of claim 2, wherein the second metadata comprises aggregate data validity information associated with multiple physical storage locations of the at least one erase unit.

6. The storage device of claim 2, wherein the second metadata represents a time since data was programmed in the at least one erase unit.

7. The storage device of claim 2, wherein the second metadata indicates wear of the at least one erase unit.

8. The storage device of claim 2, wherein the second metadata indicates a data access frequency associated with logical block addresses mapped to the at least one erase unit.

9. The storage device of claim 1, wherein the at least one query comprises one or more first queries, and wherein the storage device further comprises a host interface and logic operable to cause the storage device to:

track second metadata respective to different ones of the subdivisions;

receive, via the host interface, a second query from the host; and

responsive to the second query, transmit information, to the host, which is dependent on the tracked second metadata.

10. The storage device of claim 9, wherein the second query specifies a given subdivision of the different ones of the subdivisions and wherein the information transmitted to the host indicates a quantity of available space, associated with the set of erase units respective to the given one of the different ones of the subdivisions, which can currently be written to.

11. The storage device of claim 9, wherein the second metadata represents a time since data was programmed into the respective subdivision.

12. The storage device of claim 1, wherein the at least one query comprises one or more first queries, and wherein the storage device further comprises logic operable to cause the storage device to:

store a value representing a maximum number of the subdivisions; and

receive a second query; and

responsively transmit, to the host, information representing the maximum number of the subdivisions.

13. The storage device of claim 1, wherein:

the at least one query comprises one or more first queries;

the flash memory comprises flash memory dies;

the flash memory further comprises one or more die groups, each die group having a subset of one or more of the flash memory dies, the one or more of the flash memory dies in each die group being mutually-exclusive to the one or more of the flash memory dies in each other die group, wherein each die group is associated with an identifier (ID); and

the storage device further comprises logic operable to cause the storage device to receive a second query from the host, and to responsively transmit, to the host, information representing each ID associated with the one or more die groups.

14. The storage device of claim 13, wherein, for the first one of the write requests, the logic is further operable to cause the storage device to perform a division operation, on the address information, to identify the ID which is associated with a specific die group of the one or more die groups.

15. The storage device of claim 1, wherein the storage device further comprises logic operable to cause the storage device to:

receive a configuration command, from the host, and responsively establish a value of a setting; and

responsively update a quantity, of the one or more subdivisions, dependent on the value of the setting.

16. The storage device of claim 1, wherein:

the storage device further comprises logic operable to cause the storage device to receive a read request from the host, the read request being directed to the identified logical block address; and

the logic is further operable to cause the storage device to:

detect an error condition associated with reading of the programmed data;

responsively copy valid data from the specific erase unit to a new erase unit; and

update a logical-to-physical look-up table, such that the identified logical block address is indexed to a physical storage location within the new erase unit.

17. The storage device of claim 16, wherein the error condition corresponds to a bit error rate which exceeds a threshold.

18. The storage device of claim 1, wherein the storage device further comprises logic operable to cause the storage device to maintain a logical-to-physical look-up table and to, in response to receiving the first one of the write requests, update the logical to physical look-up table, such that the identified logical block address is indexed to the physical storage location.

19. The storage device of claim 1, wherein the storage device further comprises logic operable to cause the storage device to maintain information identifying a next-available physical storage location for the addressed subdivision, and to automatically update, in association with the receipt of the first one of the write requests, the information identifying the next-available physical storage location.

20. The storage device of claim 1, wherein the logic is further operable to cause the storage device to, for the first one of the write requests, identify a value and perform a division operation on the value, wherein a quotient of the division operation comprises at least one of a number of the erase units, or a number of pages, or a number of storage locations, and wherein a remainder of the division operation corresponds to a structural offset corresponding to a physical address in the flash memory.

21. The storage device of claim 1, wherein the associated subdivision size corresponds to at least a minimum amount of storage capacity to be physically reset by the storage device as part of a physical memory erasure operation.

22. The storage device of claim 1, wherein the storage device further comprises logic operable to cause the storage device to perform garbage collection and, in connection with said garbage collection, to:

relocate all remaining valid data from any erase unit in the set respective to the addressed subdivision to one or more new erase units; and

automatically associate the set respective to the addressed subdivision with the one or more new erase units, such that the one or more new erase units are not used to store data associated with any other of the subdivisions of the flash memory.

23. The storage device of claim 18, wherein:

the storage device further comprises logic operable to cause the storage device to receive a read request, from the host, the read request being directed to the identified logical block address; and

the logic is further operable to cause the storage device to:

retrieve, from the logical-to-physical look-up table, a physical address of the physical storage location; and

retrieve, from the flash memory, and according to the retrieved physical address, the programmed data, and responsively transmit the retrieved, programmed data to the host.

24. The storage device of claim 18, wherein the write requests are first write requests and wherein the storage device further comprises logic operable to cause the storage device to receive, from the host, a second write request, the second write request being directed to the addressed subdivision and, in association with the second write request, to:

detect that insufficient free memory space remains in the set of erase units respective to the addressed subdivision;

assign a new erase unit to the set respective to the addressed subdivision;

identify a destination physical address associated with a storage location in the new erase unit;

store write data accompanying the second write request at the identified storage location in the new erase unit; and

update the logical to physical look-up table to index a logical block address, identified for the second write request, to the destination physical address.

25. The storage device of claim 24, wherein:

the logical block address identified for the second write request corresponds to the logical block address identified for the first one of the write requests; and

the logic is further operable to cause the storage device to update, in association with the storage of the write data accompanying the second write request, the logical-to-physical look-up table, so as to reindex the identified logical block address to the destination physical address.

26. The storage device of claim 1, wherein the storage device further comprises logic operable to cause the storage device to, responsive to the automatic detection of the condition, automatically copy remaining valid data from the specific erase unit to a new erase unit, and wherein the physical erasure of the specific erase units is performed after the automatic copy of the remaining valid data.

27. The storage device of claim 26, wherein the storage device further comprises logic operable to cause the storage device to:

maintain a pool of free erase units; and

select the new erase unit from the pool of free erase units, and assign the new erase unit to the set which is respective to the addressed subdivision.

Patent Citations (423)

Patent	Date	Inventor	Cited By
US4532590(A)	1985-07-01	Wallach	Applicant
US4813002(A)	1989-03-01	Joyce	Applicant
US5404485(A)	1995-04-01	Ban	Applicant
US5568423(A)	1996-10-01	Jou et al.	Applicant
US5652857(A)	1997-07-01	Shimoi et al.	Applicant
US5860082(A)	1999-01-01	Smith et al.	Applicant
US5963977(A)	1999-10-01	Gold	Applicant
US6118724(A)	2000-09-01	Higgenbottom	Applicant
US6134631(A)	2000-10-01	Jennings, III	Applicant
US6145069(A)	2000-11-01	Dye	Applicant
US6148354(A)	2000-11-01	Ban	Applicant
US6381668(B1)	2002-04-01	Lunteren	Applicant
US6430650(B1)	2002-08-01	Miyauchi	Applicant
US6571312(B1)	2003-05-01	Sugai	Applicant
US6892287(B1)	2005-05-01	Millard	Applicant
US6895464(B2)	2005-05-01	Chow	Applicant
US7096378(B2)	2006-08-01	Stence et al.	Applicant
US7120729(B2)	2006-10-01	Gonzalez	Applicant
US7339823(B2)	2008-03-01	Nakayama et al.	Applicant
US7383375(B2)	2008-06-01	Sinclair	Applicant
US7404031(B2)	2008-07-01	Oshima	Applicant
US7406563(B1)	2008-07-01	Nagshain	Applicant
US7409489(B2)	2008-08-01	Sinclair	Applicant
US7519869(B2)	2009-04-01	Mizuno	Applicant
US7552272(B2)	2009-06-01	Gonzalez	Applicant
US7555628(B2)	2009-06-01	Bennett	Applicant
US7581078(B2)	2009-08-01	Ware	Applicant
US7702846(B2)	2010-04-01	Nakanishi et al.	Applicant
US7702948(B1)	2010-04-01	Kalman	Applicant
US7710777(B1)	2010-05-01	Mintierth	Applicant
US7739444(B2)	2010-06-01	Sinclair	Applicant
US7747813(B2)	2010-06-01	Danilak	Applicant
US7752381(B2)	2010-07-01	Wong	Applicant
US7801561(B2)	2010-09-01	Parikh et al.	Applicant
US7809900(B2)	2010-10-01	Danilak	Applicant
US7814262(B2)	2010-10-01	Sinclair	Applicant
US7818489(B2)	2010-10-01	Karamcheti et al.	Applicant
US7836244(B2)	2010-11-01	Kim et al.	Applicant
US7861122(B2)	2010-12-01	Cornwell et al.	Applicant
US7877540(B2)	2011-01-01	Sinclair	Applicant
US7898855(B2)	2011-03-01	Merry	Applicant
US7904619(B2)	2011-03-01	Danilak	Applicant
US7934074(B2)	2011-04-01	Lee	Applicant
US7941692(B2)	2011-05-01	Royer et al.	Applicant
US7970983(B2)	2011-06-01	Nochimowski	Applicant
US7984233(B2)	2011-07-01	Sinclair	Applicant
US7991944(B2)	2011-08-01	Lee et al.	Applicant
US8001318(B1)	2011-08-01	Iyer	Applicant
US8024545(B2)	2011-09-01	Kim et al.	Applicant
US8046524(B2)	2011-10-01	Tringali	Applicant
US8055833(B2)	2011-11-01	Danilak et al.	Applicant
US8065471(B2)	2011-11-01	Yano et al.	Applicant
US8065473(B2)	2011-11-01	Ito et al.	Applicant
US8068365(B2)	2011-11-01	Kim	Applicant
US8069284(B2)	2011-11-01	Oh	Applicant
US8072463(B1)	2011-12-01	Van Dyke	Applicant
US8074022(B2)	2011-12-01	Okin et al.	Applicant
US8082389(B2)	2011-12-01	Fujibayashi	Applicant
US8086790(B2)	2011-12-01	Roohparvar	Applicant
US8099581(B2)	2012-01-01	Bennett	Applicant
US8099632(B2)	2012-01-01	Tringali	Applicant
US8195912(B2)	2012-06-01	Flynn	Applicant
US8219776(B2)	2012-07-01	Forhan	Applicant
US8285918(B2)	2012-10-01	Maheshwari	Applicant
US8291151(B2)	2012-10-01	Sinclair	Applicant
US8291295(B2)	2012-10-01	Harari	Applicant
US8301881(B2)	2012-10-01	Reiter	Applicant
US8341339(B1)	2012-12-01	Boyle	Applicant
US8347042(B2)	2013-01-01	You	Applicant
US8386700(B2)	2013-02-01	Olbrich	Applicant
US8402249(B1)	2013-03-01	Zhu	Applicant
US8423710(B1)	2013-04-01	Gole	Applicant
US8429359(B1)	2013-04-01	Desai	Applicant
US8495280(B2)	2013-07-01	Kang	Applicant
US8538919(B1)	2013-09-01	Nielsen	Applicant
US8539197(B1)	2013-09-01	Marshall	Applicant
US8572331(B2)	2013-10-01	Shalvi	Applicant
US8601202(B1)	2013-12-01	Melcher	Applicant
US8621137(B2)	2013-12-01	Olbrich	Applicant
US8626989(B2)	2014-01-01	Van Aken	Applicant
US8645634(B1)	2014-02-01	Cox et al.	Applicant
US8688894(B2)	2014-04-01	Kuehne	Applicant
US8700961(B2)	2014-04-01	Lassa	Applicant
US8886899(B1)	2014-11-01	Bao	Applicant
US8898410(B1)	2014-11-01	Ehrenberg	Applicant
US8954708(B2)	2015-02-01	Kim	Applicant
US8959307(B1)	2015-02-01	Bruce	Applicant
US8996796(B1)	2015-03-01	Karamcheti	Applicant
US9063844(B2)	2015-06-01	Higgins	Applicant
US9075705(B2)	2015-07-01	Ohishi	Applicant
US9092182(B2)	2015-07-01	Ohishi	Applicant
US9123443(B2)	2015-09-01	Chung	Applicant
US9128624(B2)	2015-09-01	Ng	Applicant
US9134918(B2)	2015-09-01	Yurzola	Applicant
US9176864(B2)	2015-11-01	Gorobets	Applicant
US9229854(B1)	2016-01-01	Kuzmin et al.	Applicant
US9239781(B2)	2016-01-01	Jones	Applicant
US9286198(B2)	2016-03-01	Bennett	Applicant
US9329986(B2)	2016-05-01	Li	Applicant
US9335939(B2)	2016-05-01	Bennett et al.	Applicant
US9344596(B2)	2016-05-01	Ohishi	Applicant
US9348749(B2)	2016-05-01	Choi	Applicant
US9378149(B1)	2016-06-01	Bonwick	Applicant
US9383926(B2)	2016-07-01	Law	Applicant
US9400749(B1)	2016-07-01	Kuzmin et al.	Applicant
US9405621(B2)	2016-08-01	Yu	Applicant
US9519578(B1)	2016-12-01	Kuzmin et al.	Applicant
US9542118(B1)	2017-01-01	Lercari et al.	Applicant
US9565269(B2)	2017-02-01	Malwankar	Applicant
US9575672(B2)	2017-02-01	Yamamoto	Applicant
US9588904(B1)	2017-03-01	Lercari et al.	Applicant
US9652376(B2)	2017-05-01	Kuzmin et al.	Applicant
US9696917(B1)	2017-07-01	Sareena et al.	Applicant
US9710377(B1)	2017-07-01	Kuzmin et al.	Applicant
US9727454(B2)	2017-08-01	Kuzmin et al.	Applicant
US9734086(B2)	2017-08-01	Flynn	Applicant
US9785572(B1)	2017-10-01	Lercari et al.	Applicant
US9846541(B2)	2017-12-01	Miyamoto et al.	Applicant
US9858008(B2)	2018-01-01	Liu	Applicant
US10048884(B2)	2018-08-01	Mylly	Applicant
US10067866(B2)	2018-09-01	Sutardja	Applicant
US10445229(B1)	2019-10-01	Kuzmin et al.	Applicant
US10552058(B1)	2020-02-01	Jadon et al.	Applicant
US10552085(B1)	2020-02-01	Chen et al.	Applicant
US10642505(B1)	2020-05-01	Kuzmin	Applicant
US10642748(B1)	2020-05-01	Lercari	Applicant
US10838853(B1)	2020-11-01	Kuzmin	Applicant
US10884915(B1)	2021-01-01	Kuzmin	Applicant
US10915458(B1)	2021-02-01	Lercari	Applicant
US10956082(B1)	2021-03-01	Kuzmin	Applicant
US10977188(B1)	2021-04-01	Lercari	Applicant
US10983907(B1)	2021-04-01	Kuzmin	Applicant
US10996863(B1)	2021-05-01	Kuzmin	Applicant
US11003586(B1)	2021-05-01	Lercari	Applicant
US11023315(B1)	2021-06-01	Jadon	Applicant
US11023386(B1)	2021-06-01	Lercari	Applicant
US11023387(B1)	2021-06-01	Lercari	Applicant
US11048643(B1)	2021-06-01	Lercari	Applicant
US11068408(B2)	2021-07-01	Kim	Applicant
US11074175(B1)	2021-07-01	Kuzmin	Applicant
US11080181(B1)	2021-08-01	Kuzmin	Applicant
US11086789(B1)	2021-08-01	Lercari	Applicant
US11100006(B1)	2021-08-01	Lercari	Applicant
US11163492(B2)	2021-11-01	Kamran	Applicant
US11175984(B1)	2021-11-01	Lercari	Applicant
US11188457(B1)	2021-11-01	Kuzmin	Applicant
US11216365(B1)	2022-01-01	Kuzmin	Applicant
US11221959(B1)	2022-01-01	Lercari	Applicant
US11221960(B1)	2022-01-01	Lercari	Applicant
US11221961(B1)	2022-01-01	Lercari	Applicant
US11249652(B1)	2022-02-01	Kuzmin	Applicant
US11307995(B1)	2022-04-01	Lercari	Applicant
US11314636(B1)	2022-04-01	Kuzmin	Applicant
US11334476(B2)	2022-05-01	Kuzmin	Applicant
US11347638(B1)	2022-05-01	Kuzmin	Applicant
US11347639(B1)	2022-05-01	Kuzmin	Applicant
US11347656(B1)	2022-05-01	Lercari	Applicant
US11347657(B1)	2022-05-01	Lercari	Applicant
US11347658(B1)	2022-05-01	Lercari	Applicant
US11354234(B1)	2022-06-01	Kuzmin	Applicant
US11354235(B1)	2022-06-01	Kuzmin	Applicant
US11416413(B1)	2022-08-01	Lercari	Applicant
US11449240(B1)	2022-09-01	Jadon	Applicant
US11449436(B1)	2022-09-01	Lercari	Applicant
US11487678(B2)	2022-11-01	Park	Applicant
US11500766(B2)	2022-11-01	Bueb	Applicant
US11544183(B1)	2023-01-01	Kuzmin	Applicant
US11544200(B1)	2023-01-01	Lercari	Applicant
US11580030(B2)	2023-02-01	Das	Applicant
US11907134(B1)	2024-02-01	Lercari	Applicant
US12093533(B1)	2024-09-01	Kuzmin	Applicant
US12147335(B1)	2024-11-01	Kuzmin	Applicant
US12461655(B1)	2025-11-01	Kuzmin	Applicant
US2003/0028733(A1)	2003-02-01	Tsunoda et al.	Applicant
US2003/0037071(A1)	2003-02-01	Harris	Applicant
US2003/0065866(A1)	2003-04-01	Spencer	Applicant
US2003/0188032(A1)	2003-10-01	Solomon	Applicant
US2004/0083335(A1)	2004-04-01	Gonzalez	Applicant
US2004/0117414(A1)	2004-06-01	Braun	Applicant
US2005/0073844(A1)	2005-04-01	Gonzalez	Applicant
US2005/0073884(A1)	2005-04-01	Gonzalez	Applicant
US2005/0144367(A1)	2005-06-01	Sinclair	Applicant
US2005/0144413(A1)	2005-06-01	Kuo et al.	Applicant
US2005/0160227(A1)	2005-07-01	Todd	Applicant
US2005/0193161(A1)	2005-09-01	Lee	Applicant
US2005/0248993(A1)	2005-11-01	Lee	Applicant
US2006/0004957(A1)	2006-01-01	Hand, III	Applicant
US2006/0221719(A1)	2006-10-01	Maeda et al.	Applicant
US2007/0019481(A1)	2007-01-01	Park	Applicant
US2007/0033378(A1)	2007-02-01	Sinclair	Applicant
US2007/0046681(A1)	2007-03-01	Nagashima	Applicant
US2007/0058431(A1)	2007-03-01	Chung et al.	Applicant
US2007/0091497(A1)	2007-04-01	Mizuno	Applicant
US2007/0136555(A1)	2007-06-01	Sinclair	Applicant
US2007/0143569(A1)	2007-06-01	Sanders	Applicant
US2007/0168321(A1)	2007-07-01	Saito	Applicant
US2007/0233939(A1)	2007-10-01	Kim	Applicant
US2007/0260811(A1)	2007-11-01	Merry, Jr. et al.	Applicant
US2007/0260841(A1)	2007-11-01	Hampel	Applicant
US2007/0283428(A1)	2007-12-01	Ma et al.	Applicant
US2007/0294496(A1)	2007-12-01	Goss	Applicant
US2008/0005502(A1)	2008-01-01	Kanai	Applicant
US2008/0034153(A1)	2008-02-01	Lee	Applicant
US2008/0082596(A1)	2008-04-01	Gorobets	Applicant
US2008/0126720(A1)	2008-05-01	Danilak	Applicant
US2008/0126724(A1)	2008-05-01	Danilak	Applicant
US2008/0140902(A1)	2008-06-01	Townsend	Applicant
US2008/0147964(A1)	2008-06-01	Chow et al.	Applicant
US2008/0155204(A1)	2008-06-01	Qawami et al.	Applicant
US2008/0189485(A1)	2008-08-01	Jung et al.	Applicant
US2008/0189490(A1)	2008-08-01	Cheon	Applicant
US2008/0195833(A1)	2008-08-01	Park	Applicant
US2008/0201517(A1)	2008-08-01	Kuhne	Applicant
US2008/0209114(A1)	2008-08-01	Chow	Applicant
US2008/0256287(A1)	2008-10-01	Lee	Applicant
US2008/0294813(A1)	2008-11-01	Gorobets	Applicant
US2008/0307020(A1)	2008-12-01	Ko	Applicant
US2008/0307192(A1)	2008-12-01	Sinclair	Applicant
US2008/0320476(A1)	2008-12-01	Wingard	Applicant
US2009/0036163(A1)	2009-02-01	Kimbrell	Applicant
US2009/0044190(A1)	2009-02-01	Tringali	Applicant
US2009/0046533(A1)	2009-02-01	Jo	Applicant
US2009/0083478(A1)	2009-03-01	Kunimatsu	Applicant
US2009/0089482(A1)	2009-04-01	Traister	Applicant
US2009/0089490(A1)	2009-04-01	Ozawa et al.	Applicant
US2009/0119529(A1)	2009-05-01	Kono	Applicant
US2009/0138671(A1)	2009-05-01	Danilak	Applicant
US2009/0144497(A1)	2009-06-01	Withers	Applicant
US2009/0172219(A1)	2009-07-01	Mardiks	Applicant
US2009/0172246(A1)	2009-07-01	Afriat	Applicant
US2009/0172250(A1)	2009-07-01	Allen et al.	Applicant
US2009/0172257(A1)	2009-07-01	Prins et al.	Applicant
US2009/0172499(A1)	2009-07-01	Olbrich	Applicant
US2009/0182964(A1)	2009-07-01	Greiner	Applicant
US2009/0198946(A1)	2009-08-01	Ebata	Applicant
US2009/0210616(A1)	2009-08-01	Karamcheti	Applicant
US2009/0210636(A1)	2009-08-01	Karamcheti	Applicant
US2009/0216992(A1)	2009-08-01	Greiner	Applicant
US2009/0240903(A1)	2009-09-01	Sauber	Applicant
US2009/0254689(A1)	2009-10-01	Karamcheti	Applicant
US2009/0254705(A1)	2009-10-01	Abali et al.	Applicant
US2009/0271562(A1)	2009-10-01	Sinclair	Applicant
US2009/0292839(A1)	2009-11-01	Oh	Applicant
US2009/0300015(A1)	2009-12-01	Kazan et al.	Applicant
US2009/0327602(A1)	2009-12-01	Moore et al.	Applicant
US2010/0011085(A1)	2010-01-01	Taguchi	Applicant
US2010/0011186(A1)	2010-01-01	Bennett	Applicant
US2010/0023566(A1)	2010-01-01	Minamino	Applicant
US2010/0030946(A1)	2010-02-01	Kano	Applicant
US2010/0042655(A1)	2010-02-01	Tse et al.	Applicant
US2010/0049908(A1)	2010-02-01	Gonzalez	Applicant
US2010/0083050(A1)	2010-04-01	Ohyama	Applicant
US2010/0106734(A1)	2010-04-01	Calder	Applicant
US2010/0115172(A1)	2010-05-01	Gillingham et al.	Applicant
US2010/0125702(A1)	2010-05-01	Lee	Applicant
US2010/0161882(A1)	2010-06-01	Stern et al.	Applicant
US2010/0162012(A1)	2010-06-01	Cornwell et al.	Applicant
US2010/0182838(A1)	2010-07-01	Kim et al.	Applicant
US2010/0191779(A1)	2010-07-01	Hinrichs	Applicant
US2010/0199065(A1)	2010-08-01	Kaneda	Applicant
US2010/0211737(A1)	2010-08-01	Flynn	Applicant
US2010/0241866(A1)	2010-09-01	Rodorff	Applicant
US2010/0262761(A1)	2010-10-01	Borchers et al.	Applicant
US2010/0262762(A1)	2010-10-01	Borchers	Applicant
US2010/0262765(A1)	2010-10-01	Cheon	Applicant
US2010/0262773(A1)	2010-10-01	Borchers	Applicant
US2010/0281230(A1)	2010-11-01	Rabii et al.	Applicant
US2010/0287217(A1)	2010-11-01	Borchers et al.	Applicant
US2010/0287327(A1)	2010-11-01	Li	Applicant
US2010/0287332(A1)	2010-11-01	Koshiyama	Applicant
US2010/0299494(A1)	2010-11-01	Van Acht	Applicant
US2010/0329011(A1)	2010-12-01	Lee et al.	Applicant
US2011/0033548(A1)	2011-02-01	Kimmel et al.	Applicant
US2011/0041039(A1)	2011-02-01	Harari	Applicant
US2011/0055445(A1)	2011-03-01	Gee et al.	Applicant
US2011/0066792(A1)	2011-03-01	Shaeffer	Applicant
US2011/0125956(A1)	2011-05-01	Danilak	Applicant
US2011/0126045(A1)	2011-05-01	Bennett	Applicant
US2011/0138114(A1)	2011-06-01	Yen	Applicant
US2011/0153817(A1)	2011-06-01	Maita	Applicant
US2011/0153911(A1)	2011-06-01	Sprouse	Applicant
US2011/0161784(A1)	2011-06-01	Sellinger et al.	Applicant
US2011/0167199(A1)	2011-07-01	Danilak	Applicant
US2011/0197014(A1)	2011-08-01	Yeh	Applicant
US2011/0197023(A1)	2011-08-01	Iwamitsu et al.	Applicant
US2011/0231623(A1)	2011-09-01	Goss	Applicant
US2011/0236049(A1)	2011-09-01	Haga	Applicant
US2011/0238890(A1)	2011-09-01	Sukegawa	Applicant
US2011/0238892(A1)	2011-09-01	Tsai	Applicant
US2011/0238943(A1)	2011-09-01	Devendran et al.	Applicant
US2011/0258385(A1)	2011-10-01	Soran et al.	Applicant
US2011/0258388(A1)	2011-10-01	Soran	Applicant
US2011/0264843(A1)	2011-10-01	Haines	Applicant
US2011/0271032(A1)	2011-11-01	Yamada	Applicant
US2011/0276756(A1)	2011-11-01	Bish et al.	Applicant
US2011/0283043(A1)	2011-11-01	Schuette	Applicant
US2011/0289263(A1)	2011-11-01	McWilliams	Applicant
US2011/0296089(A1)	2011-12-01	Seol	Applicant
US2011/0296133(A1)	2011-12-01	Flynn et al.	Applicant
US2011/0302477(A1)	2011-12-01	Goss	Applicant
US2011/0314209(A1)	2011-12-01	Eckstein	Applicant
US2012/0033519(A1)	2012-02-01	Confalonieri et al.	Applicant
US2012/0054419(A1)	2012-03-01	Chen	Applicant
US2012/0059972(A1)	2012-03-01	Chen	Applicant
US2012/0066441(A1)	2012-03-01	Weingarten	Applicant
US2012/0072654(A1)	2012-03-01	Olbrich	Applicant
US2012/0072807(A1)	2012-03-01	Cornwell	Applicant
US2012/0079174(A1)	2012-03-01	Nellans	Applicant
US2012/0096217(A1)	2012-04-01	Son	Applicant
US2012/0131270(A1)	2012-05-01	Hemmi	Applicant
US2012/0131381(A1)	2012-05-01	Eleftheriou	Applicant
US2012/0155492(A1)	2012-06-01	Abel	Applicant
US2012/0159037(A1)	2012-06-01	Kwon	Applicant
US2012/0159039(A1)	2012-06-01	Kegel et al.	Applicant
US2012/0191921(A1)	2012-07-01	Shaeffer	Applicant
US2012/0198123(A1)	2012-08-01	Post	Applicant
US2012/0198128(A1)	2012-08-01	Van Aken	Applicant
US2012/0198129(A1)	2012-08-01	Van Aken	Applicant
US2012/0204079(A1)	2012-08-01	Takefman et al.	Applicant
US2012/0221776(A1)	2012-08-01	Yoshihashi	Applicant
US2012/0246394(A1)	2012-09-01	Ou	Applicant
US2012/0284587(A1)	2012-11-01	Yu	Applicant
US2012/0303875(A1)	2012-11-01	Benhase	Applicant
US2013/0007343(A1)	2013-01-01	Rub	Applicant
US2013/0013852(A1)	2013-01-01	Hou et al.	Applicant
US2013/0019062(A1)	2013-01-01	Bennett et al.	Applicant
US2013/0024423(A1)	2013-01-01	Doshi	Applicant
US2013/0024460(A1)	2013-01-01	Peterson	Applicant
US2013/0073793(A1)	2013-03-01	Yamagishi	Applicant
US2013/0073816(A1)	2013-03-01	Seo et al.	Applicant
US2013/0097236(A1)	2013-04-01	Khorashadi	Applicant
US2013/0111295(A1)	2013-05-01	Li et al.	Applicant
US2013/0111298(A1)	2013-05-01	Seroff	Applicant
US2013/0124793(A1)	2013-05-01	Gyl et al.	Applicant
US2013/0124807(A1)	2013-05-01	Nielsen	Applicant
US2013/0138868(A1)	2013-05-01	Seroff	Applicant
US2013/0145111(A1)	2013-06-01	Murukani	Applicant
US2013/0166820(A1)	2013-06-01	Batwara	Applicant
US2013/0166824(A1)	2013-06-01	Shim	Applicant
US2013/0166825(A1)	2013-06-01	Kim et al.	Applicant
US2013/0173554(A1)	2013-07-01	Ubukata	Applicant
US2013/0227201(A1)	2013-08-01	Talagala	Applicant
US2013/0232297(A1)	2013-09-01	Tanaka	Applicant
US2013/0242425(A1)	2013-09-01	Zayas et al.	Applicant
US2013/0275682(A1)	2013-10-01	Ramanujan	Applicant
US2013/0282955(A1)	2013-10-01	Parker	Applicant
US2013/0290619(A1)	2013-10-01	Knight	Applicant
US2013/0297852(A1)	2013-11-01	Fai et al.	Applicant
US2013/0297880(A1)	2013-11-01	Flynn	Applicant
US2013/0326117(A1)	2013-12-01	Aune	Applicant
US2013/0332656(A1)	2013-12-01	Kandiraju	Applicant
US2013/0339580(A1)	2013-12-01	Brandt	Applicant
US2014/0040550(A1)	2014-02-01	Nale	Applicant
US2014/0047210(A1)	2014-02-01	Cohen	Examiner
US2014/0047300(A1)	2014-02-01	Liang	Applicant
US2014/0068197(A1)	2014-03-01	Joshi	Applicant
US2014/0101371(A1)	2014-04-01	Nguyen et al.	Applicant
US2014/0122781(A1)	2014-05-01	Smith	Examiner
US2014/0189207(A1)	2014-07-01	Sinclair	Applicant
US2014/0189209(A1)	2014-07-01	Sinclair et al.	Applicant
US2014/0195725(A1)	2014-07-01	Bennett	Applicant
US2014/0208004(A1)	2014-07-01	Cohen	Applicant
US2014/0208062(A1)	2014-07-01	Cohen	Applicant
US2014/0215129(A1)	2014-07-01	Kuzmin	Examiner
US2014/0237168(A1)	2014-08-01	Prins	Applicant
US2014/0297949(A1)	2014-10-01	Nagawaka	Applicant
US2014/0317346(A1)	2014-10-01	Moon	Applicant
US2015/0046670(A1)	2015-02-01	Kim	Applicant
US2015/0067297(A1)	2015-03-01	Arroyo et al.	Applicant
US2015/0074342(A1)	2015-03-01	Bao	Applicant
US2015/0113203(A1)	2015-04-01	Dancho et al.	Applicant
US2015/0134930(A1)	2015-05-01	Huang et al.	Applicant
US2015/0149789(A1)	2015-05-01	Seo et al.	Applicant
US2015/0193148(A1)	2015-07-01	Miwa et al.	Applicant
US2015/0212938(A1)	2015-07-01	Chen et al.	Applicant
US2015/0261456(A1)	2015-09-01	Alcantara et al.	Applicant
US2015/0263978(A1)	2015-09-01	Olson	Applicant
US2015/0309734(A1)	2015-10-01	Brondjik	Applicant
US2015/0324264(A1)	2015-11-01	Vidypoornachy et al.	Applicant
US2015/0339187(A1)	2015-11-01	Sharon	Applicant
US2015/0347041(A1)	2015-12-01	Kotte et al.	Applicant
US2015/0347291(A1)	2015-12-01	Choi	Applicant
US2015/0347296(A1)	2015-12-01	Kotte et al.	Applicant
US2015/0355965(A1)	2015-12-01	Peddle	Applicant
US2015/0363120(A1)	2015-12-01	Chen	Applicant
US2015/0378613(A1)	2015-12-01	Koseki	Applicant
US2015/0378886(A1)	2015-12-01	Nemazie	Applicant
US2016/0011818(A1)	2016-01-01	Hashimoto	Examiner
US2016/0018998(A1)	2016-01-01	Mohan et al.	Applicant
US2016/0019148(A1)	2016-01-01	Vekiarides	Applicant
US2016/0019159(A1)	2016-01-01	Ueda	Applicant
US2016/0026564(A1)	2016-01-01	Manning	Examiner
US2016/0034221(A1)	2016-02-01	Zettsu	Applicant
US2016/0070496(A1)	2016-03-01	Cohen	Applicant
US2016/0092116(A1)	2016-03-01	Liu	Applicant
US2016/0147669(A1)	2016-05-01	Huang	Applicant
US2016/0179664(A1)	2016-06-01	Camp	Applicant
US2016/0202910(A1)	2016-07-01	Ravimohan	Applicant
US2016/0253091(A1)	2016-09-01	Ayyavu	Applicant
US2016/0342509(A1)	2016-11-01	Kotte et al.	Applicant
US2016/0357462(A1)	2016-12-01	Nam et al.	Applicant
US2016/0364179(A1)	2016-12-01	Tsai et al.	Applicant
US2017/0031699(A1)	2017-02-01	Banerjee et al.	Applicant
US2017/0075620(A1)	2017-03-01	Yamamoto	Applicant
US2017/0109078(A1)	2017-04-01	Shaharabany	Applicant
US2017/0132082(A1)	2017-05-01	Resch	Applicant
US2017/0139838(A1)	2017-05-01	Tomlin	Applicant
US2017/0192901(A1)	2017-07-01	Coffin	Applicant
US2017/0199703(A1)	2017-07-01	Ravimohan	Applicant
US2017/0220287(A1)	2017-08-01	Wei	Applicant
US2017/0364445(A1)	2017-12-01	Allison	Applicant
US2018/0046480(A1)	2018-02-01	Dong	Examiner
US2020/0363996(A1)	2020-11-01	Kanno	Applicant
US2021/0064293(A1)	2021-03-01	Cho	Applicant
JP2001051889(A)	2001-02-01		Applicant
JP2008176606	2008-07-01		Applicant
JP2011123863(A)	2011-06-01		Applicant
JP2011203916(A)	2011-10-01		Applicant
WO2006065668(A2)	2006-06-01		Applicant
WO2007019220(A2)	2007-02-01		Applicant
WO2008082996	2008-07-01		Applicant
WO2009100149(A1)	2009-08-01		Applicant
WO2010027983(A1)	2010-03-01		Applicant

Non-Patent Literature (69)

NVM Express, Version 1.0b, Jul. 12, 2011, pp. 1-126, published at http://www.nvmexpress.org/resources/ by the NVM Express Work Group.Applicant
John D. Strunk, “Hybrid Aggregates: Combining SSDs and HDDs in a single storage pool,” Dec. 15, 2012, ACM SIGOPS Operating Systems Review archive, vol. 46 Issue 3, Dec. 2012, pp. 50-56.Applicant
Yiying Zhang, Leo Prasath Arulraj, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, Computer Sciences Department, University of Wisconsin-Madison, “De-indirection for Flash-based SSDs with NamelessWrites,” published at https://www.usenix.org/conference/fast12/de-indirection-flash-based-ssds-nameless-writes, Feb. 7, 2012, pp. 1-16.Applicant
Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, and Vijayan Prabhakaran, “ResearchRemoving the Costs of Indirection in Flash-based SSDs with NamelessWrites,” Jun. 22, 2010, pp. 1-5, published at www.cs.wisc.edu/wind/Publications/hotstorage10-nameless.pdf by Computer Sciences Department, University of Wisconsin-Madison and Microsoft Research.Applicant
Stan Park and Kai Shen, Department of Computer Science, University of Rochester, “FIOS: A Fair, Efficient Flash I/O Scheduler,” Feb. 23, 2012, pp. 1-15, published at www.usenix.org/event/fast12/tech/full_papers/Park.pdf by the Advanced Computing Systems Association, Fast'12, 10th Usenix Conference on File and Storage Technologies, San Jose.Applicant
Eric Seppanen, Matthew T. O'Keefe, David J. Lilja, Department of Electrical and Computer Engineering, University of Minnesota, “High Performance Solid State Storage Under Linux,” Apr. 10, 2010, MSST '10 Proceedings of the 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST), pp. 1-12.Applicant
Xiangyong Ouyangyz, David Nellansy, Robert Wipfely, David Flynny, Dhabaleswar K. Pandaz, “Beyond Block I/O: Rethinking Traditional Storage Primitives,” Aug. 20, 2011, published at http://www.sciweavers.org/read/beyond-block-i-o-rethinking-traditional-storage-primitives-327868, by Fusion IO and the Ohio State University.Applicant
Intel Corp, PCI-SIG SR-IOV Primer—An Introduction to SR-IOV Technology,: 321211-002, Revision 2.5, Jan. 2011, 28 pages.Applicant
Open NAND Flash Interface (ONFI), specification, version 2.0, 174 pp. Feb. 27, 2008.Applicant
Open NAND Flash Interface (ONFI), specification, version 3.1, 296 pages Sep. 19, 2012.Applicant
NVM Express, V. 1.2.1, 217 pages, Jun. 3, 2016.Applicant
Garth Gibson, Greg Ganger, “Principles of Operation for Shingled Disk Devices,” Canregie Mellon Parallel Data Laboratory, CMU-PDL-11-107, Apr. 2011, 9 pages.Applicant
Li-Pin Chang, “Hybrid Solid State Disks: Combining Heterogeneous NAND Flash in Large SSDs,” National Chiao-Tung University, Taiwan, ASPDAC 2008, 26 pages.Applicant
Hua Wangx, Ping Huangxz, Shuang Hex, Ke Zhoux, Chunhua Lix, and Xubin He, “A Novel I/O Scheduler for SSD with Improved Performance and Lifetime,” Mass Storage Systems and Technologies (MSST), 2013 IEEE 29th Symposium on, May 6-10, 2013, 5 pages.Applicant
Altera Corp et al., “Hybrid Memory Cube” specification, 2012, 122 pages.Applicant
JEDEC Standard, JESD229, Wide IO, Dec. 2011, 74 pages.Applicant
Li-Pin Chang, “Hybrid Solid State Disks: Combining Heterogeneous NAND Flash in Large SSDs,” National Chiao-Tung University, Taiwan, 978-1-4244-1922-7/08, 2008 IEEE, 6 pages.Applicant
Optimizing NAND Flash Performance, Flash Memory Summit, Santa Clara, CA USA Aug. 2008, Ryan Fisher, pp. 1-23.Applicant
High-Speed NAND Flash: Design Considerations to Maximize Performance, Flash Memory Summit, Santa Clara, CA USA Aug. 11, 2009, , Robert Pierce, pp. 1-19.Applicant
NAND 201: An Update on the Continued Evolution of NAND Flash, Jim Cooke, Micron White Paper, Sep. 6, 2011, pp. 1-10.Applicant
Spansion SLC NAND Flash Memory for Embedded, data sheet, S34ML01G1, S34ML02G1, S34ML04G1, Sep. 6, 2012, pp. 1-73.Applicant
Wang et al., “An Efficient Design and Implementation of LSM-Tree based Key-Value Store on Open Channel SSD,”EuroSys '14 Proceedings of the Ninth European Conference on Computer Systems, Article No. 16, Apr. 14, 2014, 14 pages.Applicant
Ouyang et al., “SDF: Software-defined flash for web-scale internet storage systems,” Computer Architecture News—ASPLOS '14, vol. 42 Issue 1, Mar. 2014, 14 pages.Applicant
Macko et al., “Tracking Back References in a Write-Anywhere File System,” FAST'10 Proceedings of the 8th USENIX conference on File and storage technologies, 14 pages, Feb. 23, 2010.Applicant
Ohad, Rodeh, “IBM Research Report Defragmentation Mechanisms for Copy-on-Write File-systems,” IBM white paper, Apr. 26, 2010, 10 pages, available at domino.watson.ibm.com/library/CyberDig.nsf/papers/298A0EF3C2CDB17B852577070056B41F/$File/rj10465.pdf.Applicant
Michael Cornwell, “Anatomy of a solid-state drive,” Oct. 17, 2012, pp. 1-13, https://queue.acm.org/detail.cfm?id=2385276.Applicant
Kang et al., “A Superblock-based Flash Translation Layer for NAND Flash Memory,” EMSOFT'06, Seoul, Korea, Oct. 22, 2006, ACM 1-59593-542-8/06/0010, pp. 161-170.Applicant
TN-29-28: Memory Management in NAND Flash Arrays, Micron publication, 2005, 10 pages, available from https://www.micron.com/-/media/client/global/documents/products/technical-note/nand-flash/tn2928.pdf.Applicant
Park et al., “A Reconfigurable FTL (Flash Translation Layer) Architecture for NAND Flash-Based Applications,” 23 pages, ACM Transactions on Embedded Computing Systems, vol. 7, No. 4, Article 38, Publication date: Jul. 2008.Applicant
Gupta et al., “DFTL: A Flash Translation Layer Employing Demand-based Selective Caching of Page-level Address Mappings,” ASPLOS'09, Mar. 7-11, 2009, Washington, DC, USA, 12 pages.Applicant
Ruia, Virtualization of Non-Volatile RAM, Texas A&M Masters Thesis, 77 pages, May 2015, available from: https://oaktrust.library.tamu.edu/bitstream/handle/1969.1/154981/RUIA-THESIS-2015.pdf?sequence=1&isAllowed=y.Applicant
Hsieh et al., “Efficient Identification of Hot Data for Flash Memory Storage Systems,” ACM Transactions on Storage, vol. 2, No. 1, Feb. 2006, 19 Pages (pp. 22-40).Applicant
Wu et al., “An Adaptive Two-Level Management for the Flash Translation Layer in Embedded Systems ,” https://dl.acm.org/doi/pdf/10.1145/1233501.1233624, Date of Publication: Nov. 9, 2006.Applicant
Grupp et al., “Characterizing Flash Memory: Anomalies, Observations, and Applications,” https://dl.acm.org/doi/pdf/10.1145/1669112.1669118, Dec. 16, 2006.Applicant
Huang et al., “Unified Address Translation for Memory-Mapped SSDs with FlashMap,” https://dl.acm.org/doi/10.1145/2749469.2750420, Jun. 15, 2015.Applicant
Bang et al., “A Memory Hierarchy-Aware Metadata Management Technique for Solid State Disks,” https://ieeexplore.ieee.org/document/6026485, Aug. 10, 2011.Applicant
Petition for IPR, 2025-01266, U.S. Pat. No. 11,544,183, 81 Pages, Jul. 9, 2025.Applicant
Petition for IPR, 2025-01289, U.S. Pat. No. 11,681,614, 103 Pages, Jul. 14, 2025.Applicant
Petition for IPR, 2025-01321, U.S. Pat. No. 11,709,772, 87 Pages, Jul. 17, 2025.Applicant
Petition for IPR, 2025-01350, U.S. Pat. No. 11,740,801, 100 Pages, Jul. 28, 2025.Applicant
Litz Declaration in support of petition for IPR, 2025-01266, U.S. Pat. No. 11,544,183, 85 Pages, Jul. 9, 2025.Applicant
Litz Declaration in support of petition for IPR, 2025-01289, U.S. Pat. No. 11,681,614,150 Pages, Jul. 11, 2025.Applicant
Litz Declaration in support of petition for IPR2025-01321, U.S. Pat. No. 11,709,772, 122 Pages, Jul. 16, 2025.Applicant
Litz Declaration in support of petition for IPR, 2025-01350, U.S. Pat. No. 11,740,801, 120 Pages, Jul. 28, 2025.Applicant
Patent Infringement Defendant Samsung's Invalidity Contentions, Radian Memory Systems, LLC v. Samsung Electronics Co. Ltd, Case Nos. 2:24-cv-01073-JRG, ED Tex, 115 Pages, Jun. 18, 2025.Applicant
Petition for IPR, 2025-01376, U.S. Pat. No. 11,307,995, 110 Pages, Aug. 5, 2025.Applicant
Litz Declaration in support of petition for IPR, 2025-01376, U.S. Pat. No. 11,307,835, 111 Pages, Aug. 5, 2025.Applicant
Petition for IPR, 2025-01377, U.S. Pat. No. 11,347,656, 135 Pages, Aug. 5, 2025.Applicant
Litz Declaration in support of petition for IPR, 2025-01377, U.S. Pat. No. 11,347,656, 142 Pages, Aug. 5, 2025.Applicant
Petition for IPR, 2025-01378, U.S. Pat. No. 11,347,657, 116 Pages, Aug. 5, 2025.Applicant
Litz Declaration in support of petition ffor IPR, 2025-01378, U.S. Pat. No. 11,347,657, 111 Pages, Aug. 5, 2025.Applicant
T10/BSR Incits 536 Revision 1a, working draft revision, Information technology—Zoned Block Commands (ZBC), May 15, 2014, 47 Pages.Applicant
T10/BSR Incits 506 Revision 2, working draft revision, Information technology—SCSI Block Commands—4 (SBC-4), May 20, 2014, 358 Pages.Applicant
T10/BSR Incits 513, Revision 37, May 17, 2014, Information technology—SCSI Primary Commands—4 (SPC-4), 1010 Pages.Applicant
Infringement Defendant Samsung's Invalidity Assertion Claim Charts for U.S. Pat. No. 11,544,183, Jun. 18, 2025, 165 Pages.Applicant
Infringement Defendant Samsung's Invalidity Assertion Claim Charts for U.S. Pat. No. 11,709,772, Jun. 18, 2025, 362 Pages.Applicant
Infringement Delendant Samsung's Invalidity Assertion Claim Charts for U.S. Pat. No. 11,681,614, Jun. 18, 2025, 377 Pages.Applicant
Infringement Defendant Samsung's Invalidity Assertion Claim Charts for U.S. Pat. No. 11,740,801, Jun. 18, 2025, 304 Pages.Applicant
Infringement Delendant Samsung's Invalidity Assertion Claim Charts for U.S. Pat. No. 11,347,656, Jun. 18, 2025, 290 Pages.Applicant
Infringement Defendant Samsung's Invalidity Assertion Claim Charts for U.S. Pat. No. 11,347,657, Jun. 18, 2025, 310 Pages.Applicant
Infringement Defendant Samsung's Invalidity Assertion Claim Charts for U.S. Pat. No. 11,307,995, Jun. 18, 2025, 344 Pages.Applicant
RD527033, RD, A, Mar. 10, 2008.Applicant
C. Kuo et al., “Detecting Solid-State Disk Geometry for Write Pattern Optimization, 2011 IEEE 17th International Conference on Embedded and Real-Time Computing Systems and Applications,” 2011, pp. 89-94.Applicant
S. Im and D. Shin, “Flash-aware RAID techniques for dependable and high-performance flash memory SSD,” IEEE Transactions on Computers, V. 60, No. 1, pp. 80-92, Jan. 2011.Applicant
J. Kim et al., “A methodology for extracting performance parameters in solid state disks (SSDs),” 2009 IEEE International Symposium on Modeling, Analysis & Simulation of Computer and Telecommunication Systems, 2009, pp. 1-10.Applicant
W. Lafi et al., “High level modeling and performance evaluation of address mapping in NAND flash memory,” 2009 16th IEEE International Conference on Electronics, Circuits and Systems (ICECS 2009), Yasmine Hammamet, 2009, pp. 659-662.Applicant
Tennison, RD, “Memory space mapping using virtual addressing to multiple sized memory units,” IP.com, prior art database technical disclosure, Aug. 1, 1975.Applicant
Y. Hu et al., “Achieving page-mapping FTL performance at block-mapping FTL cost by hiding address translation,” 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST), Incline Village, NV, USA, May 3, 2010, pp. 1-12, doi: 10.1109/MSST.2010.5496970.Applicant
Chang et al., “An efficient FTL design for multi-chipped solid-state drives,” 2010 IEEE 16th Int'l. Conference on Embedded and Real-Time Computing Systems and Applications, 2010, pp. 237-246.Applicant

Abstract