TWI814975B - Method and apparatus for storage media programming with adaptive write buffer release, and the system-on-chip thereof - Google Patents

Abstract

The present disclosure describes apparatuses and methods for storage media programming with adaptive write buffer release. In some aspects, a media write manager of a storage media system stores, to a write buffer, data received from a host interface. The media write manager determines parity information for the data stored to the write buffer and then releases the write buffer on completion of determining the parity information for the data. The media write manager may then write at least a portion of the data to storage media after the write buffer is released. By releasing the write buffer of the storage media system after determining the parity information, the write buffer is freed more quickly, which may result in improved write buffer utilization and increased write throughput of the storage media system.

Description

Storage media programming method and device for utilizing self-adjusting write buffer release device, and its system single chip [Cross-reference to related applications]

This disclosure claims priority to U.S. Provisional Patent Application No. 62/791,542, filed on January 11, 2019, and U.S. Patent Application No. 16/737,137, filed on January 8, 2020, which The entire contents are incorporated herein by reference.

Many computing and electronic devices include non-volatile memory for storing software, applications or device data. Additionally, most users utilize their devices (such as multimedia content or social media applications) to stream data or access services over data networks from various locations or on the move. As user demand for data and services continues to grow, storage providers have expanded the capacity and performance of storage drives to support the data access associated with these activities by users and other data storage clients. Typically, a device's storage drive includes the storage medium to which device data is written. To do this, the device issues write commands to the storage drive, which in turn writes the data to the storage medium as specified by each command. Therefore, storage drive write performance typically depends on the rate at which the storage drive is able to complete data write commands from the device or storage client.

Storage drives typically include a write buffer for receiving data from the device corresponding to write commands. The storage drive then sends the data from the write buffer to the storage medium's programming interface. However, storage media is typically much slower to program or write than the write buffer. Additionally, most storage drives retain a copy of the data in a write buffer until the data is successfully programmed onto the storage medium to enable recovery of the data if the storage medium programming fails and the data is lost. In this way, the storage drive's write buffer may be reserved or occupied for a long time due to the slower programming speed of the storage medium. This prevents the write buffer from receiving subsequent data until programming of the storage medium is complete, which can reduce the write throughput of the storage drive or require an increased number of write buffers to maintain write throughput.

This Summary is provided to introduce the subject matter that is further described in the Detailed Description and the Figures. Accordingly, this Summary should not be considered as describing essential features, nor should it be used to limit the scope of the claimed subject matter.

In some aspects, a media write manager of a storage media system implements a method of storing data received from a host interface of the storage system including the storage media into a write buffer. The method determines parity information for data stored into a write buffer via a parity-based encoder. Alternatively or additionally, the data may be transferred to another internal buffer of the storage media system. Then, in response to the determination of parity information for the data being completed, the write buffer is released. The method also includes writing at least a portion of the data to a storage medium of the storage system after the write buffer is released from storing the data.

In other aspects, an apparatus includes: a host interface configured to communicate with a host system; a write buffer operably coupled to the host interface; a storage medium; and a media interface configured to allow access to the storage medium . The device also includes parity-based encoder and media write management The media write manager is configured to receive data from the host interface via one of the write buffers. The media write manager calculates parity information for the data received by the write buffer via the parity-based encoder and stores the parity information to the parity-based encoder's buffer. In response to the calculation of parity information for the data, the media write manager releases the write buffer, and after the write buffer is released from storing the data, at least a portion of the data is written to the storage medium of the device.

In other aspects, a system on chip (SoC) is described that includes a host interface in communication with a host system, a write buffer operatively coupled with the host interface, a media interface to access a storage medium of the storage system, and Parity-based encoder. The SoC also includes a hardware-based processor and memory storing processor-executable instructions that implement a media write manager in response to execution by the hardware-based processor to store data received from the host interface to the write buffer. The media write manager also determines parity information for data stored to the write buffer via the parity-based encoder, and releases the write buffer in response to the determination of parity information for the data. Then, after the write buffer is released from storing the data, the media write manager writes at least a portion of the data to the storage medium.

The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

100:Operating environment

102:Host system

104:Laptop

106:Desktop computer

108:Server

110: Processor

112: Computer readable media

114:Storage system

116: NVMe solid state drive

118: PCIe solid state drive

120:Solid state drive

122:Memory array

124:Storage media

126: Storage media controller (storage controller)

128:Data

130:Storage Media Write Manager (Media Write Manager)

132:Write buffer

132-0~132-2n: write buffer

134:RAID encoder

136:I/O port

138: Graphics processing unit

140:Data interface

202:Solid State Storage Drive

204-0~204-n: Flash memory device

206:Host interface

208:Media interface

210: Processor core

212:Structure

214: Static random access memory

216:DRAM controller

218: Dynamic Random Access Memory (DRAM)

220: Error correction code encoder

302: Firmware

304:Hardware

306: RAID buffer

308: Host interface driver

310: Host command processor

312:Media interface drive

314:Media Command Manager

316: Host input/output command (host I/O)

318:Data

318-0~318-3, 318-2n: data

320: Flash Memory Translation Layer

322:Media input/output command (Media I/O)

324:Data

402:XOR engine

404-0~404-1: Plane

406-0~406-1: Plane

502:XOR engine

504-0~504-1: Plane

506-0~506-1: Plane

600:Method

602~612: Steps

700:Method

702~716: Steps

800:Method

802~814: Steps

900: System on chip (SoC)

902: Input-output (I/O) control logic

904: Hardware-based processor

906:Memory

908: Firmware

1000: Storage system controller

1002: Input/output (I/O) control logic

1004: Processor

1006:Host interface

1008:Storage media interface

1010: Flash Memory Translation Layer

Details of one or more implementations of storage media programming utilizing self-adjusting write buffer release are set forth in the accompanying drawings and the detailed description below. In the drawings, the leftmost digit of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different instances in the description and drawings indicates similar elements: 1 illustrates an example operating environment having a device in which a media write manager is implemented in accordance with one or more aspects of the present disclosure.

2 illustrates an example configuration of a solid state drive in which the media write manager, write buffer, and RAID encoder of FIG. 1 are implemented in accordance with various aspects.

Figure 3 illustrates an example configuration of various hardware and firmware elements for implementing aspects of storage media programming utilizing self-adjusting write buffer release.

4A-4E illustrate examples of storage media programming utilizing self-adjusting write buffer release in the context of wafer-level data redundancy.

5A-5D illustrate examples of storage media programming utilizing self-adjusting write buffer release with plane-level data redundancy.

6 depicts an example method of storage media programming utilizing self-adjusting write buffer release in accordance with one or more aspects.

Figure 7 depicts an example method for freeing a write buffer based on calculation of parity information.

Figure 8 depicts an example method for recovering from programming failures using parity-based data reconstruction.

9 illustrates an example system-on-chip (SoC) environment in which aspects of storage media programming utilizing self-adjusting write buffer release may be implemented.

Figure 10 illustrates an example storage system controller in which a media write manager is implemented in accordance with one or more aspects of the present disclosure.

Traditional techniques for writing data to storage media typically hold data in a write buffer until the data is programmed onto the storage media, resulting in reduced write throughput of the storage drive or increased write buffer requirements ( For example, the number or size of write buffers). Typically, storage drives The driver firmware is used to manage the data path of the storage drive in an end-to-end manner, such as by translating data commands and managing the movement of data along the data path between the host interface and the storage media interface. For example, the firmware may process a write command to receive corresponding data at the host interface and send the data to the storage media interface for programming to the appropriate area of the storage media.

Many storage drives operate in a "cache-on" mode, in which the firmware sends an acknowledgment of the write command to the host once the data for the write command is received by the storage drive's controller. Generally, cache-on mode is preferred because write command latencies are shorter in cache-on mode and the host does not need to retain data as quickly. In cache-on mode, the firmware typically holds data in the controller's write buffer until an acknowledgment is received from the storage medium indicating that the program operation to transfer the data to the storage medium was successful. This is necessary because in the event of a program failure (e.g., wrong word line or wrong block), the firmware still has the data and may attempt to reprogram the data into the storage medium.

However, programming the storage medium takes a relatively long time (three milliseconds) compared to the typical transfer time of data through the write buffer, which is on the order of tens of microseconds. In other words, data received from the host occupies the write buffer for an extended period of time, primarily due to the sporadic nature of programming failures, which are rare events. Additionally, the number of write buffers implemented by a controller is often limited due to practical issues such as layout area, data path architecture, power consumption, cost, etc. When the controller's limited write buffer is continually occupied by data awaiting programming acknowledgments, the controller will not be able to receive additional data from the host until the write buffer becomes available. As such, the limited number and inefficient utilization of write buffers imposes an upper limit on write throughput and can negatively impact the storage drive's write performance.

The present disclosure describes apparatus and techniques for storage media programming utilizing self-adjusting write buffer release. In contrast to conventional techniques for writing to storage media, the described apparatus and techniques may enable data writing schemes for storage media that include parity-based encoding (eg, RAID) to program failures in the storage media Data recovery is possible. By doing this, once the same Bit information is calculated for the data to be written to the storage medium, and the storage controller's media write manager can free the write buffer. Alternatively or additionally, the data may be passed to another internal buffer of the storage media system before or while calculating the parity information. In other words, the write buffer is released when the RAID computation of parity information (e.g., millisecond). Alternatively or additionally, the release of the write buffer may also be conditional on data being copied from the write buffer to another internal buffer of the storage system or to a storage medium interface for programming to the storage medium. Once freed, the write buffer can receive subsequent data from the host in some cases while previously held data is being programmed to the storage medium. In this way, self-adjusting release of the write buffer may result in more efficient write buffer utilization and/or enable the storage driver to utilize less or smaller write buffers. This reduction in write buffer or write buffer size may in turn reduce memory controller power consumption, facilitate improved integrated circuit layout, and the like.

In aspects of storage media programming that utilize self-adjusting write buffer release, the storage media system's media write manager stores data received from the host interface into the write buffer. While data is being stored in the write buffer, the media write manager determines parity information for the data and then releases the write buffer when determining parity information for the data is complete. Then, after the write buffer is freed, the media write manager can write at least a portion of the data to the storage medium. By freeing the storage media system's write buffer after determining parity information, the write buffer can be freed faster, which can result in improved write buffer utilization and increased write throughput of the storage media system.

The following discussion describes the operating environment, the technologies that may be employed in the operating environment, and the system-on-a-chip (SoC) in which components of the operating environment may be embodied. In the context of this disclosure, reference is made to the operating environment by way of example only.

operating environment

FIG. 1 illustrates an example operating environment 100 having a host system 102 capable of storing or accessing various forms of data or information. Examples of host systems 102 may include a laptop 104, a desktop 106, and a server 108, any of which may be configured as a user device, a computing device, or as part of a storage network or cloud storage. Other examples (not shown) of host system 102 may include tablet computers, set-top boxes, data storage devices, wearable smart devices, televisions, content streaming devices, high-definition multimedia interface (HDMI) media sticks, smart appliances, home automation controls controllers, smart thermostats, Internet of Things (IoT) devices, Mobile Internet Devices (MIDs), Network Attached Storage (NAS) drives, converged storage systems, game consoles, automotive entertainment devices, automotive computing systems, automotive control modules (e.g. Engine or power transmission control module), etc. Generally, host system 102 may communicate or store data for any suitable purpose, such as to enable functionality of a particular type of device, provide a user interface, enable network access, implement gaming applications, replay media, provide navigation, edit content , provide data storage, etc.

Host system 102 includes processor 110 and computer-readable media 112 . Processor 110 may be implemented as any suitable type or number of single-core or multi-core processors for executing instructions or commands of an operating system or other applications of host system 102 . Computer readable medium 112 (CRM 112) includes memory (not shown) and storage system 114 of host system 102. The memory of host system 102 may include any suitable type of volatile memory or non-volatile memory, or combinations thereof. For example, the volatile memory of the host system 102 may include various types of random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), etc. Non-volatile memory may include read-only memory (ROM), electrically erasable programmable ROM (EEPROM), or flash memory (eg, NAND flash memory). These memories, individually or in combination, may store data associated with users, applications, and/or the operating system of host system 102 .

Storage system 114 of host system 102 may be configured as any suitable type of data storage system, such as storage devices, storage drives, storage arrays, storage volumes, and the like. Although described with reference to host system 102, storage system 114 may also be implemented separately as a stand-alone device or larger Part of a storage complex, such as a network-attached storage device, an external storage drive, a data center, a server farm, or a virtual storage system (eg, for cloud-based storage or services). Examples of storage systems 114 include Non-Volatile Memory Express (NVMe) solid-state drives 116, Peripheral Component Connect Express (PCIe) solid-state drives 118, solid-state drives 120 (SSDs 120), and memory arrays 122, which may utilize storage devices or Any combination of storage drives can be implemented.

Storage system 114 includes storage media 124 and storage media controller 126 (storage controller 126 ) for managing various operations or functions of storage system 114 . Storage medium 124 may include or be formed from a non-volatile storage device on which data 128 or information of host system 102 is stored. Storage medium 124 may be implemented utilizing any type of solid-state storage medium, such as flash memory, NAND flash memory, RAM, DRAM (eg, for cache), SRAM, etc., or a combination thereof. In some cases, data 128 stored to storage media 124 is organized into data (eg, content) files or data objects that are stored to storage system 114 and accessed by host system 102 . The file type, size or format of data 128 may vary depending on the corresponding source, purpose or application associated with the file. For example, the data 128 stored in the storage system 114 may include audio files, video files, text files, image files, multimedia files, spreadsheets, etc. Although described with reference to solid-state memory, aspects of storage media programming utilizing self-adjusting write buffer releases may also be implemented into magnetic-based or optical-based media types.

Generally, storage controller 126 manages the operation of storage system 114 and enables host system 102 to access storage media 124 for data storage. Storage controller 126 may be implemented through any suitable combination of hardware, firmware, or software to provide the various functions of storage system 114 . Storage controller 126 may also manage or implement internal tasks or operations associated with storage media 124, such as data caching, data migration, garbage collection, thermal management (eg, throttling), power management, and the like. In this manner, storage controller 126 may receive host I/O from host system 102 for data access and queue (or generate) internal I/O associated with internal operations of storage medium 124 .

In this example, storage controller 126 also includes storage media write manager 130 (Media Write Manager 130), write buffer 132, and a parity-based encoder, shown as a tolerant array of independent disks (RAID) encoder 134. Write buffer 132 may receive or store data received from host system 102 for writing to storage medium 124 . RAID encoder 134 may calculate parity information (eg, XOR bits) for data written to storage media 124 as part of a RAID stripe. The members or units of a RAID stripe may include any suitable partition or region of storage media, such as dies, planes, blocks, pages, wordlines, etc. Typically, the parity information provided by the RAID encoder can be used to combine with information from other RAID stripe members to restore the RAID stripe member's data if that member's programming operation fails. RAID or parity-based data recovery can provide enhanced data reliability and protection from complete block or page faults of the storage media.

In various aspects, media write manager 130 may interact with RAID encoder 134 to calculate parity information for data stored to write buffer 132 . In some cases, data may also be passed to another internal buffer of the storage media system before or during computation of parity information. If a programming operation to write data to the storage medium fails, the media write manager 130 can use this parity information to achieve data recovery rather than relying on data held in the write buffer. Because parity information enables data recovery, the media write manager can then release the write buffer in response to computation of parity information (and/or data being transferred to another internal buffer or storage medium), thereby freeing the write buffer. 132 is free for reuse before or while data is programmed into the storage medium. By doing so, self-adjusting release of write buffers can result in improved write buffer utilization and increased storage medium write throughput.

Host system 102 may also include I/O port 136, graphics processing unit 138 (GPU 138), and data interface 140. Generally, I/O ports 136 allow host system 102 to interact with other devices, peripherals, or users. For example, the I/O port 136 may include or be coupled to a universal serial bus, human-machine peripherals, audio input, audio output, etc. GPU 138 processes and renders graphics-related data for use by the host system. System 102, such as user interface elements, applications, etc. of the operating system. In some cases, GPU 138 accesses a portion of the native memory for drawing graphics, or includes dedicated memory for drawing graphics for host system 102 (eg, video RAM).

Data interface 140 of host system 102 provides connectivity to one or more networks and other devices connected to those networks. Data interface 140 may include a wired interface (such as an Ethernet or fiber optic interface) for communication over a local area network, an intranet, or the Internet. Alternatively or additionally, data interface 140 may include facilities to facilitate communication over wireless networks, such as wireless local area networks (LANs), wide area wireless networks (eg, cellular networks), and/or wireless personal area networks (WPANs). wireless interface. In accordance with one or more aspects of storage media programming utilizing self-adjusting write buffer release, any data transferred via I/O port 136 or data interface 140 may be written to or read from storage system 114 of host system 102 .

FIG. 2 illustrates at 200 an example configuration of solid state drive 202 in which a media write manager, write buffer, and RAID encoder may be implemented in accordance with one or more aspects. In this example, media write manager 130 and other components are shown in the context of storage system 114 implemented as solid-state storage drive (SSD) 202 . SSD 202 may be coupled to any suitable host system 102 and embedded with storage medium 124 including a plurality of NAND flash memory devices 204-0 through 204-n, where n is any suitable integer. In some cases, NAND flash memory device 204 includes multiple flash memory channels that store devices, dies, or dies that can be accessed or managed at the channel level (device group) or device level (individual device). Although shown as an element of storage controller 126, media write manager 130 may be implemented separately from or external to the storage controller. In some cases, media write manager 130 is implemented as part of a memory interface (such as a DRAM controller) or an interface associated with a storage controller.

Generally, operation of SSD 202 is enabled or managed by an instance of storage controller 126 , which in this example includes a host interface 206 for enabling communication with host system 102 and an interface for enabling access to storage media 124 Media interface 208. Host interface 206 may be configured to implement any Appropriate type of storage interface or protocol, such as Serial Advanced Technology Attach (SATA), Universal Serial Bus (USB), PCIe, Advanced Host Controller Interface (AHCI), NVMe, NVM-OF (NVM-OF), NVM Host Controller Interface Specification (NVMHCIS), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), Secure Digital I/O (SDIO), Fiber Channel, any combination thereof (e.g. M.2 or next generation form factor Factor (NGFF) combination interface), etc. Alternatively or additionally, media interface 208 may implement any suitable type of storage media interface, such as a flash memory interface, a flash memory bus channel interface, a NAND channel interface, a physical page addressing (PPA) interface, or the like.

In various aspects, SSD 202 or elements of storage controller 126 provide data paths between host interface 206 to host system 102 and media interface 208 to storage media 124 . In this example, storage controller 126 includes a processor core 210 for executing kernels, firmware, or drivers to implement the functions of storage controller 126 . In some cases, processor core 210 may also execute processor-executable instructions to implement media write manager 130 of storage controller 126 . Alternatively or additionally, media write manager 130 may execute from or run on hardware associated with RAID encoder 134 .

As shown in FIG. 2 , structure 212 of storage controller 126 , which may include control and data buses, is operatively coupled and supports communications between elements of storage controller 126 . For example, media write manager 130 may communicate with write buffer 132, RAID encoder 134, or processor core 210 (e.g., firmware) to exchange data, information, or control signaling (e.g., buffers) within storage controller 126 release interrupt). The static random access memory 214 of the storage controller 126 may store processor-executable instructions or code for the storage controller's firmware or drivers, which may be executed by the processor core 210 . Alternatively or additionally, the write buffer 132 of the memory controller 126 may be implemented in the SRAM 214 of the controller.

In this example, storage controller 126 includes a dynamic random access memory (DRAM) controller 216 and associated DRAM 218 for use in storage controller 126 on host system 102 , storage medium 124 , or storage controller. Various data are stored or cached in memory while moving data between other components. As shown in Figure 2, an instance of write buffer 132 is implemented in DRAM 218 and can be Controller 216 is accessed or managed. Storage controller 126 also includes an error correction code (ECC) encoder 220 that may be used to ECC encode data programmed or written to storage media 124 of SSD 202 .

FIG. 3 illustrates at 300 an example configuration of various hardware and firmware elements for implementing aspects of storage media programming utilizing self-adjusting write buffer release. In this example, the elements of storage controller 126 are shown as abstract entities that may be implemented in the storage controller's firmware 302 and/or hardware 304 . This is only one example implementation of various elements, any of which may be implemented separately from or in combination with other elements described herein. Alternatively or additionally, any of the elements described with reference to Figure 2 or Figure 3 may be implemented as an intellectual property block (IP block) or IP core configured as a logical unit, unit that provides the various descriptive characteristics of the element. and/or integrated circuits (ICs). For example, elements of storage controller 126 (eg, media write manager 130) may be implemented as IP cores or IP blocks that include a combination of hardware, firmware, or software to provide corresponding functionality or implement corresponding operations of the elements.

In this example, hardware 304 of storage controller 126 includes NAND flash memory device 204, host interface 206, media interface 208, processor 210 (not shown), and ECC encoder 220, which may be described with reference to FIG. 2 implemented as described. Hardware 304 may also include a write buffer 132 and a RAID encoder 134 operatively coupled with RAID buffer 306 . Shown separately in this example, RAID buffer 306 may be implemented as part of RAID encoder 134 and stores parity information generated or calculated by the RAID encoder. Media write manager 130 may be implemented at least partially in hardware 304 and interact with write buffer 132 or RAID encoder 134 to perform self-tuning freeing of write buffer 132 as described throughout this disclosure. Alternatively or additionally, media write manager 130 may execute on processor core 210 of storage controller 126 .

Typically, firmware 302 of storage controller 126 assists hardware 304 in managing the data path between host system 102 and storage media 124 . In other words, firmware 302 may translate commands or requests for data received from host system 102 to enable access to storage medium 124 . As shown in FIG. 3, firmware 302 includes a host interface driver 308 for implementing the host command processor 310 on the host side and a host interface driver 308 for implementing the host command processor 310 on the storage device. The media side implements the media interface driver 312 of the media command manager 314. As shown in Figure 3, host input/output commands 316 (host I/O 316) for data 318 (eg, data corresponding to a write command) are received by the host command processor 310 and sent to the storage control The I/O scheduler of the flash translation layer 320 (FTL 320) of the processor 126. The FTL 320 and/or I/O scheduler may process and schedule the host I/O 316, which may then be executed as corresponding media input/output commands 322 (media I/O 322) for use by the media command manager 314 storage media access.

FTL 320 may manage command processing (eg, host I/O 316 translation and scheduling) to facilitate the movement of host system data 318 within storage system 114 and/or through storage controller 126 , such as to storage media 124 . As shown in Figure 3, in the context of writing host data to storage media, FTL 320 handles host I/O 316 to manage or facilitate the movement of data 318 from the host interface 206 through the data path to the media interface 208, where the data 318 is programmed into the NAND flash memory device 204. To this end, FTL 320 or firmware 302 may manage various elements of hardware 304 to facilitate the movement of data 318 from one element to the next. For example, firmware 302 may cause hardware 304 to obtain or move data 318 from host interface 206 to write buffer 132, provide data 318 (eg, by passing or copying) to RAID encoder 134, and/ Or the data 318 is provided to the ECC encoder 220 for encoding. Firmware 302 may also cause hardware 304 to send data 318 or ECC-encoded data 324 to media interface 208 for writing or programming to NAND flash memory device 204 .

In various aspects, media write manager 130 may interact with write buffer 132, RAID encoder 134, firmware 302, or other elements of hardware 304 to implement aspects of storage media programming utilizing self-adjusting write buffer release. In some cases, media write manager 130 monitors RAID encoder 134 for an indication that calculation of parity information for data 318 (eg, data for a host write command) is complete. Upon completion of parity calculations and a copy of the data being stored to another internal buffer (e.g., an ECC buffer), write buffer 130 generates an interrupt to firmware 302 to cause the release of stored data 318 (e.g., a host write command data) write buffer 132. By doing this, write buffering Buffer 132 is free and can be reused for data 318 on the host's next write command. This may also enable the storage drive to utilize fewer or smaller write buffers without impacting the storage drive's write throughput.

4A-4E illustrate examples of storage media programming utilizing self-adjusting write buffer release in the context of wafer-level data redundancy. As shown at 400 in Figure 4A, storing host data to storage media generally includes processing data 318 received at write buffer 132 and moving it to NAND flash memory 204 for programming into the NAND media. NAND flash memory 204 is illustrated here as individual NAND die 1204-1 through NAND die n 204n, where n is any suitable integer. Any of the entities of Figures 4A-4E may be implemented similarly to the corresponding entities described with reference to Figures 1-3. In this example, storage controller 126 includes an instance of RAID encoder 134 to implement RAID encoding, which may provide improved data reliability to the storage controller and enable recovery of data lost during a NAND programming failure.

Typically, a RAID stripe can span storage blocks that reside on different dies or planes of storage media. In high code rate applications (low overhead), a RAID stripe may also include blocks from the same die or plane of storage media. In this example, RAID encoder 134 is implemented in a wafer-level RAID scheme (or wafer-level RAID), which can protect against failures of storage media wafers (eg, NAND wafers). In other aspects, a Reed-Solomon code encoder can be implemented in place of a RAID encoder to achieve protection against failure events in multiple RAID stripe members (e.g., planes or dies).

As shown in Figure 4A, first write buffer 0 132-0 may receive first data 318-0 from a host (such as host system 102). The first data 318-0 is then provided to the RAID encoder 134 for calculating parity information for the first data 318-0, and to the ECC encoder 220 for ECC encoding, and is programmed into the first The first plane (plane 0 406-0) of NAND die 0 204-0. Typically, the data in the first write buffer 0 132-0 may be passed in parallel to the ECC encoder and/or the storage medium and the RAID encoder for XOR generation. Thus, the first write buffer 0 132-0 is programmed into the storage medium quality, and the RAID buffer 306 accumulates XOR information until all RAID members have passed the RAID encoder 134, and then the contents of the RAID buffer 306 can be written to the media.

In this example, RAID encoder 134 includes XOR engine 402 to compute XOR bits for first data 318-0, which is stored to the first plane of RAID buffer 306 (plane 0 404-0). As noted, programming of the first data 318-0 to the NAND flash memory may take longer compared to the calculation of the RAID encoder 134 parity information (e.g., 40 to 50 microseconds) or the transfer time to the storage medium. much time (e.g. 3 to 4 milliseconds).

Continuing with FIG. 4B , in response to RAID encoder 134's calculation of the XOR bits, media write manager 130 may release first write buffer 0 132 - 0 , as shown at 408 . Before or during programming 410 of first data 318-0 to first NAND die 204-0, first write buffer 0 132-0 may be freed. Therefore, before programming of first data 318-0 to NAND flash memory 204 is completed, first write buffer 0 132-0 may be freed and available for reuse. In contrast to traditional storage media programming, first write buffer 0 132 - 0 may receive additional data from the host before first data 318 - 0 completes programming, which may improve write delivery to storage controller 126 or storage system 114 quantity.

As shown in Figure 4B, when the second write buffer 1 132-1 receives the second data 318 1 from the host, it continues to store the host data. The second data 318 1 is then provided to the RAID encoder 134 for calculating parity information for the second data 318 1 , to the ECC encoder 220 for ECC encoding, and programmed into the first NAND The second plane of die 0 204-0 (plane 1 406-1). The XOR engine 402 computes the XOR bits of the second data 318 1 , which is stored into the second plane of the RAID buffer 306 (Plane 1 404 - 1 ).

Continuing with FIG. 4C , upon completion of RAID encoder 134's calculation of the XOR bits of second data 318 - 1 , media write manager 130 may release second write buffer 1 132 - 1 , as shown at 412 . Similar to first write buffer 0 132-0, second write buffer 1 132-1 may be released prior to or during programming 414 of second data 318-1 to first NAND die 204-0. So in the second data 318 1 to NAND Before programming of flash memory 204 is completed, second write buffer 112-12-1 may be released and available for reuse. In some cases, first write buffer 0 132-0 and second write buffer 1 132-1 may be released for reuse before programming of second data 318 1 to NAND flash memory 204 is completed.

Referring to the storage of host data in the context of Figure 4C, third write buffer 2 132-2 receives third data 318-2 from the host. The third data 318-2 is then provided to the RAID encoder 134 to calculate parity information for the third data 318-2, to the ECC encoder 220 for ECC encoding, and to be programmed to the second NAND chip. The first plane of element 1 204-1 (plane 0 406-0). The XOR engine 402 may calculate the XOR bits for the third data 318-2, which may be stored to the first plane of the RAID buffer 306 (Plane 0 404-0).

As shown in FIG. 4D , in response to RAID encoder 134 completing the calculation of the XOR bits of third data 318 - 2 , media write manager 130 releases third write buffer 2 132 - 2 , as shown at 416 . Before or during programming 418 of third data 318-2 to second NAND die 204-1, third write buffer 2132-2 may be released. Therefore, before programming of third data 318-2 to NAND flash memory 204 is completed, third write buffer 2 132-2 may be freed and available for reuse. In some cases, first write buffer 0 132-0, second write buffer 1 132-1, and third write buffer 2 are completed before programming of third data 318-2 to NAND flash memory 204 is completed 132-2 can be released for reuse.

To end the storage of the host data in this example, the fourth write buffer 3 132-3 receives the fourth data 3183 from the host. The fourth data 318 3 is then provided to the RAID encoder 134 for calculating parity information of the fourth data 318 3 and to the ECC encoder 220 for ECC encoding and programmed to the second NAND die. The second plane of 1 204-1 (plane 1 406-1). The XOR engine 402 computes the XOR bits of the fourth data 318-3, which is stored to the second plane of the RAID buffer 306 (Plane 1 404-1). Similar to other write buffers 132, the media write manager may release fourth write buffer 3 132-3 upon completion of calculation of parity information for fourth information 318-3.

Referring to Figure 4E, the parity information or XOR bits calculated by the RAID encoder 134 may be stored or maintained in the RAID buffer 306 until programming of the last NAND die 204 is completed. In the case of die-level RAID, the parity information of the RAID encoder 134 is programmed from the RAID buffer 306 to the two planes 406 of the last NAND die n 204-n of the RAID stripe. By way of review, the host's data 318 is striped across other NAND die 204 members of the RAID stripe, such as NAND die 0 204-0 through NAND die n-1 (not shown). In this example, ECC encoder 220 (two examples shown for visual clarity) encodes corresponding parity information (eg, XOR bits) for first plane 0 406-0 and second plane 1 406-1. Then, the ECC-encoded parity information is respectively programmed to the first plane 0 406-0 and the second plane 1 406-1 of the last NAND wafer n 204-n. By implementing RAID encoding, data on any plane of a die that cannot be programmed (for example, die k < n) can also be recovered as shown in Equations 1 and 2.

(die k, plane 0) = (die 0, plane 0) XOR (die 1, plane 0) XOR…XOR (die k-1, plane 0) XOR (die k+1, plane 0) XOR...XOR(die n, plane 0) Formula 1: Data recovery of plane 0 of wafer k

(die k, plane 1) = (die 0, plane 1) XOR (die 1, plane 1) XOR…XOR (die k-1, plane 1) XOR (die k+1, plane 1) XOR...XOR(die n, plane 1) Formula 2: Data recovery of plane 1 of wafer k

In the event that programming of parity information to die n fails, the parity information can be maintained in the RAID buffer 306 until programming of die n is completed, so that the parity data can be restored directly from the RAID buffer 306 .

Alternatively, the RAID buffer 306 may also be released early once it is known that all (non-co-located) members of the RAID stripe have been successfully programmed to the storage medium. In this case, the RAID buffer 306 can be freed early, and if programming to the storage medium fails, the parity information can be passed Rebuild by reading all RAID members again. Alternatively, when parity reestablishment is not required, the stripe may lack RAID protection, and the stripe may be relocated to another location that effectively reestablishes parity information.

5A-5D illustrate examples of storage media programming utilizing self-adjusting write buffer release in the context of plane-level data redundancy. As shown at 500 in Figure 5A, storing host data to storage media generally includes processing data 318 received at write buffer 132 and moving it to NAND flash memory 204 for programming to the NAND media middle. NAND flash memory 204 is shown here as individual NAND die 1204-1 through NAND die n 204n, where n is any suitable integer. Any of the entities of Figures 5A-5D may be implemented similarly to the corresponding entities described with reference to Figures 1-4. In this example, storage controller 126 includes an instance of RAID encoder 134 to implement RAID encoding, which may provide improved data reliability to the storage controller and enable recovery of data lost during NAND programming operations (e.g., block or page fault).

In this example, the RAID encoder 134 is implemented in a planar RAID scheme (or plane-level RAID), which can protect against failures of a storage media plane (eg, a NAND plane). In some cases, using planar RAID can reduce the computational overhead involved in on-die RAID (eg, Figures 4A-4E). In other aspects, a Reed-Solomon code encoder can be implemented in place of a RAID encoder to achieve protection against failure events in multiple RAID stripe members (e.g., planes or dies).

As shown in Figure 5A, first write buffer 0 132-0 may receive first data 318-0 from a host (such as host system 102). The first data 318-0 is then provided to the RAID encoder 134 for calculating parity information for the first data 318-0, and to the ECC encoder 220 for ECC encoding, and is then programmed into the first The first plane (plane 0 506-0) of NAND die 0 204-0. In this example, RAID encoder 134 includes XOR engine 502 to compute XOR bits for first data 318-0, which is stored into the first plane of RAID buffer 306 (plane 0 504-0). As noted, programming the first data 318-0 can consume much more time than the calculation of the parity information of the RAID encoder 134 or the XOR engine 502.

Continuing with FIG. 5B , in response to RAID encoder 134's calculation of the XOR bits, media write manager 130 may release first write buffer 0 132 - 0 , as shown at 508 . Before or during programming 510 of first data 318-0 to first NAND die 204-0, first write buffer 0 132-0 may be freed. Therefore, before programming of first data 318-0 to NAND flash memory 204 is completed, first write buffer 0 132-0 may be freed and available for reuse. In contrast to traditional storage media programming, first write buffer 0 132 - 0 may receive additional data from the host before first data 318 - 0 completes programming, which may improve write delivery to storage controller 126 or storage system 114 quantity.

As shown in Figure 5B, when the second write buffer 1 132-1 receives the second data 318 1 from the host, storage of the host data continues. The second data 318 1 is then provided to the RAID encoder 134 for calculating parity information for the second data 318 1 and to the ECC encoder 220 for ECC encoding, and then programmed to the first NAND The second plane of die 0 204-0 (plane 1 506-1). The XOR engine 502 computes the XOR bits of the second data 318 1 , which is stored into the second plane of the RAID buffer 306 (Plane 1 504 - 1 ).

Continuing with FIG. 5C , based on completion of RAID encoder 134's calculation of the XOR bits for second data 318 - 1 , media write manager 130 may release second write buffer 1 132 - 1 , as shown at 512 . Similar to first write buffer 0 132-0, second write buffer 1 132-1 may be released prior to or during programming 514 of second data 318-1 to first NAND die 204-0. Therefore, before programming of the second data 318 1 to the NAND flash memory 204 is completed, the second write buffer 1 132-1 may be freed and available for reuse. Here, it is assumed that the parity information has also been calculated for the third data (not shown), which has been sent to the programming interface of the NAND flash memory 204 . In response to the calculation of parity information for the third data, media write manager 130 releases third write buffer 2 132-2, as shown at 516. In this way, the release of the third write buffer 2 132-2 can occur before or during the programming 518 of the third data, thereby causing the third write buffer 2 to be released before the corresponding data is programmed into the NAND flash memory 204. 2 132-2 Free for reuse.

Ending the storage of host data as shown in Figure 5C, the last write buffer 2n 132-2n (eg, the last write buffer for the stripe) receives data 318-2n from the host for the last plane member of the RAID stripe . Data 318-2n is then provided to RAID encoder 134 for computing parity information for data 318-2n, to ECC encoder 220 for ECC encoding, and programmed to the nth NAND die n 204-n's first plane (plane 0 506-0). The XOR engine 502 computes the XOR bits for data 318-2n, which is stored into the first plane of the RAID buffer 306 (Plane 0 504-0). Similar to other write buffers 132, the media write manager may release the final write buffer 2n 132-2n upon completion of calculation of parity information for message 318-2n.

Referring to Figure 5D, the parity information or XOR bits calculated by the RAID encoder 134 may be stored or maintained in the RAID buffer 306 until programming of the last NAND die 204 is completed. In the case of plane-level RAID, the parity information for each plane (504-0 and 504-1) of the RAID encoder 134 is programmed into the second plane (204-n) of the last NAND die n 204-n of the RAID stripe. Plane 0 506-1) before, are combined by XOR operation. By way of review, the host's data 318 is striped across other NAND plane members of the RAID stripe, such as the plane of NAND die 0 204-0 to the first plane of NAND die n. In this example, ECC encoder 220 encodes parity information (eg, XOR bits) for the combination of first plane 0 506-0 and second plane 1 506-1. The ECC-encoded parity information is then programmed into the second plane 1 506-1 of the final NAND die n 204-n. By implementing RAID encoding, data on any plane of a die that cannot be programmed (for example, die k < n) can also be recovered as shown in Equations 3 and 4.

(die k, plane 0) = (die 0, plane 0) XOR (die 1, plane 0) XOR…XOR (die k-1, plane 0) XOR (die k+1, plane 0) XOR...XOR(die n, plane 0) Formula 3: Data recovery of plane 0 of wafer k

(die k, plane 1) = (die 0, plane 1) XOR (die 1, plane 1) XOR…XOR (die k-1, plane 1) XOR (die k+1, plane 1) XOR...XOR(die n, plane 1) Formula 4: Data recovery of plane 1 of wafer k

In the event that programming of the parity information to die n fails, the parity information may be retained in the RAID buffer 306 until programming of the second plane of die n is completed, such that the parity data is directly available from the RAID buffer 306 restore. These are just a few examples of storage media programming utilizing self-adjusting write buffer release, and others of the examples are implemented and described throughout this disclosure.

Techniques for self-tuning write buffer release and data recovery

The following discussion describes techniques for programming storage media that utilize self-adjusting write buffer release and/or parity-based data recovery. These techniques may be implemented using any of the environments and entities described herein, such as media write manager 130, write buffer 132, and/or RAID encoder 134. These techniques include the various methods shown in Figures 6-8, each of which is shown as a collection of operations that can be performed by one or more entities.

Methods 600-800 are not necessarily limited to the order of operations shown in the associated figures. Rather, any operations within this operation may be repeated, skipped, replaced, or reordered to implement various aspects described herein. Furthermore, these methods may be used in whole or in part in conjunction with each other, whether performed by the same entity, separate entities, or any combination thereof. In portions of the following discussion, reference will be made, for example, to the operating environment 100 of Figure 1 and the various entities or configurations of Figures 2-5D. Such references should not be construed as limiting the described aspects to the operating environment 100, entity, or configuration, but rather as an illustration of one example among various examples. Alternatively or additionally, the operations of the method may also be implemented by or in conjunction with the entities described with reference to the system-on-chip of FIG. 9 and/or the storage system controller of FIG. 10 .

6 depicts an example method 600 for storage media programming utilizing self-adjusting write buffer release, including being performed by or with the media write manager 130, write buffer 132, or RAID encoder 134 of a storage media controller. operation.

At 602, data received from the host interface is stored into the write buffer. The write buffer can be implemented in the SRAM or DRAM of the memory controller. In some cases, the connection from the host interface The received data corresponds to the write command of the host system from which the data is received via the host interface. A write command may specify the destination of data in a storage medium, such as the NAND flash memory of a storage system.

At 604, parity information is determined using a parity-based encoder for data stored to the write buffer. Before or during determination of parity information, data may be transferred to the storage system's internal buffer or storage medium. Parity-based encoders may include RAID encoders with XOR engines or XOR buffers for determining parity information (eg, XOR bits). The parity information may correspond to data to be written to a plane or die of the storage medium and other data to be written to at least one other plane or at least one other die of the storage medium. For example, parity data may correspond to XOR bits of data members of a RAID stripe spanning multiple dies or planes of NAND flash memory.

At 606, parity information for the data is stored into the parity-based encoder's buffer. Parity information may be stored into planes of the buffer based on the corresponding plane in the storage medium into which the data is programmed. Alternatively or additionally, parity information for data and other data may be maintained in a buffer of the parity-based encoder until the parity information is successfully programmed into the storage medium.

At 608, in response to the determination of parity information, the write buffer is released. The write buffer is released before the data is completely programmed into the storage medium. Parity-based encoders can provide notification indicating the completion of a determination of parity information. In some cases, the parity-based encoder is monitored to detect when determination or calculation of parity information is complete and/or stored in the parity-based encoder's buffer. In response to a notification or detection of a determination that parity information is complete, a notification or interrupt may be sent to the memory controller's firmware to cause the write buffer to be released. When freed, the write buffer is available for reuse, such as receiving subsequent data from the host interface.

At 610, after the write buffer is released from storing the data, at least a portion of the data is written to the storage medium. Because the write buffer is released after parity information is determined, the write buffer can be released before data is written or programmed to the storage medium. In this way, after releasing the write buffer After that, you can continue to write or program data to the storage medium. In the event of a programming failure, data can be recovered based on parity information and without using data previously held in the write buffer.

Optionally at 612, prior to completing the writing of the data to the storage medium, additional data is stored to the write buffer. As noted, programming of data can continue after the write buffer is released, which can be freely reused by the memory controller's firmware or other elements. In some cases, additional data is stored to the write buffer while previous data is programmed to the storage medium. Self-tuning aspects of buffer release can improve write buffer utilization or increase the write throughput of a storage medium by freeing the write buffer and reusing the write buffer.

7 depicts an example method 700 for freeing a write buffer based on calculation of parity information, including performed by or in conjunction with the media write manager 130, write buffer 132, and/or RAID encoder 134 of a storage media controller. The operation performed.

At 702, data from the host system is received at the write buffer. Data is received from the host system through the storage controller's host interface. In some cases, data is received or obtained from the host system as part of an I/O command to write the data to a storage medium associated with the storage controller.

At 704, data is transferred from the write buffer to the RAID encoder. Typically, data is transferred, passed, or sent to a RAID encoder while another internal buffer of the storage system maintains the data. In other words, the RAID encoder can process the data while keeping a copy of the data in another buffer or while the data is being sent to the storage medium for programming. By doing so, the host system can be freed from the data (eg, cache-on mode) and the storage controller can have a native replica in the event of a data processing or programming failure.

At 706, parity information is calculated for the data using the RAID encoder. The RAID encoder may include an XOR engine or XOR buffer for calculating or generating XOR bits of the data in the write buffer. XOR bits (or parity information for data) can be maintained in the parity-based encoder's buffer. In some cases, RAID encoders are configured to generate interrupts or provide support for parity Notification of completion of calculation of information. For example, the RAID encoder may provide an interrupt to the storage controller's firmware that indicates that calculation of the parity information is complete and/or that the parity information for the data is maintained in the RAID encoder's buffer.

At 708, in response to completion of calculation of parity information for the data, the write buffer is released. Before releasing the write buffer, the data can be copied to another internal buffer of the storage system or programmed to the storage medium. The write buffer can be released before the data is fully programmed into the storage medium. In some cases, the write buffer is released before programming of data to the storage medium begins. Alternatively or additionally, the write buffer may be released in response to an interrupt or notification provided by the RAID encoder, ECC encoder, or other element of the storage controller.

At 710, the data is encoded using an ECC encoder to provide ECC encoded data. The ECC encoder can encode data after RAID encoding or in parallel with RAID encoding. In some cases, the ECC encoder receives data from the RAID encoder after parity information is calculated from the data.

At 712, after the write buffer is released from storing the data, at least a portion of the ECC encoded data is written to the storage medium. Because the write buffer is released after parity information is determined, the write buffer is released before or at the same time as the data is ECC encoded by the ECC encoder. In this way, writing or programming of ECC-encoded data to the storage medium may occur or continue after the write buffer is released. In the event of a programming failure, data can be recovered based on parity information and without using data previously held in the write buffer.

Optionally at 714, parity information is written to the storage medium. Parity information may be written to any suitable area of the storage medium, such as the last die or plane of a RAID stripe. Normally, when parity information is held by the RAID buffer, parity information can be written to the last member of the RAID stripe. By doing this, parity information can be recovered from the RAID buffer in the event of a storage media programming failure.

Optionally at 716, additional data is received at the write buffer. As noted, programming of ECC-encoded data may continue after releasing the write buffer, which is free for reuse by the memory controller's firmware or other components. In some cases, other data is received at the write buffer while previous data is being programmed to the storage medium. Self-tuning aspects of buffer release can improve write buffer utilization or increase the write throughput of a storage medium by freeing and reusing write buffers.

8 depicts an example method 800 for recovering from a programming failure utilizing parity-based data reconstruction, including being performed by or in conjunction with the media write manager 130, write buffer 132, and/or RAID encoder 134 of a storage media controller. The operation performed.

At 802, parity information is calculated using the RAID encoder for the data received from the host interface. The RAID encoder may include an XOR engine or XOR buffer for calculating or generating XOR bits for writing data in the buffer.

At 804, the parity information is stored in the RAID encoder's buffer. XOR bits (or parity information for data) can be maintained in the parity-based encoder's buffer. In some cases, the RAID encoder is configured to generate an interrupt or provide notification that the calculation of parity information is complete.

At 806, the write buffer is released after calculating the parity information. The write buffer can be released before the data is fully programmed into the storage medium. Alternatively or additionally, the write buffer is released in response to an interrupt or notification provided by the storage controller's RAID encoder, ECC encoder, media write manager, or other element.

At 808, programming of data to the area of the storage medium is initiated. Data may be released to the storage medium interface for programming to a region of the storage medium (eg, block, plane, or die). In some cases, data is sent to the flash memory controller via the memory controller's flash memory interface for programming to a region of flash memory. For example, a media I/O provided with data may designate a plane on which the flash memory controller writes data to the storage medium.

At 810, a programming failure is detected for programming of data to the storage medium. Programming faults can include page faults, block faults, plane faults, wafer faults, etc. Programming failures can be detected after the write buffer is released from storing data.

At 812, the data is reconstructed based on the parity information and corresponding data from other areas of the storage medium. By implementing RAID, the storage controller can reconstruct lost data from a programming failure based on parity information in the RAID buffer and data from other members of the RAID stripe (e.g., die or planes). By doing so, the storage controller is able to reconstruct the data previously held by the freed write buffer.

At 814, the reconstructed data is programmed to a different area of the storage medium. In the event of a programming failure, the storage controller is able to reconstruct the data lost due to the programming failure and attempt to reprogram the data to a different area of the storage medium, which can ensure the reliability of the data managed by the storage controller. Alternatively or additionally, the RAID buffer's parity information may also be reprogrammed to a different area of the storage medium if a programming failure occurs while trying to write the parity information to the last member of the RAID stripe. As noted, parity information is maintained in the RAID buffer until programming to the storage medium is successfully completed to ensure the ability to recover from such programming failures. Alternatively, the RAID buffer can be released when the stripe is reallocated and its parity information is regenerated.

SoC

Figure 9 illustrates an example system on chip (SoC) 900 that can implement various aspects of storage media programming utilizing self-adjusting write buffer release. SoC 900 can be implemented in any suitable system or device, such as smartphones, netbooks, tablets, access points, network attached storage, cameras, smart devices, printers, set-top boxes, servers, data center, solid state drive (SSD), hard disk drive (HDD), storage drive array, memory module, automotive computing system, or any other suitable type of device (such as other devices described herein). Although described with reference to an SoC, the entities of Figure 9 may also be implemented as other types of integrated circuits or embedded systems, such as application specific integrated circuits (ASICs), memory controllers, storage controllers, communications controllers, Specialized Standard Products (ASSP), Digital signal processor (DSP), programmable SoC (PSoC), system-in-package (SiP) or field-programmable gate array (FPGA).

SoC 900 may interface with electronic circuitry, a microprocessor, memory, input-output (I/O) control logic, communications interfaces, firmware, and/or software for providing functionality of a computing device, host system, or storage system (such as herein). Any of the described devices or elements (such as a storage drive or storage array) are integrated together. SoC 900 may also include an integrated data bus or interconnect fabric (not shown) that couples the various elements of the SoC for signaling, data communication, and/or routing between control elements. The integrated data bus, interconnect fabric, or other components of SoC 900 may be exposed or accessed through an external port, parallel data interface, serial data interface, fabric-based interface, peripheral device interface, or any other suitable data interface. For example, components of the SoC 900 can access or control external storage media through an external interface or an off-chip data interface.

In this example, SoC 900 includes various elements, such as input-output (I/O) control logic 902 and a hardware-based processor 904 (processor 904), such as a microprocessor, a processor core, an application processor, DSP etc. SoC 900 also includes any type of memory 906, which may include RAM, SRAM, DRAM, non-volatile memory, ROM, one-time programmable (OTP) memory, multiple-time programmable (MTP) memory, fast Flash memory and/or other suitable electronic data storage devices and/or combinations thereof. In some aspects, processor 904 and code stored on memory 906 are implemented as a storage system controller or storage aggregator to provide various functions associated with storage media programming utilizing self-adjusting write buffer release. In the context of this disclosure, memory 906 stores data, code, instructions or other information via non-transitory signals and does not include carrier waves or transient signals. Alternatively or additionally, SoC 900 may include a data interface (not shown) for accessing additional or expandable off-chip storage media, such as solid-state memory (eg, flash memory or NAND memory), based on Magnetic memory media, or optically based memory media.

SoC 900 may also include firmware 908 , applications, programs, software, and/or operating systems, which may be embodied as processor-executable instructions maintained on memory 906 for execution by processor 904 to implement the functions of SoC 900 . SoC 900 may also include other communication interfaces, such as a transceiver interface for controlling or communicating with components of a local on-chip (not shown) or off-chip communication transceiver. . Alternatively or additionally, the transceiver interface may also include or implement signaling interfaces to carry radio frequency (RF), intermediate frequency (IF), or baseband frequency signals off-chip to facilitate communication through the transceiver, physical layer transceiver (PHY), or coupling Wired or wireless communication to SoC 900's Media Access Controller (MAC). For example, SoC 900 may include a transceiver interface configured to allow storage over a wired or wireless network, such as to provide a network-attached storage (NAS) volume that enables storage media programming with self-adjusting write buffer release.

SoC 900 also includes a media write manager 130, a write buffer 132, and a RAID encoder 134, which may be implemented separately as shown, may be combined with storage elements, data interfaces, or may be accessible through an off-chip interface . In accordance with aspects of storage media programming utilizing self-adjusting write buffer release, media write manager 130 may interact with RAID encoder 134 to calculate parity information for data stored in write buffer 132 . Then, in response to the computation of parity information, the media write manager may release the write buffer, thereby releasing write buffer 132 for reuse before or while data is programmed to the storage medium. By doing so, self-adjusting release of write buffers can result in improved write buffer utilization and increased storage medium write throughput. Any of these entities may be embodied as distinct or combined elements, as described with reference to the various aspects presented herein. Examples of these elements and/or entities or corresponding functions are described with reference to the corresponding elements or entities of the environment 100 of FIG. 1 , the corresponding configurations shown in FIGS. 2 to 5D , and/or the methods shown in FIGS. 6 to 8 . All or portions of media write manager 130 may be implemented as processor-executable instructions maintained by memory 906 and executed by processor 904 to implement various aspects of storage media programming and/or utilizing self-adjusting write buffer release. Characteristics.

Media write manager 130 may be implemented independently or in combination with any suitable components or circuitry to implement the aspects described herein. For example, media write manager 130 may be implemented as part of a DSP, processor/memory bridge, I/O bridge, graphics processing unit, memory controller, storage controller, arithmetic logic unit (ALU), etc. Media write manager 130 may also be provided internally with other entities of SoC 900, such as integrated with processor 904, memory 906, storage media interface, or firmware 908 of SoC 900. Alternatively or additionally, media write manager 130, RAID encoder 134, RAID encoder 134, and/or other elements of SoC 900 may be implemented as hardware, firmware, fixed logic circuitry, or any combination thereof.

As another example, consider Figure 10, which illustrates an example storage system controller 1000 in accordance with one or more aspects of storage media programming utilizing self-adjusting write buffer release. In various aspects, storage system controller 1000 or any combination of elements thereof may be implemented as a storage drive controller, storage media controller, NAS controller, fabric interface, NVMe target for solid state storage media or other types of storage media. or storage aggregation controller. In some cases, storage system controller 1000 is implemented similar to or with reference to elements of SoC 900 described in FIG. 9 . In other words, an instance of SoC 900 may be configured as a storage system controller, such as storage system controller 1000, for managing solid-state (eg, NAND flash memory-based) media.

In this example, storage system controller 1000 includes input/output (I/O) control logic 1002 and a processor 1004, such as a microprocessor, processor core, application processor, DSP, or the like. In some aspects, the processor 1004 and firmware of the storage system controller 1000 may be implemented to provide various functions associated with storage media programming utilizing self-adjusting write buffer release, such as described with reference to any of methods 600-800 those functions. Storage system controller 1000 also includes a host interface 1006 (eg, SATA, PCIe, NVMe, or fabric interface) and a storage media interface 1008 (eg, NAND interface) that enable access to the host system and storage media, respectively. Storage system controller 1000 also includes flash translation layer 1010 (FTL 1010), device level manager 1012, and I/O scheduler (not shown). In some aspects of storage media programming utilizing self-adjusting write buffer release, FTL 1010 processes write commands received via host interface 1006 to manage the movement of data within or through storage system controller 1000.

Storage system controller 1000 also includes instances of media write manager 130 , write buffer 132 , RAID encoder 134 , and ECC encoder 220 . Any or all of these elements may be implemented separately as shown, or may be implemented in conjunction with processor 1004, host interface 1006, storage media interface 1008, flash memory translation layer 1010, device level manager 1012, and/or or I/O scheduler combined together. Examples of these elements and/or entities or corresponding functions are described with reference to corresponding elements or entities of environment 100 of FIG. 1 or corresponding configurations shown in FIGS. 2-5D. In accordance with aspects of storage media programming utilizing self-adjusting write buffer release, media write manager 130 may interact with RAID encoder 134 for computing parity information for data stored in write buffer 132 . The media write manager may then release the write buffer in response to the computation of parity information, thereby freeing the write buffer 132 for reuse before or while data is programmed to the storage medium. By doing so, self-adjusting release of write buffers can result in improved write buffer utilization and increased storage medium write throughput. Media write manager 130 may be implemented in whole or in part as processor-executable instructions maintained by memory of the controller and executed by processor 1004 to implement various aspects of storage media programming utilizing self-adjusting write buffer release and /or features.

Although the subject matter has been described in language specific to structural features and/or methodological operations, it should be understood that the subject matter defined in the patent scope of the appended claims is not necessarily limited to the specific examples, features or operations described herein, including the order in which they are performed.

130:Storage media write manager

132:Write buffer

134:RAID encoder

204:Flash memory device

208:Media interface

220: Error correction code encoder

302: Firmware

304:Hardware

306: RAID buffer

308: Host interface driver

310: Host command processor

312:Media interface drive

314:Media Command Manager

316: Host input/output command (host I/O)

318:Data

318-0~318-3, 318-2n: data

320: Flash Memory Translation Layer

322:Media input/output command (Media I/O)

324:Data

Claims (20)

A storage medium programming method for utilizing self-adjusting write buffer release, including: storing data into a write buffer, the data being received from a host interface of a storage system, the storage system including a storage medium; utilizing a parity-based encoder to determine parity information for the data stored in the write buffer; responsive to completion of the determination of the parity information for the data, releasing the write buffer; and in the write buffer After the area is released from storing the data, at least a portion of the data is written to the storage medium of the storage system. The method of claim 1, wherein the data is first data, and the method further includes storing the second data before completing writing the first data to the storage medium of the storage system. to the write buffer. The method according to claim 1, further comprising storing the parity information of the data into a buffer associated with the parity-based encoder while the data is written to the storage medium. middle. The method according to claim 3, further comprising: writing the parity information from the buffer associated with the parity-based encoder to the storage medium of the storage system; or after completing the process of writing the parity information to the storage medium of the storage system; When the data is written to the storage medium of the storage system, the parity information is deleted from the buffer associated with the parity-based encoder. According to the method described in request item 1, further comprising: Encoding the data via an error correction code (ECC) encoder to provide ECC-encoded data; and writing the ECC-encoded data to the storage medium of the storage system. The method of claim 5, wherein the data is transmitted from the parity-based encoder to the ECC encoder, and the method further includes: monitoring the parity-based encoder to detect the Determination of parity information is completed; and after the data is transmitted to the ECC encoder, in response to completion of determination of parity information, notifying firmware of the storage system to release the write buffer. The method of claim 1, wherein the parity-based encoder is a RAID encoder of the storage system, and the parity information includes the parity information generated by the RAID encoder for the The calculated XOR bits of the data. The method according to claim 1, wherein: the storage medium is a flash memory; the data is written to a plane of the flash memory or a wafer of the flash memory; and the The parity information corresponds to the data written to the plane or the die of the flash memory and to at least one other plane or at least one other die of the flash memory. of other data. The method of claim 1, wherein the data is written to an area of the storage medium as part of a storage medium programming operation, and the method further includes: detecting that the data is written to the storage medium failure of the programming operation of the region; reconstructing the data based on the parity information and corresponding data from other regions of the storage medium; and writing the reconstructed data to a different location of the storage medium area. A storage medium programming device for utilizing self-adjusting write buffer release, comprising: a host interface configured to communicate with a host system; a write buffer operably coupled to The host interface; storage medium; a media interface configured to achieve access to the storage medium; a parity-based encoder; and a media write manager, the media write manager is Configured to: receive data from the host interface via one of the write buffers; and calculate parity information of the data received by the write buffer via the parity-based encoder; storing the parity information in a buffer of the parity-based encoder; releasing the write buffer in response to calculation of the parity information for the data; and storing the parity information in the write buffer After the data is released, at least a portion of the data is written to the storage medium of the device. The apparatus of claim 10, wherein the data is first data, and the media write manager is further configured to, before completing writing the first data to the storage medium of the apparatus, via The write buffer is released to receive the second data. The device of claim 10, wherein the media write manager is further configured to: write the parity information from the buffer of the parity-based encoder to the storage medium of the device or Another memory of the device; or clearing the parity information from the buffer of the parity-based encoder when completing writing the data to the storage medium of the device. The apparatus of claim 10, further comprising an error correction code (ECC) encoder, and wherein the media write manager is further configured to: encode the data via the ECC encoder to provide ECC-encoded data; and writing the ECC-encoded data to the storage medium of the device. The apparatus of claim 10, wherein the data is sent from the parity-based encoder to the ECC encoder, and the media write manager is further configured to: receive from the parity-based encoder a notification indicating that the determination of the parity information is complete; and after the data is sent to the ECC encoder, generating an interrupt to the firmware of the device to cause a release of the write buffer . The apparatus of claim 10, wherein the data is written to an area of the storage medium as part of a storage medium programming operation, and the media write manager is further configured to: detect that the data is written failure of the programming operation to the region of the storage medium; reconstructing the data based on the parity information and corresponding data from other regions of the storage medium; and writing the reconstructed data to the A different area of storage media. A system on a chip (SoC), including: a host interface, the host interface communicates with a host system; a write buffer, the write buffer is operatively coupled to the host interface; a media interface, the The media interface is used to access the storage medium of a storage system; a parity-based encoder; a hardware-based processor; a memory storing processor-executable instructions that implement a media write manager in response to execution by the hardware-based processor to: write data from the host data received by the interface is stored in one of the write buffers; determining parity information of the data stored in the write buffer via the parity-based encoder; responding to the data based on the determination of the parity information, releasing the write buffer; and writing at least a portion of the data to the storage medium after the write buffer is released from storing the data. The system on a chip according to claim 16, wherein the data is first data, and the media write manager is further implemented to complete all writing of the first data to the storage medium of the storage system. Before writing, the second data is stored in the write buffer. The system single chip according to claim 16, wherein the media write manager is further implemented to: when the data is written to the storage medium, store the parity information for the data to the same location as the data. into the buffer associated with the parity-based encoder; or write the parity information from the buffer associated with the parity-based encoder to the storage medium of the storage system. The system-on-chip of claim 16, wherein the media write manager is further implemented to: receive a notification from the parity-based encoder, the notification indicating completion of the determination of the parity information; and An interrupt is generated to firmware of the device to cause the release of the write buffer. The system-on-chip of claim 16, wherein the data is written to an area of the storage medium as part of a storage medium programming operation, and the media write manager is further configured to: detect that the data failure of the programming operation to write to the region of the storage medium; reconstructing the data based on the parity information and corresponding data from other regions of the storage medium; and writing the reconstructed data to a different area of the storage medium.