Tailoring memory performance goals for applications

Abstract

A memory subsystem may receive a definition of a performance goal for each of a number of applications using the memory subsystem for storage. The memory subsystem may create a plurality of partitions according to the definition and assign each of the partitions to a block group. The memory subsystem is capable of operating each block group with trimming customized for the performance goal corresponding to that block group and application.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to memory subsystems, and more particularly, to tailoring memory performance targets for application programs. Background Art

[0002] The memory subsystem may include one or more memory devices that store data. The memory devices may be, for example, non-volatile memory devices and volatile memory devices. In general, the host system may utilize the memory subsystem to store data in the memory devices and retrieve data from the memory devices.

[0003] Vehicles are becoming increasingly reliant on memory subsystems to provide storage for previously mechanical, independent, or nonexistent components. Vehicles may include a computing system, which may host a memory subsystem. The computing system may run applications that provide component functionality. Vehicles may be driver-operated, unmanned (autonomous), and / or partially autonomous. Computing systems in vehicles may make extensive use of memory devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present disclosure will be more fully understood from the detailed description given below and from the accompanying drawings of various embodiments of the present disclosure.

[0005] Figure 1 An example computing system including a memory subsystem according to some embodiments of the present disclosure is described.

[0006] Figure 2 is a block diagram of a memory subsystem that provides storage for applications according to some embodiments of the present disclosure.

[0007] Figure 3 A diagram illustrating a portion of a memory array having multiple physical blocks according to some embodiments of the present disclosure.

[0008] Figure 4 is a block diagram of an example computer system in which embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0009] Aspects of the present disclosure relate to using multiple trims tailored for performance targets for block groups of a memory subsystem. For example, a vehicle may include a memory subsystem, such as a solid state drive (SSD). The memory subsystem may be used by various components of the vehicle, such as applications run by a host system of the vehicle, to store data. Examples of such applications include an instrument cluster of the vehicle, a black box of the vehicle, and an infotainment system of the vehicle. Figure 2Describes additional details of such applications. Based on the needs of the different applications, different applications may have different performance goals for data storage in the memory subsystem. Thus, it may be beneficial to operate different block groups of the memory subsystem with different trims tailored for those performance goals of the different applications.

[0010] The figures herein follow a numbering convention in which the first digit or digits correspond to the figure number and the remaining digits identify the element or component in the figure. Similar elements or components between different figures may be identified by using similar numerals. For example, 104 may refer to Figure 1 Component "04" in, and similar components can be found in Figure 2 204 in FIG. 204. Similar elements within the drawings may be referred to by a hyphen and an additional number or letter. Such similar elements may generally be referenced without the hyphen and additional number or letter. For example, Figure 1 1, 106-2, and 106-N in the drawings may be collectively referred to as 106. As used herein, the designators "N" and "P" particularly with respect to reference numbers in the drawings indicate that a number of specific features so designated may be included. As will be appreciated, the elements shown in the various embodiments herein may be added, exchanged, and / or deleted in order to provide a number of additional embodiments of the present disclosure. In addition, as will be appreciated, the proportions and relative scales of the elements provided in the drawings are intended to illustrate certain embodiments of the present disclosure and should not be construed in a limiting sense.

[0011] Figure 1 An example computing system 100 including a memory subsystem 104 is illustrated according to some embodiments of the present disclosure. The memory subsystem 104 may include media such as one or more volatile memory devices 118, one or more non-volatile memory devices 120, or a combination thereof. The volatile memory device 118 may be, but is not limited to, a random access memory (RAM) such as a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), and a resistive DRAM (RDRAM).

[0012] The memory subsystem 104 may be a storage device, a memory module, or a mixture of storage devices and memory modules. Examples of storage devices include SSDs, flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash storage (UFS) drives, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile dual in-line memory modules (NVDIMMs).

[0013] The computing system 100 may be a computing device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an airplane, drone, train, car, or other transportation vehicle), an Internet of Things (IoT) enabled device, an embedded computer (e.g., a computer included in a vehicle, industrial equipment, or a networked commercial device), or such a computing device that includes a memory and a processing device.

[0014] The computing system 100 includes a host system 102 coupled to one or more memory subsystems 104. In some embodiments, the host system 102 is coupled to memory subsystems 104 of different types. Figure 1 An example of a host system 102 coupled to a memory subsystem 104 is illustrated. As used herein, "coupled to" or "coupled with" generally refers to a connection between components, which can be an indirect communication connection or a direct communication connection (e.g., without intervening components), whether wired or wireless, including connections such as electrical, optical, magnetic, etc.

[0015] The host system 102 includes or is coupled to processing resources, memory resources, and network resources. As used herein, a "resource" is a physical or virtual component with limited availability within the computing system 100. For example, the processing resources include a processing device 110-1 (or several processing devices), the memory resources include a memory subsystem 104 for secondary storage and a main memory device (not specifically illustrated) for primary storage, and the network resources include a network interface 112. The processing device 110-1 may be one or more processor chipsets that can execute a software stack. The processing device 110-1 may include one or more cores, one or more caches, a memory controller (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller, etc.). The host system 102 uses the memory subsystem 104, for example, to write data to the memory subsystem 104 and read data from the memory subsystem 104.

[0016] Host system 102 may be configured to provide virtualized or non-virtualized access to memory subsystem 104 and / or processing resources and network resources. Virtualization may include abstraction, pooling, and automation of processing, memory, and / or network resources. Figure 1 Generally speaking, the host system 102 provides virtualized access, and Figure 4 Generally speaking, the host system provides non-virtualized access.

[0017] To provide this virtualization, the host system 102 incorporates a virtualization layer 108 (e.g., a hypervisor, a virtual machine monitor, etc.) that can execute a number of virtual computing instances (VCIs) 106-1, 106-2, ..., 106-N. The virtualization layer 108 can provide processing resources and memory resources to the VCI 106 and can facilitate the communication of the VCI 106 via a network interface 112. The virtualization layer 108 represents an execution instance of software run by the host system 102. The term "virtual computing instance" covers a range of computing functionality. The VCI may include a non-virtualized physical host, a virtual machine (VM), and / or a container. A container can run on a host operating system without a hypervisor or a separate operating system, such as a container running within Linux. The container can be provided by a virtual machine that includes a container virtualization layer (e.g., Docker). VMs generally refer to isolated end-user space instances that can be executed within a virtualized environment. Other technologies that can provide isolated application instances other than hardware virtualization may also be referred to as VCIs. The term "VCI" encompasses these examples and combinations of different types of VCIs, and so forth.

[0018] In some embodiments, VMs operate on the host system 102 with their own client operating systems, using the resources of the host virtualized by the virtualization layer 108. Tenants (i.e., owners of VMs) can choose which applications to operate on top of the client operating system. On the other hand, some containers run on top of the host operating system without the need for a hypervisor or the construction of a separate client operating system. The host operating system can use namespaces to isolate containers from each other and thus provide operating system-level separation of different application groups operating in different containers. This separation is similar to the VM separation that can be provided in a hypervisor virtualization environment of virtualized system hardware, and therefore can be viewed as a form of virtualization that isolates different application groups operating in different containers. Such containers can be more lightweight than VMs.

[0019] Thus, the VCIs 106 may represent applications running on the virtualization layer 108 or on an operating system executed by the host system 102. For example, the first VCI 106-1 is an application that provides an instrument cluster for a vehicle, the second VCI 106-2 is an application that provides a black box for a vehicle, and the third VCI 106-N is an application that provides an infotainment system for a vehicle. Embodiments are not limited to these specific examples of applications.

[0020] The host system 102 may be coupled to the memory subsystem 104 via a physical host interface. Examples of the physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a PCIe interface, a Universal Serial Bus (USB) interface, a Fibre Channel, a Serial Attached SCSI (SAS), a Small Computer System Interface (SCSI), a Double Data Rate (DDR) memory bus, a Dual In-line Memory Module (DIMM) interface (e.g., a DIMM slot interface supporting Double Data Rate (DDR)), an Open NAND Flash Interface (ONFI), Double Data Rate (DDR), Low Power Double Data Rate (LPDDR), or any other interface. The physical host interface may be used to transfer data between the host system 102 and the memory subsystem 104. When the memory subsystem 104 is coupled to the host system 102 through a PCIe interface, the host system 102 may further utilize an NVM Express (NVMe) interface to access the non-volatile memory device 120. The physical host interface may provide an interface for passing control, address, data, and other signals between the memory subsystem 104 and the host system 102. Figure 1 Memory subsystem 104 is illustrated. In general, host system 102 can access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0021] The host system 102 may send a request to the memory subsystem 104, for example, to store data in the memory subsystem 104 or to read data from the memory subsystem 104. The data to be written or read as specified by the host request is referred to as "host data". The host request may include logical address information. The logical address information may be a logical block address (LBA), which may include or be accompanied by a partition number. The logical address information is a location that the host system associates with the host data. The logical address information may be part of the metadata of the host data. The LBA may also correspond to (e.g., dynamically map to) a physical address, such as a physical block address (PBA), indicating a physical location where the host data is stored in the memory.

[0022] Examples of the nonvolatile memory device 120 include NAND-type flash memory. NAND-type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND). The nonvolatile memory device 120 may be other types of nonvolatile memory, such as read-only memory (ROM), phase change memory (PCM), self-select memory, other chalcogenide-based memory, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin transfer torque (STT)-MRAM, conductive bridge RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), NOR flash memory, electrically erasable programmable read-only memory (EEPROM), and three-dimensional cross-point memory. The cross-point array of the nonvolatile memory may be combined with a stackable cross-grid data access array to perform bit storage based on changes in bulk resistance. Additionally, in contrast to many flash-based memories, cross-point non-volatile memories can perform write-in-place operations, where non-volatile memory cells can be programmed without first erasing the non-volatile memory cells.

[0023] Each of the non-volatile memory devices 120 may include one or more arrays of memory cells. One type of memory cell, such as a single level cell (SLC), may store one bit per cell. Other types of memory cells, such as a multi-level cell (MLC), a three-level cell (TLC), a four-level cell (QLC), and a five-level cell (PLC) may store multiple bits per cell. In some embodiments, each of the non-volatile memory devices 120 may include one or more arrays of memory cells, such as SLC, MLC, TLC, QLC, or any combination thereof. In some embodiments, a particular memory device may include an SLC portion and an MLC portion, a TLC portion, a QLC portion, or a PLC portion of a memory cell. The memory cells of the non-volatile memory device 120 may be grouped into pages that may refer to a logical unit of a memory device used to store data. For some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0024] The memory subsystem controller 114 (or simply controller 114) can communicate "with the non-volatile memory device 120 to perform operations such as reading data, writing data, erasing data, and other such operations at the non-volatile memory device 120. The memory subsystem controller 114 can include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The hardware can include digital circuitry with dedicated (i.e., hard-coded) logic to perform the operations described herein. The memory subsystem controller 114 can be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or other suitable circuitry.

[0025] The memory subsystem controller 114 may include a processing device 110-2 (e.g., a processor) configured to execute instructions stored in a local memory 116. In the illustrated example, the local memory 116 of the memory subsystem controller 114 is an embedded memory configured to store instructions for executing various processes, operations, logic flows, and routines that control the operation of the memory subsystem 104, including handling communications between the memory subsystem 104 and the host system 102.

[0026] In some embodiments, local memory 116 may include memory registers that store memory pointers, fetched data, etc. For example, local memory 116 may also include ROM for storing microcode. Figure 1 The example memory subsystem 104 in has been illustrated as including a memory subsystem controller 114, but in another embodiment of the present disclosure, the memory subsystem 104 does not include a memory subsystem controller 114, but may rely on external control (e.g., provided by an external host, or by a processor or controller separate from the memory subsystem 104).

[0027] In general, the memory subsystem controller 114 may receive information or operations from the host system 102 and convert the information or operations into instructions or appropriate information to achieve the desired access to the non-volatile memory device 120 and / or the volatile memory device 118. The memory subsystem controller 114 may be responsible for other operations, such as wear leveling operations, error detection and / or correction operations, encryption operations, cache operations, and address translation between logical addresses (e.g., logical block addresses) and physical addresses (e.g., physical block addresses) associated with the non-volatile memory device 120. The memory subsystem controller 114 may further include a host interface circuit system to communicate with the host system 102 via a physical host interface. The host interface circuit system may convert queries received from the host system 102 into commands to access the non-volatile memory device 120 and / or the volatile memory device 118, and convert responses associated with the "non" volatile memory device 120 and / or the volatile memory device 118 into information for the host system 102.

[0028] In some embodiments, the non-volatile memory device 120 includes a local media controller 122 that operates in conjunction with the memory subsystem controller 114 to perform operations on one or more memory cells of the memory device 120. An external controller (e.g., the memory subsystem controller 114) can manage the non-volatile memory device 120 externally (e.g., perform media management operations on the memory device 120). In some embodiments, the memory device 120 is a managed memory device, which is a raw memory device combined with a local controller (e.g., the local controller 122) for media management within the same memory device package. An example of a managed memory device is a managed NAND device.

[0029] In at least one embodiment, the block labeled "TRIM" 124 represents a trimming circuit system 124. As used herein, the trimming circuit system 124 may include an ASIC configured to perform the examples described herein. For example, the trimming circuit system 124 may operate different groups of blocks of the non-volatile memory device 120 with different trims tailored for different performance goals. Figure 2 The block groups and additional functionality of the trimming circuitry 124 and the memory subsystem controller 114 and / or local media controller 122 are described in greater detail. In some embodiments, the local media controller 122 of the non-volatile memory device 120 includes at least a portion of the trimming circuitry 124. For example, the local media controller 122 may include a processor (e.g., a processing device) configured to execute instructions stored on the volatile memory device 118 for performing the operations described herein. In some embodiments, the trimming circuitry 124 is part of the host system 102, an application, or an operating system.

[0030] In at least one embodiment, the block labeled "TRIM" 124 represents data or instructions (eg, trim or set trim commands) stored in the memory subsystem 104. The functionality described with respect to trim circuitry 124 may be embodied in machine-readable and executable instructions stored in a tangible machine-readable medium.

[0031] Trim is a set of operating parameters (e.g., voltages) that can be used to operate memory cells. A controller, such as the memory subsystem controller 114 or the local media controller 122, can issue a set trim command that causes the nonvolatile memory device 120 to operate the memory cells of the nonvolatile memory device 120 using a particular set of operating parameters. Trim can include operating parameters associated with various operations such as programming (writing), program verification, erasing, erase verification, and sensing (reading), as well as other operations associated with an array of memory cells. Examples of trim include programming voltage, programming frequency, and programming time length.

[0032] Trimming may be used to achieve or adjust a desired threshold voltage (Vt) distribution for different data states of memory cells of the nonvolatile memory device 120 and / or a voltage variation range between different Vt distributions. Trimming may be used to cause the nonvolatile memory device 120 to operate with different programming times. Different trimming may be used for different operations, such as programming, reading, and erasing, to achieve different performance goals, such as programming speed, reading speed, data retention over time (how long a memory cell reliably stores data programmed to it), and memory cell endurance (how reliably a memory cell operates after various numbers of program / erase cycles). The effects of different trimming on different performance goals may be understood based on testing, historical observations, theoretical modeling, active monitoring of the operation of the memory device, and other methods. For example, a faster programming time may provide better programming speed, but may result in relatively poor data retention over time. A slower programming time may provide a slower programming speed, but may result in better data retention over time.

[0033] Examples of trimming include a program start voltage, a program step voltage, a program inhibit start voltage, and an erase verify voltage. The program start voltage is the magnitude of an initial program voltage pulse in a series of voltage pulses applied to a selected word line during a program operation on memory cells in a selected block. The program step voltage is the voltage step size between program voltage pulses. The program inhibit start voltage is a voltage used to inhibit further programming of a memory cell once the Vt level associated with the desired data state has been reached. The erase verify voltage is a voltage used to check whether the memory cells in a selected block have a Vt level that indicates an erased state.

[0034] Other examples of trimming include read reference voltages and / or program verify voltages. The program verify voltage represents the target voltage level to which the memory cell is to be programmed in order to represent a particular data state. The read reference voltage is a voltage level that may be between programming Vt distributions and is used to determine a particular data state of a data cell during a data read operation.

[0035] The memory subsystem 104 may also include additional circuitry or components not illustrated. In some embodiments, the memory subsystem 104 may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoders and column decoders) that may receive addresses from the memory subsystem controller 114 and decode the addresses to access the non-volatile memory device 120.

[0036] Figure 2 2 is a block diagram of a memory subsystem 204 that provides storage for applications 226 according to some embodiments of the present disclosure. The memory subsystem 204 is illustrated as communicating with a first application 226-1, a second application 226-2, and a third application 226-3. Embodiments are not limited to a particular number of applications. The applications 226 may be vehicle applications. According to the examples described herein, the first application 226-1 is an infotainment system, the second application 226-2 is an instrument cluster, and the third application 226-3 is a black box. The applications may be executed by a host system (not illustrated). In at least one embodiment, the applications 226 are similar to Figure 1 106 (eg, where each application 226 is a different VCI). Providing storage for many different integrated systems with one memory subsystem 204 can be a cost-effective solution, but it presents technical challenges for the memory subsystem 204 to handle the different performance goals of the different integrated systems and applications 226.

[0037] The infotainment system of a vehicle may also be referred to as an in-vehicle entertainment system. It is a collection of hardware and software that provides audio and / or video entertainment. A navigation system, such as a global positioning system, may be associated with the infotainment system and / or instrument cluster. The infotainment system may include or be connected to the audio system of the vehicle. The infotainment system may include a radio, a compact disc player, a storage media player, USB, Bluetooth, WiFi, hands-free voice controls, and other features. The infotainment system may have relatively large data storage requirements. For example, for items such as high-density (HD) maps of a navigation system or for updates performed over the air, the total number of bytes written (TBW) may be large. However, the TBW requirement is not as high as that of a black box (as described below). Because the infotainment system may represent different functionalities, in some embodiments, the infotainment system may have more than one performance target. For example, the first performance target of the storage of the infotainment system is good data retention and the second performance target of the storage of the infotainment system is balanced data retention and memory unit durability. The first performance target may be for a storage media player of the infotainment system. The second performance target may be for a navigation system of the infotainment system.

[0038] The instrument cluster of a vehicle may provide information related to the operation of the vehicle and its components (e.g., engine, cooling system, transmission, electrical system, suspension, fuel system, etc.). Examples of functionality provided by the instrument cluster include a speedometer, tachometer, fuel gauge, battery gauge, tire pressure monitoring, oil temperature, exhaust temperature, battery temperature, etc. Some of this functionality may have been previously provided by mechanical components or independent electrical components. However, more modern vehicles may have a digital instrument cluster provided as an application run by a computing system, which aggregates data from various vehicle systems and presents it to the user. The instrument cluster may have a relatively small storage size requirement. Typically, a relatively small amount of data is written to the storage device of the instrument cluster, however, the data is frequently accessed. Therefore, the performance goal of the storage of the instrument cluster is good data retention across the wide temperature range to which the vehicle may be exposed.

[0039] The black box of a vehicle may also be referred to as an accident data recorder. The emergence of autonomous vehicles, the Internet of Things (IoT), and monitoring devices has led to a greater gap between the TBW of the usable life of a memory subsystem and the user capacity of the memory subsystem. For example, with the emergence of autonomous vehicles, some autonomous driving requires real-time buffering of telemetry data, such as cameras, RADAR, LIDAR, ultrasound, and other sensors necessary for replaying the sequence before the accident. For the sequential write throughput from the host system, the data from various sensors generates a considerable amount of data per unit time. When an event occurs, it is necessary to capture the playback time of thirty (30) seconds just before the event to determine the cause of the event. Replay may be referred to as a "snapshot". The storage device of this information is referred to as a black box in this article. A black box is such an application, in which the user capacity requirement may be as low as one hundred and twenty-eight (128) GB, but the TBW requirement may be as high as hundreds of Peta bytes. The example of the given value is not restrictive, but emphasizes the relative difference between the capacity requirement and the TBW. The black box may need to store at least a few of the most recent snapshots. The storage performance target of the black box is significant write performance at large TBW, where memory cell endurance is important since the memory cells will be subjected to many program / erase cycles.

[0040] For each application 226 using the memory subsystem 204 for storage, the memory subsystem 204 may receive (e.g., from a host system) a respective definition of performance objectives. The memory subsystem 204 may receive a respective number of definitions of performance objectives for each application 226. Examples of performance objectives include data retention, memory cell endurance, and balanced data retention and memory cell endurance. The memory subsystem 204 (e.g., through its controller) may create a plurality of partitions 228 in accordance with the definitions. A partition 228 may be created for each application 226 and additional partitions may be created for applications 226 having more than one performance objective. A partition 228 may be created for each performance objective defined for a given application 226. If one performance objective is defined for one application 226, then one partition 228 may be created for that application 226. Figure 2 As illustrated in FIG. 1 , the second application 226-2 and the third application 226-3 each have one respective partition 228-3, 228-4 created for them, indicating that only one performance target is defined for each application. If more than one (e.g., two) performance targets are defined for one application 226, more than one (e.g., two) partitions 228 may be created for that application 226. Figure 2, the first application 226-1 has two partitions 228-1, 228-2 created for it, indicating that two performance targets are defined for the first application. The memory subsystem 204 may associate each partition 228 with a respective performance target.

[0041] The memory subsystem 204 may logically organize memory devices (e.g., Figure 1 The physical blocks (e.g., blocks 232) of the non-volatile memory device 120 described in the embodiment of the present invention are divided into a number of block groups 230 equal to the number of unique performance targets of the plurality of applications 226 stored using the system. The number of unique performance targets is the total number of received performance targets that are not duplicates of previously received performance targets. For example, regarding Figure 2 , the first application 226-1 is an infotainment system with two performance goals: (1) data retention and (2) balanced data retention and memory cell endurance; the second application 226-2 is an instrument cluster with one performance goal: data retention; and the third application 226-3 is a black box with one performance goal: memory cell endurance. Because the first performance goal of the first application 226-1 is the same as the performance goal of the second application 226-2, this counts as only one unique performance goal, while the second performance goal of the first application 226-1 and the performance goal of the third application 226-3 are each unique. In summary, there are three unique performance goals in this example, so the physical blocks of the memory device are divided into a first block group 230-1, a second block group 230-2, and a third block group 230-3.

[0042] The memory subsystem 204 may assign each of the partitions 228 to a respective block group 230 and operate each of the block groups 230 with different trims tailored to the respective unique performance goals corresponding to the block groups 230. In response to more than one of the partitions 228 (e.g., partitions 228-1, 228-3) having the same performance goal, more than one of the partitions may be assigned to one of the block groups 230. Figure 2, a first partition 228-1 and a third partition 228-3 (having a performance goal of data retention) are assigned to a first block group 230-1; a second partition 228-2 (having a performance goal of balanced data retention and memory cell endurance) is assigned to a second block group 230-2; and a fourth partition 228-4 (having a performance goal of memory cell endurance) is assigned to a third block group 230-3. The first block group 230-1 may operate with a first trim ("trim set 1"), the second block group 230-2 may operate with a second trim ("trim set 2"), and the third block group 230-3 may operate with a third trim ("trim set 3"). In the examples described herein, the first trim may be customized for data retention; the second trim may be customized for balanced data retention and memory cell endurance; and the third trim may be customized for memory cell endurance.

[0043] The memory subsystem 204 may operate a particular block group 230 by issuing a set trim command to cause the memory device to use trimming for commands directed to the particular block group 230. The set trim command may be issued in response to receiving a request from the host system directed to a different one of the block groups 230 than a previously satisfied request. Each of the block groups 230 may be operated as a separate logical unit with a respective trim. In such embodiments, when the memory subsystem 204 divides the blocks into block groups, the division will follow logical unit boundaries. Figure 3 The logical unit is described in more detail. In some embodiments, each of the block groups 230 can be operated as part of a logical unit. In such embodiments, a set trim command can be issued to the logical unit to operate the second block group 230-2 with a second trim after operating the first block group 230-1 with a first trim. In such embodiments, a set trim command can be sent when changing operation from one block group 230 to another block group.

[0044] In some embodiments, the host system running the application 226 may provide a definition of the size of each of the partitions 228 to the memory subsystem 204 (in addition to providing a definition of the performance target for each application 226). By providing this definition, the host system does not have to specify what partitions to create. Instead, the host can specify each application 226, and more specifically, how much storage is required for each performance target of each application 226. The memory subsystem can use this information to create partitions 228 with sufficient backing storage in the block group 230. For example, the partition 228 may be associated with an LBA range corresponding to sufficient physical storage for it. The memory subsystem 204 can provide the LBA range of each partition 228 and provide an additional logical address (e.g., a partition identifier) ​​to the host system for each partition 228 created. Subsequently, the host system can address the request to the memory subsystem with a corresponding partition identifier corresponding to the corresponding performance target of each of the applications 226, and the memory subsystem 204 can receive a memory access request from the host system using the corresponding logical address (partition identifier) ​​and LBA. The memory subsystem 204 may store the correspondence between each partition 228 and the block group 230 in an address table. The address table may also specify the logical addresses (partition identifiers) of the partitions and their corresponding LBA ranges.

[0045] The memory subsystem 204 may be configured to perform wear leveling on each of the block groups 230 individually. Wear leveling is used to control the rate of wear on memory blocks. Wear leveling may increase the life of non-volatile memory devices that may experience failure after a number of program / erase cycles. Wear leveling may include dynamic wear leveling to minimize the amount of valid blocks that are moved to reclaim blocks. Dynamic wear leveling may include a technique known as garbage collection, in which blocks are reclaimed by erasing blocks that have a number of invalid pages (i.e., pages that have data that has been rewritten to different pages and / or that is no longer needed on the invalid pages). Static wear leveling includes writing static data to blocks with high erase counts to extend the life of the blocks. About Figure 3 The relationship between pages and blocks is described in more detail. According to at least one embodiment of the present disclosure, it is advantageous to perform wear leveling on each of the block groups 230 individually because they are operated at different trims. Blocks in different block groups 230 are used to achieve different performance goals, which may be adversely affected by wear leveling across block groups 230. For example, blocks intended for memory cell endurance (fewer program / erase cycles) will typically be erased and used to store new data according to most wear leveling algorithms to balance program / erase cycle counts across all blocks in the memory subsystem 204.

[0046] Figure 3Schematic diagram illustrating a portion of a memory array 340 having multiple physical blocks according to some embodiments of the present disclosure. The memory array 340 may be Figure 1 Components of the non-volatile memory device 120 described in . The memory array 340 includes a number of logical units, such as "logical unit 0" 334-1 and "logical unit 1" 334-2. Each logical unit 334 is divided into two planes "Plane Address 0" and "Plane Address 1". The embodiments are not limited to any particular number of planes per logical unit 334. Each logical unit 334 includes a number of blocks. Each block may include a number of pages of memory cells, such as "Page 0" 336-1, "Page 1" 336-2, ..., "Page P" 336-P illustrated in "Block B+1" 332 of "Logical Unit 1" 334-2. Each logical unit 334 may be on its own memory die or multiple logical units 334 may be on the same memory die.

[0047] Each plane is in bidirectional communication with a page register (e.g., memory page register, strobe register, etc.), such as page register 338 of "Plane Address 1" of "Logical Unit 1" 334-2. Page register 338 can store an amount of data equal to the page size of the memory device. Data can be transferred from the page register to the memory plane during a write operation. Data can also be transferred from the memory plane to the page register during a read operation. Data can be transferred from the page register to a bus (not specifically illustrated) and / or from the bus to the page register.

[0048] Each memory cell page may include a number of memory cells (e.g., nonvolatile memory cells). As used herein, a memory cell page refers to a number of memory cells that can store a one-time programmable amount of data. As an example, a one-time programmable amount of data may be referred to as a data page, and a memory cell storing page data may be referred to as a memory cell page. In one or more embodiments, a memory cell page may include memory cells coupled to a specific access line (e.g., a word line). In one or more embodiments, a memory cell coupled to a specific word line may be divided into more than one data page. In one or more embodiments, a memory cell page may include memory cells coupled to more than one word line. For embodiments including multi-level cells, a number of memory cells that can be programmed at one time may store multiple data pages (e.g., an upper data page and a lower data page, wherein each memory cell stores one or more bits toward the upper data page and one or more bits toward the lower data page). As used herein, a block of memory cells refers to a number of memory cells that can store a one-time erasable amount of data. For example, a one-time erasable amount of data may be referred to as a data block, and a memory cell storing a data block may be referred to as a memory cell block.

[0049] Each logic unit 334 can operate differently. A controller, such as Figure 1 34-1, and the like. The memory subsystem controller 114 or the local media controller 122 illustrated in FIG. 34-1 may issue a set trim command 342 that causes a logical unit 334 to operate the memory cells of the logical unit 334 using a particular trim (set of operating parameters). For example, a first set trim command 342-1 may be issued to a first logical unit 334-1 and a second set trim command 342-2 may be issued to a second logical unit 334-2. In general, once a set trim command 342 has been issued to a logical unit 334, the logical unit will operate according to the set trim command 342 until a different set trim command 342 is issued. According to at least one embodiment of the present disclosure, the trim associated with the set trim command 342 is customized to the performance goals of an application whose data is stored in a block group. If the block group for a particular application is part of one logical unit, such as "logical unit 0" 334-1, and other block groups are not part of that logical unit 334-1, then only one set trim command 342-1 needs to be used to cause that block group to operate with the desired trim. However, if that logical unit 334-1 includes blocks that are part of different groups of blocks associated with different applications with different performance goals, then a set trim command 342 may be issued to operate the second group of blocks with a second trim after operating the first group of blocks with a first trim. The same is true for embodiments in which the entire memory is operated as a single logical unit 334 (issuing a set trim command 342 to cause the logical unit 334 to use trim for operations directed to a particular group of blocks with a different performance goal than the previous operation). The controller is configured to issue a set trim command 342 in response to receiving a request from the host system directed to a different one of the groups of blocks than the previously satisfied request.

[0050] Figure 4 4 is a block diagram of an example computing system 400 in which embodiments of the present disclosure may operate. Within the computing system 400, a set of instructions for causing the machine to perform one or more methodologies discussed herein may be executed. The computing system 400 includes a processing device 410, a main memory 446, a static memory 452 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 404 that communicate with each other via a bus 450. The data storage system 404 is similar to Figure 1 The memory subsystem 104 described in .

[0051] The processing device 410 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets or a processor that implements a combination of instruction sets. The processing device 410 may also be one or more special-purpose processing devices, such as an ASIC, an FPGA, a digital signal processor (DSP), a network processor, etc. The processing device 410 is configured to execute instructions 444 for performing the operations and steps discussed herein. The computing system 400 may further include a network interface device 412 for communicating over a network 448.

[0052] The data storage system 404 may include a machine-readable storage medium 452 (also referred to as a computer-readable medium) having stored thereon one or more sets of instructions 444 or software embodying one or more methodologies or functions described herein. The instructions 444 may also reside, completely or at least partially, within the main memory 446 and / or the processing device 410 during execution by the computing system 400, the main memory 446 and the processing device 410 also constituting machine-readable storage media.

[0053] In one embodiment, the instructions 444 include instructions for implementing the Figure 1 The instructions may include trimming 424 for groups of operating blocks that are customized for performance targets. Although the machine-readable storage medium 452 is shown as a single medium in the example embodiment, the term "machine-readable storage medium" should be understood to include a single medium or multiple media that store one or more sets of instructions. The term "machine-readable storage medium" should also be understood to include a medium that is capable of storing or encoding a set of instructions for execution by a machine and causing the machine to perform one or more methodologies of the present disclosure. Therefore, the term "machine-readable storage medium" should be understood to include, but not be limited to, solid-state memory, optical media, and magnetic media.

[0054] Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the art of data processing to most effectively convey the substance of their work to others skilled in the art. An algorithm is here and generally considered to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulation of physical quantities. Typically, although not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. Mainly for common reasons, it sometimes proves convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0055] It should be remembered, however, that all of these and similar terms should be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may involve the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage systems.

[0056] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the intended purpose, or it may comprise a general-purpose computer that is selectively activated or reconfigured by a computer program stored in the computer. This computer program may be stored in a machine-readable storage medium, such as, but not limited to, several types of disks, semiconductor-based memories, magnetic or optical cards, or other types of media suitable for storing electronic instructions.

[0057] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, which can be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes a mechanism for storing information in a form readable by a machine (e.g., a computer).

[0058] In the foregoing description, embodiments of the present disclosure have been described with reference to specific example embodiments thereof. It will be apparent that various modifications may be made to the present invention without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the appended claims. Accordingly, the description and drawings should be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method comprising: receiving a respective definition of performance objectives for each of a plurality of applications (226-1, 226-2, 226-3); Creating a plurality of partitions (228-1, 228-2, 228-3, 228-4) according to the corresponding definitions; assigning each of the plurality of partitions to a respective one of a plurality of block groups (230-1, 230-2, 230-3); as well as Each of the plurality of block groups is operated with respective trimming (124, 424) tailored for respective performance targets.

2. The method of claim 1 , wherein operating each of the plurality of groups of blocks with a respective trim tailored for the respective performance target comprises: operating a first block group to maintain a first trim customized for the data; operating a second group of blocks with a second trim customized for memory cell endurance; and The third group of blocks is operated with a third trim tailored for a balance between data retention and memory cell endurance. 3 . The method of claim 1 , wherein receiving the respective definition comprises receiving definitions of more than one performance objective for one of the plurality of applications.

4. The method of claim 1, wherein assigning each of the plurality of partitions (228-1, 228-3) comprises assigning the more than one of the plurality of partitions to one of the plurality of block groups (230-1) in response to the more than one of the plurality of partitions having the same performance goal.

5. The method of any one of claims 1 to 4, further comprising wear leveling each of the plurality of block groups individually.

6. The method of any one of claims 1 to 4, further comprising operating each of the plurality of block groups as a separate logical unit (334-1, 334-2) with the respective trim.

7. The method of any one of claims 1 to 4, further comprising operating each of the plurality of block groups as part of a logical unit; and After operating the first block group with the first trimming, a set trimming command (342-2) is issued to operate the second block group with the second trimming.

8. The method of any one of claims 1 to 4, further comprising providing a respective logical address of each of the plurality of partitions to a host of the plurality of applications (102); and A memory access request is received from the host using the respective logical address and logical block address.

9. A system comprising: Controller (114, 122); as well as a memory device (120) coupled to the controller; The controller is configured to: logically partitioning physical blocks (232, 332) of the memory device into a number of block groups (230-1, 230-2, 230-3) equal to the number of unique performance goals of a plurality of application programs (226-1, 226-2, 226-3) using the system for storage; as well as Each of the block groups is operated with a different trim (124, 424) tailored for a respective one of the unique performance goals.

10. The system of claim 9, wherein the controller is configured to operate one of the groups of blocks by issuing a set trim command (342-1, 342-2) to cause the memory device to use the trim for commands directed to the one of the groups of blocks.

11. The system of claim 10, wherein the controller is configured to issue the set trim command in response to receiving a request from a host (102) directed to a different one of the block groups than a previously satisfied request.

12. The system of claim 9, wherein each of the plurality of applications is a different transportation application.

13. The system of claim 12, wherein each of the different transportation applications comprises a different virtual computing instance (106-1, 106-2, 106-N).

14. The system of claim 12, wherein the different vehicle applications include infotainment, instrument cluster, and black box; and The unique performance targets include data retention, memory cell endurance, and balanced data retention and memory cell endurance.

15. The system of any one of claims 9 to 14, wherein the controller is further configured to: creating a respective partition for each of the plurality of applications (228-1, 228-3, 228-4); and A respective additional partition is created for each of the plurality of applications having more than one performance goal (228-2).

16. The system of claim 15, wherein the controller is configured to receive from a host a definition of: The unique performance goals described; the number of performance objectives for each of the plurality of applications; and The corresponding size of each partition.

17. The system of claim 15, wherein the controller is further configured to: Associating each partition with a corresponding performance objective; and Each partition is assigned to a respective one of the block groups based on the respective performance goals associated with each partition.

18. The system of claim 17, wherein the controller being configured to assign each partition to a corresponding one of the block groups comprises the controller being configured to store a correspondence between each partition and the corresponding one of the block groups in an address table.

19. The system of any one of claims 9 to 14, wherein the controller is configured to perform wear leveling within each of the groups of blocks individually.

20. A system comprising: Processing device (110-1, 410); a memory subsystem (104, 404) coupled to the processing device; as well as A memory device (446) coupled to the processing device and storing instructions (444) that, when executed by the processing device: Running a plurality of transportation applications (226-1, 226-2, 226-3); defining a respective performance goal for each of the plurality of transportation applications; as well as A request is addressed to the memory subsystem with a respective partition identifier corresponding to the respective performance goal of each of the plurality of transportation applications.

21. The system of claim 20, wherein the plurality of vehicle applications include an instrument cluster, an infotainment system, and a black box.

22. The system of claim 20, further comprising instructions for defining a respective partition size for each of the plurality of transportation applications.

Images