Abstract: Disclosed herein are systems and methods that recognize and recapture potentially unused processing time in typical page program and block erase operations in non-volatile memory (NVM) devices. In one embodiment, a characterization module within a controller executes a characterization procedure by performing page program and block erase operations on one or more NVM devices in an array and storing execution time data of the operations in a calibration table. The procedure may be executed at start-up and/or periodically so that the time values are reflective of the actual physical condition of the individual NVM devices. A task manager uses the stored time values to estimate the time needed for completing certain memory operations in its task table. Based on the estimated time for completion, the task manager assigns tasks to be executed during page program and/or block erase cycles, so that otherwise unused processing time can be utilized.

Abstract: A command portal enables a host system to send non-standard or “vendor-specific” storage subsystem commands to a storage subsystem using an operating system (OS) device driver that does not support or recognize such non-standard commands. The architecture thereby reduces or eliminates the need to develop custom device drivers that support the storage subsystem's non-standard commands. To execute non-standard commands using the command portal, the host system embeds the non-standard commands in blocks of write data, and writes these data blocks to the storage subsystem using standard write commands supported by standard OS device drivers. The storage subsystem extracts and executes the non-standard commands. The non-standard commands may alternatively be implied by the particular target addresses used. The host system may retrieve execution results of the non-standard commands using standard read commands.

Abstract: Systems and methods for an architecture for optimizing execution of storage access commands is disclosed. The architecture enables a storage subsystem to execute storage access commands while satisfying one or more optimization criteria. The architecture thereby provides predictable execution times of storage access commands performed on a storage subsystem. In order to optimize execution of storage access commands, in one embodiment the host system sends a calibration request specifying a storage access command and an optimization criterion. In response to the calibration request, the storage subsystem determines the execution speeds of the storage access command within the non-volatile memory storage array and selects at least one region within the non-volatile memory storage array having the execution speed that satisfies the optimization criterion.

Abstract: A command portal enables a host system to send non-standard or “vendor-specific” storage subsystem commands to a storage subsystem using an operating system (OS) device driver that does not support or recognize such non-standard commands. The architecture thereby reduces or eliminates the need to develop custom device drivers that support the storage subsystem's non-standard commands. To execute non-standard commands using the command portal, the host system embeds the non-standard commands in blocks of write data, and writes these data blocks to the storage subsystem using standard write commands supported by standard OS device drivers. The storage subsystem extracts and executes the non-standard commands. The non-standard commands may alternatively be implied by the particular target addresses used. The host system may retrieve execution results of the non-standard commands using standard read commands.

Abstract: A command portal enables a host system to send non-standard or “vendor-specific” storage subsystem commands to a storage subsystem using an operating system (OS) device driver that does not support or recognize such non-standard commands. The architecture thereby reduces or eliminates the need to develop custom device drivers that support the storage subsystem's non-standard commands. To execute non-standard commands using the command portal, the host system embeds the non-standard commands in blocks of write data, and writes these data blocks to the storage subsystem using standard write commands supported by standard OS device drivers. The storage subsystem extracts and executes the non-standard commands. The non-standard commands may alternatively be implied by the particular target addresses used. The host system may retrieve execution results of the non-standard commands using standard read commands.

Abstract: A storage subsystem contains multiple non-volatile memory arrays that are accessible to a host system when the storage subsystem is connected thereto. The storage subsystem implements commands and/or modes for enabling the host system to create and use backup copies of files, such that the host system can recover when files become corrupted or otherwise lost. In one embodiment, the storage subsystem presents the non-volatile memory arrays to the host's operating system as distinct storage devices (e.g., ATA device 0 and 1), and implements special commands for copying data between these storage devices. The subsystem may alternatively present the memory arrays to the host operating system as a single storage device. The storage subsystem may have a standard form factor, such as a form factor commonly used for memory cards.

Abstract: A solid-state storage subsystem, such as a non-volatile memory card or drive, includes multiple interfaces and a memory area storing information used by a data arbiter to prioritize data commands received through the interfaces. As one example, the information may store a priority ranking of multiple host systems that are connected to the solid-state storage subsystem, such that the data arbiter may process concurrently received data transfer commands serially according to their priority ranking. A host software component may be configured to store and modify the priority control information in solid-state storage subsystem's memory area.

Abstract: A command portal enables a host system to send non-standard or “vendor-specific” storage subsystem commands to a storage subsystem using an operating system (OS) device driver that does not support or recognize such non-standard commands. The architecture thereby reduces or eliminates the need to develop custom device drivers that support the storage subsystem's non-standard commands. To execute non-standard commands using the command portal, the host system embeds the non-standard commands in blocks of write data, and writes these data blocks to the storage subsystem using standard write commands supported by standard OS device drivers. The storage subsystem extracts and executes the non-standard commands. The non-standard commands may alternatively be implied by the particular target addresses used. The host system may retrieve execution results of the non-standard commands using standard read commands.

Abstract: A non-volatile solid-state storage subsystem, such as a non-volatile memory device, maintains usage statistics reflective of the wear state, and thus the remaining useful life, of the subsystem's memory array. A host system reads the usage statistics information, or data derived therefrom, from the subsystem to evaluate the subsystem's remaining life expectancy. The host system may use this information for various purposes, such as to (a) display or report information regarding the remaining life of the subsystem; (b) adjust the frequency with which data is written to the subsystem; and/or (c) select the type(s) of data written to the subsystem.

Abstract: A storage subsystem monitors one or more conditions related to the probability of a data error occurring. Based on the monitored condition or conditions, the storage subsystem adjusts an error correction setting, and thus the quantity of ECC data used to protect data received from a host system. To enable blocks of data to be properly checked when read from memory, the storage subsystem stores ECC metadata indicating the particular error correction setting used to store particular blocks of data. The storage subsystem may be in the form of a solid-state non-volatile memory card or drive that attaches to the host system.

Abstract: A solid-state storage subsystem, such as a non-volatile memory card or drive, includes multiple interfaces and a memory area storing information used by a data arbiter to prioritize data commands received through the interfaces. As one example, the information may store a priority ranking of multiple host systems that are connected to the solid-state storage subsystem, such that the data arbiter may process concurrently received data transfer commands serially according to their priority ranking. A host software component may be configured to store and modify the priority control information in solid-state storage subsystem's memory area.

Abstract: A non-volatile storage subsystem is capable of serving as a configuration controller for configuring/programming one or more field-programmable devices, such as FPGAs, of a target computer system. The storage subsystem may be in the form of a memory card or drive that plugs into a standard slot or external port of the target system. When connected to the target system, the storage subsystem uses the appropriate download interface/protocol to stream or otherwise send configuration data stored in its non-volatile storage to the target system's field-programmable device(s). Thus, the need for a configuration controller in the target system is avoided. Once the configuration process is complete, the storage subsystem preferably acts as a standard storage subsystem, such as an ATA storage drive, that may be used by the target system to store data.

Abstract: A storage subsystem includes a variable-size write buffer that temporarily stores write data received from a host system. The storage subsystem is capable of adjusting the size of the write buffer so as to vary both the performance (e.g., sustained write speed) of the storage subsystem and a risk of data loss. In one embodiment, the storage subsystem implements a command set that enables the host system to directly control the size of the write buffer. The storage subsystem may additionally or alternatively be capable of adjusting the size of the write buffer based on monitored operating conditions, such as the temperature, the stability/consistency of a power signal received from the host system, and/or the elapsed time since the storage subsystem was last powered up.

Abstract: A storage subsystem comprises a set of zone definitions that uses physical block addresses to divide a memory array in the storage subsystem into zones or segments. A set of zone parameters defines user access modes and security levels for each of the segments. Defining zones for the memory array provide flexibility and increased protection for data stored in the memory array. For example, data of one zone can be quickly erased without affecting data stored in other zones and critical data can be stored in read-only zones to prevent inadvertent overwrite.

Abstract: A non-volatile solid-state storage subsystem, such as a non-volatile memory device, maintains usage statistics reflective of the wear state, and thus the remaining useful life, of the subsystem's memory array. A host system reads the usage statistics information, or data derived therefrom, from the subsystem to evaluate the subsystem's remaining life expectancy. The host system may use this information for various purposes, such as to (a) display or report information regarding the remaining life of the subsystem; (b) adjust the frequency with which data is written to the subsystem; and/or (c) select the type(s) of data written to the subsystem.

Abstract: A solid-state storage subsystem, such as a non-volatile memory card or drive, includes a main memory area that is accessible via standard memory access commands (such as ATA commands), and a restricted memory area that is accessible only via one or more non-standard commands. The restricted memory area stores information used to control access to, and/or use of, information stored in the main memory area. As one example, the restricted area may store one or more identifiers, such as a unique subsystem identifier, needed to decrypt an executable or data file stored in the main memory area. A host software component is configured to retrieve the information from the subsystem's restricted memory area, and to use the information to control access to and/or use of the information in the main memory area.

Abstract: A storage subsystem monitors one or more conditions related to the probability of a data error occurring. Based on the monitored condition or conditions, the storage subsystem adjusts an error correction setting, and thus the quantity of ECC data used to protect data received from a host system. To enable blocks of data to be properly checked when read from memory, the storage subsystem stores ECC metadata indicating the particular error correction setting used to store particular blocks of data. The storage subsystem may be in the form of a solid-state non-volatile memory card or drive that attaches to the host system.

Abstract: A storage subsystem is disclosed that maintains (a) statistics regarding errors detected via an ECC (error correction code) module of the storage subsystem; and/or (b) historical data regarding operating conditions experienced by the storage subsystem, such as temperature, altitude, humidity, shock, and/or input voltage level. The storage subsystem, and/or a host system to which the storage subsystem attaches, may analyze the stored data to assess a risk of a failure event such as an uncorrectable data error. The results of this analysis may be displayed via a user interface of the host system, and/or may be used to automatically take a precautionary action such as transmitting an alert message or changing a mode of operation of the storage subsystem.

Abstract: A non-volatile storage subsystem maintains, and makes available to a host system, monitor data reflective of a likelihood of a data error occurring. The monitor data may, for example, include usage statistics and/or sensor data. The storage subsystem transfers the monitor data to the host system over a signal interface that is separate from the signal interface used for standard storage operations. This interface may be implemented using otherwise unused pins/signal lines of a standard connector, such as a CompactFlash or SATA connector. Special hardware may be provided in the storage subsystem and host system for transferring the monitor data over these signal lines, so that the transfers occur with little or no need for host-software intervention. The disclosed design reduces or eliminates the need for host software that uses non-standard or “vendor-specific” commands to retrieve the monitor data.

Abstract: A storage system that comprises multiple solid-state storage devices includes a command set that enables a host system to initiate one or more types of purge operations. The supported purge operations may include an erase operation in which the storage devices are erased, a sanitization operation in which a pattern is written to the storage devices, and/or a destroy operation in which the storage devices are physically damaged via application of a high voltage. The command set preferably enables the host system to specify how many of the storage devices are to be purged at a time during a purge operation. The host system can thereby control the amount of time, and the current level, needed to complete the purge operation. In some embodiments, the number of storage devices that are purged at a time may additionally or alternatively be selectable by a controller of the storage system.