Apparatus and method for generating descriptors to reaccess a non-volatile semiconductor memory of a storage drive due to an error

A storage drive including a first module and a second module. The first module is configured to, based on an instruction signal of a first descriptor, transfer a block of data to or from a non-volatile semiconductor memory in the storage drive. The second module is configured to: monitor a status of the transfer of the block of data; determine whether an error exists with respect to the transfer of the block of data; and independent of communication with a host device, initiate generation of a second descriptor if the error exists. The second module is configured to, according to the second descriptor, perform a reaccess event including reaccessing the non-volatile semiconductor memory to again transfer the block of data to or from the non-volatile semiconductor memory.

FIELD

The present disclosure relates to non-volatile semiconductor memory access systems, and more particularly to data transfer control systems for non-volatile semiconductor memory.

FIELD

The present disclosure relates to non-volatile semiconductor memory access systems, and more particularly to data transfer control systems for non-volatile semiconductor memory.

BACKGROUND

A non-volatile semiconductor memory (NVSM) drive (e.g., a flash drive) includes NVSM and operates based on a size of a page of data. For example, data transferred to and from the NVSM is grouped into data sets. Each of the data sets has a length equal to the length of one or more pages of data. A page of data may have a length of, for example, 8 kilobytes (KB).

A NVSM drive can include, for example, an NVSM interface, a buffer managing module, an error correction code (ECC) module, an interface management module and a NVSM control module. The NVSM interface can communicate with a host. Data is transferred between the NVSM interface and the host. The buffer managing module receives data from the host prior to being stored in the NVSM and receives data from the NVSM prior to being transferred to the host. The ECC module encodes data provided to the NVSM and decodes data received from the NVSM. The interface management module controls data transfers between the ECC module and the NVSM.

The NVSM control module executes firmware to generate descriptors in response to access request signals received from the host. The descriptors may indicate, for example, whether a read operation or a program (i.e. write) operation is to be performed, the amount of data to be transferred, and the addresses to access in the NVSM. The ECC module and the interface management module are operated based on the descriptors.

The interface control module communicates with the NVSM via multiple channels (e.g., 8 channels per NVSM chip) and includes a first-in-first-out (FIFO) register for each of the channels. The FIFO registers are accessed sequentially during read and program operations. The size of each of the FIFO registers is equal to the size of one or more pages of data.

During a program operation, the ECC module can transfer data in a page-based format to the interface control module prior to being stored in the NVSM. The ECC module may transfer one or more pages (M pages) of data to each of the FIFO registers, where M is an integer greater than or equal to 1. The number of pages the ECC module transfers to each of the FIFO registers is dependent on the page format of that NVSM drive. For each set of M pages transferred a single descriptor can be generated.

For example, if the ECC module is operating in an NVSM drive with a single page format, 1 page of data is transferred to each of the FIFO registers. In this example, the size of each of the FIFO registers is equal to the size of 1 page of data. If the ECC module is operating in an NVSM drive with a dual page format, then 2 pages of data are transferred to each of the FIFO registers and the size of each of the FIFO registers is equal to the size of 2 pages of data. The M pages of data are transferred to a current FIFO register prior to transferring data to a next (or subsequent) FIFO register. The above-described data transfers are performed in reverse for a read operation.

Because data is not transferred to a next FIFO register until a current FIFO register receives the M pages of data, data transfer delays can result. These delays may be experienced at one or more of the FIFO registers and can increase with higher order page formats. The order of a page format refers to the number of pages transferred during a single data transfer event. A data transfer event refers to transferring data to or from one of the channels of the NVSM. For example, in a NVSM drive with a 2-page format, if a “bottleneck” arises at a first FIFO register due to speed differences between the ECC module and a first channel, delays can arise at the first FIFO register and at all subsequent FIFO registers. Since two pages of data are transferred to a single FIFO register, a second page of data can be delayed when a first page of data is delayed. Also, delays in transferring the second page of data to the first FIFO register delays transfers of data to FIFO registers subsequent to the first FIFO register.

In addition, data errors can occur during reading of data from the NVSM. A data error can occur, for example, due to use of an inaccurate voltage reference in the NVSM. State of memory cells in the NVSM are distinguishable based on voltage references. If the voltage references become inaccurate over time, interpretation of detected voltages corresponding to states of the memory cells can be inaccurate and as a result can cause data errors. To correct the data errors, the NVSM control module can execute firmware to generate descriptors to reread the memory cells having the corresponding data errors.

SUMMARY

A storage drive is provided and includes a first module and a second module. The first module is configured to, based on an instruction signal of a first descriptor, transfer a block of data to or from a non-volatile semiconductor memory in the storage drive. The second module is configured to: monitor a status of the transfer of the block of data; determine whether an error exists with respect to the transfer of the block of data; and independent of communication with a host device, initiate generation of a second descriptor if the error exists. The second module is configured to, according to the second descriptor, perform a reaccess event including reaccessing the non-volatile semiconductor memory to again transfer the block of data to or from the non-volatile semiconductor memory.

In other features, the storage drive further includes a third module and a fourth module. The third module is configured to, according to the first descriptor, generate a third descriptor to transfer the block of data between the first module and the non-volatile semiconductor memory. The fourth module is configured to generate the instruction signal in response to the second descriptor. The second module is configured to, based on execution of the third descriptor by the first module, monitor the status of the transfer of the block of data, determine whether the error exists with respect to the transfer of the block of data, and initiate the generation of the second descriptor if the error exists.

In other features, the third module is configured to: access a template; update fields in the template based on parameters in the first descriptor; and generate the second descriptor or the third descriptor according to the template.

In other features, the second module is configured to trigger the third module to generate reaccess descriptors corresponding respectively to multiple reaccess events for the block of data. The reaccess descriptors includes the second descriptor. The third module is configured to: access a template for each of the reaccess events, where each of the templates includes fields; update the fields in the templates based on the first descriptor; and generate the reaccess descriptors according to the templates.

In other features, the storage drive further includes a third module and a fourth module. The third module is configured to process data transferred between the first module and the non-volatile semiconductor memory and generate an indication signal if the error exists. The second module is configured to, based on the indication signal, generate a trigger signal to trigger the generation of the second descriptor. The fourth module is configured to generate the second descriptor based on the trigger signal.

In other features, the storage drive further includes a third module configured to set a maximum number of reaccess events for the block of data. The second module is configured to track a number of reaccess events performed for the block of data, trigger generation of reaccess descriptors corresponding respectively to the reaccess events performed for the block of data, and cease generation of reaccess descriptors if the number of reaccess events is equal to or greater than the maximum number of reaccess events. One of the reaccess descriptors generated for the reaccess events is the second descriptor.

In other features, a method is provided and includes: based on an instruction signal of a first descriptor, transferring a block of data to or from a non-volatile semiconductor memory in a storage drive; monitoring a status of the transfer of the block of data; determining whether an error exists with respect to the transfer of the block of data; and initiating generation of a second descriptor if the error exists. The method further includes, according to the second descriptor, performing a reaccess event including reaccessing the non-volatile semiconductor memory to again transfer the block of data to or from the non-volatile semiconductor memory.

In other features, the method further includes according to the first descriptor, generating a third descriptor to transfer the block of data to or from the non-volatile semiconductor memory. The instruction signal is generated in response to the second descriptor. Based on execution of the third descriptor, the status of the transfer of the block of data is monitored. The determination of whether the error exists with respect to the transfer of the block of data is performed. The generation of the second descriptor is initiated if the error exists.

In other features, the method further includes: accessing a template; updating fields in the template based on parameters in the first descriptor; and generating the second descriptor or the third descriptor according to the template.

In other features, the method further includes: triggering generation of reaccess descriptors corresponding respectively to reaccess events for the block of data, where the reaccess descriptors includes the second descriptor; accessing a template for each of the reaccess events, where each of the templates includes fields; updating the fields in the templates based on the first descriptor; and generating the reaccess descriptors according to the templates.

In other features, the method further includes: processing data transferred to or from the non-volatile semiconductor memory; generating an indication signal if the error exists; based on the indication signal, generating a trigger signal to trigger the generation of the second descriptor; and generating the second descriptor based on the trigger signal.

In other features, the method further includes: setting a maximum number of reaccess events for the block of data; tracking a number of reaccess events performed for the block of data; triggering generation of reaccess descriptors corresponding respectively to the reaccess events performed for the block of data, where one of the reaccess descriptors generated for the reaccess events is the second descriptor; and ceasing generation of reaccess descriptors if the number of reaccess events is equal to or greater than the maximum number of reaccess events.

In other features, the method further includes reporting: a pass for the block of data if the error no longer exists as a result of one of the reaccess events performed for the block of data clearing the error; and a pass or a failure for the block of data if the number of reaccess events performed for the block of data is equal to or greater than the maximum number of reaccess events.

DESCRIPTION

A NVSM control module can execute firmware to generate descriptors to read data from or write data to a NVSM. The NVSM control module can also generate descriptors to reaccess memory cells of the NVSM when data errors occur. The generating of descriptors to read, write and reaccess memory cells of the NVSM can require a large amount of firmware overhead and can utilize significant bandwidth and/or processing time of the NVSM control module. To reduce firmware overhead, bandwidth, and processing time associated with generating descriptors, examples are disclosed below that include generating descriptors via a reaccess module and/or hardware, which are separate from a NVSM control module. The reaccess module and/or hardware may include an electronic circuit or other suitable hardware for generating descriptors as described below. Although the following examples are primarily described as utilizing hardware for these purposes, the examples may include logic devices and/or a processor, which may execute additional firmware for descriptor generation. The reaccess module and/or hardware can generate descriptors to reaccess the NVSM without NVSM control module intervention.

In the following description, the term “non-volatile semiconductor memory (NVSM)” may refer to phase change memory (PCM), electrically erasable programmable read-only memory (EEPROM), read only memory (ROM) and/or random access memory (RAM). A couple of examples of EEPROM are NAND flash memory and NOR flash memory.

Also, in the following description the term “host” may refer to a device that transfers data to and/or accesses data from a NVSM drive. A NVSM drive may be a flash drive, a universal serial bus (USB) drive, a solid-state memory drive, etc.

As a few examples, a host may refer to a computer, a camera, a handheld device, a portable device, a cellular phone, a printer, a personal data assistant, an electronic note pad, a television, a display, an appliance, a monitoring system, etc. Examples of computers are a desktop computer, a laptop computer, an electronic note pad, etc. Examples of appliances are a washer, a dryer, a refrigerator, etc. A NVSM drive includes NVSM and may not include a rotating magnetic storage medium, such as a hard disk drive platter. Examples of monitoring systems include burglar monitors, smoke detection systems, baby monitors, etc.

In addition, various system elements, such as modules, network devices, and circuit components are disclosed herein. Examples of arrangements of the system elements are disclosed and include adjacent elements and non-adjacent elements. The adjacent elements are shown as being directly connected to each other. The non-adjacent elements are shown as being indirectly connected to each other.

FIG. 1shows a non-volatile semiconductor memory (NVSM) storage system10. The NVSM system10includes a reaccess module11, which is configured to generate descriptors to reaccess NVSM12as a result of errors that occur during access of the NVSM12. Generation of the descriptors and operation of the NVSM system10are further described below.

The NVSM storage system10includes a host13(or host side) and a NVSM drive14(or NVSM side). The host13includes a host control module16and a host interface18. The NVSM drive14communicates with the host13via a NVSM drive interface20. The NVSM drive14includes the NVSM drive interface20, a receive path22, a transmit path24, an interface management control system26and a NVSM12. The NVSM drive interface20communicates with the host interface18. The receive and transmit paths22,24transfer data between the NVSM drive interface20and the NVSM12. The interface management control system26includes a NVSM control module27. The NVSM control module27controls data transfers to and from the NVSM12.

The interface management control system26operates based on predetermined, selected, and/or determined size(s) of allocation blocks of data (or allocation units (AUs)). This is unlike traditional NVSM drives that operate based on a single fixed block size. In a traditional NVSM, the single block size is equal to the size of a page of data.

In the present disclosure, an allocation block of data refers to an amount of data (or size boundary) set by the NVSM drive14and used to transfer data between devices and/or modules of the NVSM drive14. Each data transfer event to and from the NVSM12includes one or more allocation blocks of data. The data transfer events may be program events or read events. The sizes of the allocation blocks may be the same or different: for different read events; for different program events; and/or between read events and program events. The sizes of the allocation blocks may be determined, set and/or adjusted by the NVSM control module27. Allocation blocks, allocation block sizes and the transfer of allocation blocks are further described below.

The host control module16transmits and receives host data to and from the NVSM drive14via the host interface18. This may include access events such as read, write (or program), and/or erase access events. The host13may generate HDSs based on a received data object and/or request host data sectors (HDSs) from the NVSM drive14. A HDS may be the smallest length data element that is transmitted from the host13to the NVSM drive14. The HDSs are transmitted between respective ports of the interfaces18,20. The interfaces18,20may be, for example, serial advanced technology attachment (SATA) interfaces, small computer system interfaces (SCSIs), serial-attached SCSIs (SASs), fiber channel interfaces, universal serial bus (USB) interfaces, etc.

The host control module16may also generate access request signals30, such as data program signals, data read signals, data erase signals, etc. The access request signals30may be received by a NVSM control module27and/or by other modules of the NVSM drive14via the NVSM drive interface20. The NVSM control module27controls access to the NVSM12based on the access request signals30. The NVSM drive14receives the HDSs via the NVSM drive interface20. The NVSM control module27may access and/or request drive data sectors (DDSs) from the NVSM12based on the access request signals30.

The receive path22includes a compression module40, an encryption module42, a buffer managing module44, a drive data sector (DDS) generating module46, an error correction code (ECC) module48, an interface management module50and the NVSM12. The transmit path24includes the NVSM12, the interface management module50, the ECC module48, a HDS generating module52, the buffer managing module44, a decryption module54and a decompression module56. The buffer managing module44and the DDS and HDS generating modules46,52may be combined to form a single module. The interface management control system26includes the NVSM control module27, a command management module60, the ECC module48, and the interface management module50. Modules of the NVSM drive14may be referred to as a NVSM storage system and may be combined into one or more modules.

The NVSM drive interface20may receive a single data stream or multiple concurrent parallel data streams from the host interface18. The data streams may be transferred to the compression module40. Multiple concurrent parallel data streams may be received when the host and NVSM interfaces18,20are, for example, SAS interfaces.

The compression module40compresses HDSs received from the host interface18when possible and prior to being received by the buffer managing module44. The compression is performed on HDSs that are the same length as the HDSs received from the host interface18. The compression module40may use lossy and/or lossless compression methods. Lossy compression and decompression provides data that is close but not the same as the original data after compression and decompression. Lossless compression and decompression provides reconstruction of the same data as the original subsequent to compression and decompression. Lossless data compression includes detecting repeating bit patterns and removing the redundancy.

The compression module40compresses host data sectors (HDSs) received from the host13when possible. The HDSs may be uncompressed, partially compressed, and/or fully compressed when received. An HDS may be the smallest length data element that is transmitted from the host13to the NVSM drive14. Certain HDSs may not be compressible, for example, when lossless compression is used and a corresponding data pattern does not include redundancy.

The encryption module42encrypts the compressed HDSs. The encryption module42encrypts data received from the compression module40. The encryption may include one or more public and private keys. The encryption may also include one or more keys that are specific to the NVSM drive14or a component of the NVSM drive14, such as a key specific to the NVSM control module27and/or the NVSM12.

The buffer managing module44stores the HDSs in a buffer70and forwards the HDSs to the DDS generating module46. The buffer70may include volatile memory, such as RAM, dynamic RAM (DRAM), and/or static RAM (SRAM). The buffer managing module44may collect and store one or more HDSs prior to storage in the NVSM12.

The buffer managing module44may: convert received DDSs from the encryption module42to HDSs when possible; receive HDSs from a component downstream from the buffer managing module44(between the buffer managing module44and the NVSM12); and/or transfer HDSs to the decompression module56. Each of the DDSs may be larger than or equal to the size of the HDSs. Decompressed HDSs are transmitted to the host13. The buffer managing module44may combine and store the compressed and/or encrypted HDSs in a predetermined order regardless of the order in which the HDSs are received.

For example, HDSs may be received in a numerical order or may be received in a different order. Sequentially received HDSs may be stored in different HDS registers72to allow for reordering of the HDSs in a numerical or predetermined order. Thus, HDS registers72may be used to provide HDS sets74for respective DDSs (HDS registers1-N and HDS sets1-N are shown). As a HDS register is filled and/or a predetermined DDS length limit is met, an HDS set may be released from the buffer managing module44and passed to the DDS generating module46. A predetermined DDS length limit is met, for example, when no further HDSs can be and/or are to be combined with other HDSs of a current DDS.

The DDS generating module46generates DDSs based on the combined and/or stored HDS(s) in the HDS registers72and based on HDS and DDS information. The DDS generating module46converts the HDSs to DDSs prior to storage in the NVSM12. The HDS and DDS information may be received from the buffer managing module44. The HDS and DDS information may include the HDS information bits and DDS information, such as DDS length, DDS bit slot availability, etc.

The DDS generating module46may generate each DDS to have the same bit length. Nuisance data refers to data that is added to one or more HDSs such that a generated DDS is of a predetermined bit length. Compressed HDSs may have different bit lengths. Different amounts of nuisance data is added to combine compressed HDSs to generate DDSs of equal length. The NVSM control module27prevents an HDS from being split between two DDSs by adding the nuisance data. Instead of storing portions of a HDS with two or more other HDSs, nuisance data is attached. The nuisance data may include, for example, all 0's, all 1's, null states, and/or redundant data to minimize programming and/or processing of the NVSM control module27.

The ECC module48and the interface management module50may operate based on parameter signals from the command management module60. The command management module60generates a first parameter signal80and a second parameter signal82based on commands and/or job descriptors84received from the NVSM control module27and/or a descriptor generating module103.

During a data transfer event, the NVSM control module27or one of the other modules of the NVSM drive14receives the access request signals30. The NVSM control module27may be implemented as a system-on-chip (SoC) and include or access a first non-volatile memory90. The first non-volatile memory90stores firmware (FW)92executed by the NVSM control module27. In executing the firmware92, the NVSM control module27generates the descriptors84(referred to below as FW descriptors) based on the access request signals30. The descriptors84are stored in a second non-volatile memory94and/or provided to the descriptor generating module103. The second non-volatile memory94may be part of the command management module60or separate from the command management module60, as shown. The second non-volatile memory94may store the descriptors84and/or descriptors95generated by the descriptor generating module103. Descriptors generated using firmware, such as those generated by the NVSM control module27, are referred to as firmware descriptors. Descriptors generated using hardware, such as those generated by the descriptor generating module103, are referred to as hardware descriptors. The second non-volatile memory94may also store parameter information96for interpreting the descriptors84,95to determine parameters and generate the parameter signals80,82, as described below.

In generating the descriptors84, the NVSM control module27may determine: a size of an allocation block of data based on the access request signals, tables relating sizes of blocks of data to other parameters, an application of use, etc. A size of an allocation block of data may be referred to as an allocation unit (AU) size or an allocation block size. An application of use may indicate, for example, a type of host, a type of NVSM drive, and speeds of the host and the NVSM drive. The NVSM control module27generates the descriptors84to indicate the allocation block sizes. The descriptors84may each include: the allocation block sizes; buffer register locations; NVSM addresses; NVSM channel identifiers (IDs); NVSM device identifiers (e.g., memory chip IDs); data formats; amounts of data to transfer; type of operation bits (e.g., read, program, and/or erase bits); etc. Generation of the hardware descriptors95is described below.

Each of the allocation block sizes may be page based, sub-page based, or non-page based. An allocation block size is page based when the allocation block size is equal to the size of one or more pages of data. As an example a single page of data may be equal to 8 kilobytes (KB). Other example page sizes are 4 KB, 16 KB, and 32 KB. An allocation block size is sub-page based when the size of two or more allocation blocks of data is equal to the size of 1 page of data. An allocation block size is non-page based when the allocation block size is not an integer multiple of 1 page and an integer multiple of the allocation block size is not equal to the size of 1 page of data. An allocation block may include any amount of data.

Allocation blocks of data may be transferred to and from channels100of the NVSM12. A transfer of one or more allocation blocks of data (“blocks of data”) may be referred to as a data transfer event. Data transfer events may also occur, for example, between devices in series with and/or communicating with the channels. Example data transfer events between example devices and/or modules are shown inFIGS. 2-5.

The command management module60may determine: allocation block sizes, an ECC correction power (number of bit errors per data block corrected); buffer register locations; NVSM addresses; data formats; amounts of data to transfer; redundant array of independent disks (RAID) operations; read, program, and/or erase bits; etc. based on the descriptors84. The command management module60executes the descriptors84,95and/or generates the first and second parameter signals80,82based on the descriptors84,95.

The first parameter signal80may include: an ECC correction power bit; buffer register location bits; NVSM address bits; data format bits; amount of data to transfer bits; a number of blocks of data to transfer bits; redundant array of independent disks (RAID) operation bits; read, program, and/or erase bits; etc. The second parameter signal82may include: NVSM address bits; allocation block size bits; a number of blocks of data to transfer bits; read, program, and/or erase bits; etc.

The ECC module48performs error correction and encodes and decodes the DDSs and data received from the NVSM12. The ECC module48transfers DDSs to and receives DDSs from the interface management module50based on the first parameter signal80. The interface management module50accesses the NVSM12based on the second parameter signal82. The interface management module50transmits instruction signals102to the NVSM12to control access to the NVSM12. The NVSM12transmits data signals to the interface management module50and/or receives data signals from the interface management module50via the channels100based on and/or according to the instruction signals102. The instruction signals may include commands for reading data from and/or writing data to the NVSM12. The instruction signals are used to signal the NVSM12that; a read operation or a program operation is to be performed; the amount of data and/or the number of allocation blocks being transferred; the addresses of the allocation blocks; etc.

For each descriptor, one or more sets of instructions may be generated. The descriptors may be page descriptors or allocation block descriptors. A page descriptor refers to a descriptor used to trigger and/or transfer one or more pages of data. An allocation block descriptor refers to a descriptor used to trigger and/or transfer one or more allocation blocks of data. The page descriptors and the allocation block descriptors may be trigger descriptors, read descriptors, or program descriptors. The trigger descriptors are used to initialize a data transfer event (read or program event). As an example, the trigger descriptors may identify a command type (read or program), target addresses within the NVSM12and/or buffer managing module44, and how much data is to be transferred (e.g., number of pages and/or number of allocation blocks).

The read descriptors are used to read data from the NVSM12. The program descriptors are used to program data to the NVSM12. As an example, the read descriptors and the program descriptors may identify how much data is to be transferred and the locations of the data within a page of data. A descriptor may be both a trigger descriptor and a read descriptor. A descriptor may alternatively be both a trigger descriptor and a program descriptor.

The ECC module48and/or other ECC modules may be connected: between the compression module40and the encryption module42to encode compressed HDSs; between the encryption module42and the buffer managing module44to encode encrypted HDSs; between the buffer managing module44and the DDS generating module46; and/or between the DDS generating module46and the NVSM12as shown. The DDSs are then stored in the NVSM12.

The ECC module48may use one or more ECC methods to prevent errors when writing data to and reading data from the NVSM12. Parity bits may be generated and added to the DDSs prior to being stored in the NVSM12and/or may be stored separate from the DDSs in the NVSM12.

The interface management module50may store the DDSs at physical block addresses (PBAs) in the NVSM12. The PBAs of the DDSs may be stored in one or more locations and acquired by the interface management module50when accessing storage locations of the DDSs in the NVSM12. For example, the PBAs may be stored in the first non-volatile memory90and/or in the NVSM12. The first non-volatile memory90or the NVSM12may store a mapping table104of the PBAs, which may be based on an allocation block size. As an example, PBA(s) associated with an allocation block may be identified in the mapping table104. This is different than storing the PBAs based on a size of a page of data. The allocation block size may be set based on or independent of a size of a page of data. Since the firmware92stores the PBAs based on allocation block size, a change in allocation block size does not require a change in firmware instructions, but rather simply an allocation block size setting adjustment. The mapping table104may relate logical block addresses (LBAs) to PBAs. The mapping table104may be accessed by any of the modules in the paths22,24. The mapping table104may be stored in and/or shared with the descriptor generating module103.

The interface management module50may access DDSs in the NVSM12prior to forwarding the DDSs to the ECC module48. The ECC module48may decode DDSs accessed from the NVSM12based on access command signals and/or parity information associated with the DDSs. The access command signals may be generated by the NVSM control module27and/or the command management module60and include the first parameter signal80. The access command signals may include one or more PBAs. The access command signals may be generated by the NVSM control module27and based on LBAs and/or access request signals received from the host13. The HDS generating module52accesses or receives the DDSs from the ECC module48based on data request signals received, for example, from the buffer managing module44.

The HDS generating module52and/or the buffer managing module44separate the received DDSs into HDSs. The HDS generating module52generates one or more HDSs based on decrypted DDSs received from the ECC module48. The HDS generating module52generates the HDSs based on the HDS identification information and/or a data request signal. The data request signal may include one or more LBAs. The decryption module54decrypts decoded DDSs from the ECC module48. The keys used by the encryption module42may be shared, accessed and/or generated by the decryption module54.

Although the modules of the paths22,24are shown in a particular order, they may be rearranged in a different order. For example, the encryption module42may be located upstream from the compression module40. In other words, the encryption module42may be connected between the NVSM drive interface20and the compression module40. As another example, the decryption module54may be connected between the NVSM drive interface20and the decompression module56.

HW Descriptor Generation

The interface management control system26includes the NVSM control module27and a descriptor generating module103. The NVSM control module27may operate according to firmware92stored in the memory90of the NVSM control module27. The descriptor generating module103is included to reduce firmware overhead for generating descriptors via firmware. The descriptor generating module103may include an electronic circuit and/or other suitable hardware for generating descriptors as described herein. Although the following examples refer to the descriptor generating module103as including hardware, the descriptor generating module103may include logic devices and/or a processor, which may execute firmware for descriptor generation. Firmware executed by the descriptor generating module103may be separate from and different than the firmware92executed by the NVSM control module27. The descriptor generating module103and the reaccess module11may be implemented as the same electronic circuit.

The descriptor generating module103may be triggered to generate descriptors (e.g., hardware descriptors) by the NVSM control module27. The NVSM control module27generates the firmware (or first) descriptors84and forwards the firmware descriptors84to the memory94. The NVSM control module27may generate a descriptor command signal to generate hardware descriptors and forward the descriptor command signal to the descriptor generating module103. The descriptor command signals may be stored in a first-in-first-out (FIFO) memory104in the descriptor generating module103. The descriptor command signals may include input parameters based on which the descriptor generating module103generates the second descriptors (e.g., hardware descriptors)95. The memory94may include a FIFO memory allocated to storing the descriptors84,95.

The descriptor generating module103may then report to the NVSM control module27, via an advanced microcontroller bus (AHB)105, that the second descriptors are generated and stored in the memory94. The generation of the second descriptors may be reported via a completion status flag generated by the descriptor generating module103and/or accessed by the NVSM control module27may detect the generation of the completion status flag by accessing the completion status flag in the memory94. As another example, the completion of generating the second descriptors may be indicated via an interrupt generated by the descriptor generating module103and sent to the NVSM control module27. Generation of the second descriptors by the descriptor generating module103reduces the amount of processing time of the NVSM control module27associated with the generation of descriptors. This allows the NVSM control module27to perform other tasks.

The NVSM control module27executes the firmware92to implement firmware-to-hardware and/or single-to-multiple descriptor operations disclosed below. As an example, the firmware92generates the firmware descriptors84, which may each be converted to one or more other descriptors (e.g., hardware descriptors) by the descriptor generating module103.

The command management module60communicates with the descriptor generating module103and may receive and/or execute descriptors (e.g., hardware descriptors) received from the descriptor generating module103. The command management module60is in communication with the memory94via, for example, an advanced extensible interface (AXI) bus112. The command management module60may be referred to as a sequencer as the command management module60may sequentially execute a sequence of descriptors generated by the descriptor generating module103. The memory94may store the parameter information96, the descriptors84, and templates106. The descriptors84may include firmware and/or hardware descriptors. The firmware descriptors may be received from the NVSM control module27and/or from the descriptor generating module103. The hardware descriptors may be received from the descriptor generating module103. The templates106may be used to generate the second descriptors95, which may include descriptors generated in response to the first descriptors84and descriptors generated for reaccess events (e.g., reread events or rewrite events).

Hardware descriptor generation is further described with respect toFIGS. 4-14below.

The interface management control system26and corresponding firmware and hardware are used to reaccess the NVSM12based on whether certain conditions exist. The firmware (e.g., firmware92) may be used to initiate generation of reaccess descriptors and/or control generation of reaccess descriptors. A reaccess descriptor refers to a hardware descriptor that is associated with a reaccess event. The firmware may provide parameters such as size of data to be transferred and start and end addresses for read or write events. These parameters are stored in hardware registers108in the memory94. The firmware92may be used to define the conditions in response to which a reaccess event is to be performed. These conditions may be set, controlled and/or monitored by the NVSM control module27based on the firmware92. The conditions may include: detection of one or more data errors (e.g., read errors or write errors); detection of an uncorrectable error; and/or detection of a media circulant redundant check (MCRC) error. Another example condition includes determining whether a predetermined and/or maximum number of reaccess events for the same one or more memory cells has been performed. These conditions and/or corresponding parameters may be stored in the memory94. The parameters may further include a number of reaccess attempts for each reaccessed address. The conditions and/or parameters may be stored in the hardware registers108.

The NVSM control module27, based on the firmware92, may also control whether a hard decision reread mode or a multi-bit reread mode is to be performed. The hard decision reread mode includes sensing a voltage or value of a memory cell one time per access or reaccess event. The multi-bit reread mode includes sensing a voltage or value of a memory cell multiple times per access event. Rereading a value multiple times increases the probability that the ECC module48is able to properly determine a data bit value and/or correct a data bit value.

The interface management control system26includes the reaccess module11and a linklist module107. The reaccess module11is included to reduce firmware overhead associated with reaccessing the NVSM12due to errors (e.g., read errors or write errors). The reaccess module11may include an electronic circuit and/or other suitable hardware for triggering generation of hardware descriptors to reaccess the NVSM12. The reaccess module11monitors statuses of allocation blocks and if there are errors, triggers the descriptor generating module103to generate hardware descriptors to reaccess the NVSM12. The reaccess module11may trigger generation of the hardware descriptors, for one or more reaccess events for the same one or more allocation blocks, independent of and/or without intervention by the NVSM control module27. Although the following examples refer to the reaccess module11as including hardware, the reaccess module11may include logic devices and/or a processor, which may execute firmware for triggering descriptor generation. Firmware executed by the reaccess module11may be separate from and different than the firmware92executed by the NVSM control module27.

The linklist module107generates linklists, which include addresses of the buffer70identifying where to store and/or access data received from and/or transferred to the NVSM12. The linklists may be used by the ECC module48to transfer allocation blocks between the buffer70and the NVSM12.

The interface management control system26including the modules11,27,48,50,60,103,107operate to trigger, control and perform reaccess events. This includes the NVSM control module27executing the firmware92to: set a maximum number of reaccess events (e.g., 4), schedule reaccess data flows, control Vref adjustments during reaccess events, and control different types of decoding. A Vref adjustment may be performed for each reaccess event. If more than one reaccess event is performed for the same address, memory cell, and/or group of addresses and/or memory cells, then multiple Vref adjustments may be performed. As an example, a different Vref adjustment may be performed for each successive reaccess event. The different types of decoding may include hard decision decoding, 2-bit LDPC decoding and/or other suitable types of decoding. The types of decoding may be set by the NVSM control module27and may be performed by the ECC module48. Operations of the modules11,27,48,50,60,103,107pertaining to reaccess events are further described below with respect to the method ofFIG. 15. The modules11,27,48,50,60,103and107may be implemented as a single module. The modules11,48,50,60,103and107may be implemented as hardware and/or as a single electronic circuit separate from the module27.

FIG. 2shows a portion120of the interface management control system26including the ECC module48, the interface management module50, and the NVSM12. The ECC module48includes an encoder122and a decoder124. The encoder122encodes DDSs and forwards the encoded DDSs in the form of allocation blocks of data to the interface management module50. The encoder122may combine an integer multiple of DDSs to form an allocation block of data. The decoder124decodes allocation blocks of data from the interface management module50to generate DDSs.

The interface management module50includes, for the example shown, a first series of FIFO registers126and a second series of FIFO registers128. The first series of FIFO registers126are associated with program events and are used to buffer data transferred from the ECC module48to the NVSM12. The second series of FIFO registers128are associated with read events and are used to buffer data transferred from the NVSM12to the ECC module48. Although a FIFO register series is shown for each of the encoder122and decoder124, the interface management module50may include a single series of FIFO registers, which are shared by the encoder122and the decoder124. The first and second FIFO registers126,128may include, for example, SRAM or other suitable memory devices.

The size of each of the FIFO registers126,128may be greater than or equal to an allocation block size set by the NVSM control module27. The size of each of the FIFO registers126,128may be greater than, equal to, or less than the size of a page of data, as the allocation block size may be greater than, equal to, or less than the size of a page of data. An example of FIFO registers sized equal to a size of a page of data is shown inFIG. 7. An example of FIFO registers sized less than a size of a page of data is shown inFIG. 14.

The interface management module50communicates with the NVSM12over the channels1001-N. Each of the FIFO registers126,128is associated with a respective one of the channels1001-N. The FIFO registers126,128temporarily store data prior to being stored in the NVSM12and/or prior to being transferred to the buffer managing module44(shown inFIG. 1). The NVSM12may include buffers130for each of the channels1001-N. The FIFO registers126,128and/or the buffers130may be used to balance different bandwidths (or speeds) between the encoder122and the NVSM12and/or between the decoder124and the NVSM12.

The bandwidth of the ECC module48may be different than the bandwidth of the NVSM12. The speeds of the encoder122and the decoder124may be faster than the speeds of each of the channels1001-N. For example, the speeds of each of the encoder122and the decoder124may be 8-16 times faster than the speed of each of the channels1001-N. Speed differences may also result due to, for example, data flow “bottlenecks” or delays in one or more of the channels1001-N, which may be due to operations of the interface management module50and NVSM12. The FIFO registers126,128and the buffers130aid in balancing out the speed differences. The speed of the encoder122may be set to maintain operation of the channels1001-Nat peak operating speeds. The speed of the decoder124may be set to prevent filling of the second set of FIFO registers128and maintain output of the channels1001-Nat the peak operating speeds.

InFIG. 3, a portion210of an interface management control system is shown illustrating multi-page program events with page-sized transfers. The portion210may be incorporated into the interface management control system26ofFIG. 1. Each transfer may fill one of the FIFO registers126of the interface management module50. Each page of data transferred may have two associated page descriptors.

Each of the FIFO registers126is connected to a respective one of Channels0-7of the NVSM12. Channels0-7may be included in the channels100ofFIG. 1. Although the FIFO registers126may each be sized to store more than 1 page of data, the FIFO registers126are each shown as being able to store 1 page of data. If a multi-page (M-page) transfer is performed (as described above), the FIFO registers126do not need to be sized to store M pages of data, as one or more page descriptors are used per page of data transferred. Sizing the FIFO registers126to store a single page of data rather than two or more pages of data reduces memory allocated for the FIFO registers126and decreases data transfer times. If only a single descriptor was used to transfer the M pages of data, each of the FIFO registers126would need to be sized to equal the amount of data in a page of data, because each descriptor is associated with a single channel and/or a single FIFO register.

In a multi-page transfer event, data that is provided to the interface management module50is spread across multiple channels page-by-page. Pages of data Data1-16are shown. A single page is transferred to each of the Channels0-7prior to sending a second page to any of the Channels0-7. The pages of data are transferred from the FIFO registers126to the Channels0-7based on speeds of the Channels0-7and/or devices internal to the NVSM12. As the pages of data are transferred to each of the FIFO registers126, probability of a data bottleneck at any one of the FIFO registers126is reduced. For example, if transfer speed of a first channel (e.g., Channel0) is slow, a bottleneck at a corresponding first FIFO register FIFO1may not occur, as pages of data are loaded into the other FIFO registers FIFO2-8prior to loading another page of data into the first FIFO register FIFO1.

InFIG. 4, a portion330of an interface management control system is shown illustrating an allocation block based program events with allocation block sized transfers. This portion330may be incorporated into the interface management control system26ofFIG. 1. Each allocation block of data transferred may fill one of FIFO registers126′ of the interface management module50. Each allocation block of data transferred may have, for example, two or three associated allocation block descriptors.

Each of the FIFO registers126′ is connected to one of Channels0-7of the NVSM12. Although the FIFO registers126′ may each be sized to store more than 1 allocation block of data, the FIFO registers126′ are each shown as being able to store 1 allocation block of data.

The size of each of the FIFO registers126′ may be based on the size of the allocation blocks of data and may be independent of a size of a page of data. Any number of allocation blocks may be equal to the size of one page of data. Reducing the sizes of the allocation blocks of data and the FIFO registers126′ can further increase data transfer speeds, increase parallel data transfer efficiency, and prevent data bottlenecks.

In a multi-allocation block transfer event, data that is provided to the interface management module50is spread across multiple channels block-by-block. Allocation blocks of data Data1-32are shown. A single allocation block of data is transferred to each of the channels prior to sending a second allocation block to any of the channels. The allocation blocks of data are transferred from the FIFO registers126′ to the channels based on speeds of the channels and/or devices internal to the NVSM12. As the allocation blocks of data are transferred to each of the FIFO registers126′, probability of a data bottleneck at any one of the FIFO registers126is reduced.

FIG. 5shows a portion340of an interface management control system. The portion340may be incorporated into the interface management control system26ofFIG. 1, replace the portion120ofFIG. 2, and includes an ECC module48′, an interface management module50′ and the NVSM12. Unlike the implementation ofFIG. 2, the ECC module48′ includes multiple encoders342and multiple decoders344and the interface management module50′ does not include FIFO registers. Each of the encoders342may transfer data at approximately the same speed as the channels100of the NVSM12.

During a program event, the DDS generating module46may spread allocation blocks of data to the encoders342similar to the spreading of allocation blocks of data to FIFO registers as described with respect toFIG. 2. The implementation ofFIG. 5further decreases the amount of memory used to transfer data to and from the NVSM12by not incorporating FIFO registers in the interface management module50′. As FIFO registers are not incorporated, this implementation can support any page size or allocation block size. This increases development flexibility of the firmware92. This implementation may also increase parallel data transfer efficiency.

Use of FIFO registers with sizes less than the size of a page and/or the elimination of FIFO registers, as described inFIGS. 4-5, minimizes hardware/memory requirements.

The NVSM storage system10and/or the NVSM drive14may be operated using numerous methods, an example allocation block based method is provided by the method ofFIG. 6. InFIG. 6, a method of operating a NVSM storage system and a NVSM drive is shown. Although the following tasks are primarily described with respect to the implementations ofFIGS. 1-15, the tasks may be easily modified to apply to other implementations of the present disclosure. The tasks may be iteratively performed. The method may begin at350.

At352, the NVSM drive interface20receives access request signals from the host interface18requesting that read, program, and/or erase events be performed.

At354, the NVSM control module27generates page and/or allocation block descriptors based on the access request signals. The page and/or allocation block descriptors may be generated to perform one or more data transfer events. Each of the data transfer events may be a read event or a program event and include only one read preparing period or one program preparing period. The number of descriptors generated per data transfer event, page of data transferred, and/or allocation block of data transferred may be determined by the NVSM control module27.

Each of the data transfer events includes two or more descriptors. The number of pages of data and/or the number of allocation blocks of data per transfer event may also be determined by the NVSM control module27and indicated in the generated descriptors. One or more pages of data and/or one or more allocation blocks of data may be transferred per data transfer event. Page sizes may be predetermined and fixed or may be set by the NVSM control module27.

At358, an ECC module (e.g., one of the ECC modules48,48′) and an interface management module (e.g., one of the interface management modules50,50′) determine whether a read event or a program event is to be performed based on the first parameter signal80and the second parameters signal82. Task360is performed when a read event is performed. Task370is performed when a program event is performed.

At360, the interface management module generates the instruction signals102to instruct the NVSM12to transfer blocks of data from the NVSM12to the interface management module via the channels100. The instruction signals102are generated based on the second parameter signal82.

At362, the NVSM12prepares for and transfers the pages of data and/or the allocation blocks of data to one or more of the channels100based on the instruction signals. The pages of data and/or the allocation blocks of data may be received by FIFO registers of the interface management module.

At364, the pages of data and/or the allocation blocks of data are transferred from the interface management module to the ECC module based on the parameter signals80,82. The pages of data and/or the allocation blocks of data may be transferred to one or more decoders of the ECC module, as shown inFIGS. 2-5.

At366, the pages of data and/or the allocation blocks of data are transferred to the NVSM drive interface20via, for example, the HDS generating module52, the buffer managing module44, the decryption module54and the decompression module56. The host13may receive the pages of data and/or the allocation blocks of data from the NVSM drive interface20. Subsequent to performing task366, the method may return to task352or end at380, as shown.

At370, the pages of data and/or the allocation blocks of data are received by the NVSM drive interface20. At371, the pages of data and/or the allocation blocks of data are forwarded to the ECC module via, for example, the compression module40, the encryption module42, the buffer managing module44and the DDS generating module46.

At372, the ECC module may transfer the pages of data and/or the allocation blocks of data to the interface management module based on the first parameter signal80. The pages of data and/or the allocation blocks of data may be transferred from an encoder of the ECC module and spread to one or more FIFO registers of the interface management module, as shown inFIGS. 2-4. As an alternative, the pages of data and/or the allocation blocks of data may be transferred from multiple encoders of the ECC module to the interface management module, as shown inFIG. 5.

At374, the interface management module generates instruction signals102to transfer the pages of data and/or the allocation blocks of data to the NVSM12based on the second parameter signal82.

At376, the NVSM12receives the pages of data and/or the allocation blocks of data via the channels100. Subsequent to performing task376, the method may return to task352or end at380, as shown.

The above-described tasks ofFIG. 6are meant to be illustrative examples; the tasks may be performed sequentially, synchronously, simultaneously, continuously, during overlapping time periods or in a different order depending upon the application. For example, task374may be performed while task376is performed.

Some of the examples described above use multiple descriptors (as defined above) per page and/or multiple descriptors per allocation block transferred to and/or from NVSM. By generating and using multiple descriptors, firmware flexibility is increased over using only a single descriptor per transfer. Other examples are provided below that include generating one descriptor per allocation block. Performing data transfers based on a selected allocation block size allows read and program events to be performed independent of page sizes and allows a NVSM drive to accommodate any page size of a NVSM. Allocation blocks that are smaller than the size of a page are easier for firmware of a NVSM control module to handle, easier to encode and decode, and are easier for a host to handle. Reading allocation blocks from a NVSM as opposed to reading pages of data reduces read latency.

Also, allocation block based transfers allow for FIFO sizes of an interface management module of a NVSM drive to be independent of page sizes. Also, by spreading allocation blocks of data over multiple channels of a NVSM per transfer event improves transfer efficiency. The data may be spread to multiple channels without waiting for an additional block of data to be loaded into a FIFO of a channel, which has already received a block of data. This further decreases transfer latencies.

FIG. 7illustrates generation of a firmware descriptor per allocation unit. A NVSM control module may generate a firmware descriptor per allocation unit, which may then be stored in a memory. As an example four allocation units (or blocks) of data AU1-4are shown. The NVSM control module generates firmware descriptors F/W Desc1-4for the AU1-4to control operation of a NVSM. The firmware descriptors F/W Desc1-4correspond respectively to the allocation units of data AU1-4. The allocation units of data AU1-4are shown collectively as a single block of data420prior to the generation of the firmware descriptors. The allocation units of data AU1-4are shown separately subsequent to the generation of the firmware descriptors. The allocation units of data AU1-4may be separated to allow for parallel transfer of the allocation units of data AU1-4during the same period of time.

FIG. 8illustrates generation of a descriptor (e.g., hardware descriptor) per allocation unit, as described with respect to the embodiments ofFIG. 1. The NVSM control module27may generate a firmware (or first) descriptor422for a single block of data424having a predetermined number of allocation units of data AU1-4. The firmware descriptor422may be stored in the memory94and/or provided to the descriptor generating module103. The descriptor generating module103may generate a second descriptor for each of the allocation units of data AU1-4. The second descriptors may be hardware descriptors and are identified as H/W Desc1-4. The second descriptors are used to control the NVSM12. The amount of data associated with the second descriptors is the same as the amount of data associated with the firmware descriptor422generated by the NVSM control module27. Although a one-to-one relationship is shown between the second descriptors and the allocation units of data AU1-4inFIG. 8, each of the second descriptors may be associated with one or more allocation units of data AU1-4. Conversions from firmware (or first) descriptors to the hardware (or second) descriptors is further described below.

Each of the allocation units of data AU1-4may have any amount of data. The size of the allocation units of data AU1-4may be predetermined, fixed and/or set by the NVSM control module27. The size of the allocation units may be less than, equal to, or greater than the size of a page of data. Each of the second descriptors may be used to control the transfer of one or more pages of data and thus may correspond to a single or multiplane read and/or program (or write) operation. The descriptor generating module103may generate the second descriptors to spread the allocation units of data AU1-4to multiple channels of the NVSM12to maximize parallel transfer of data between the interface management module50and the NVSM12.

The above-described features ofFIGS. 1 and 8allow the NVSM control module27to generate a single firmware descriptor when performing a multiplane (multiple page) transfer of data. This is because the descriptor generating module103converts the single firmware descriptor into multiple descriptors, which are executed by the command management module60. The generation of the descriptors by the descriptor generating module103allows the NVSM control module27to continue to dispatch data to and from the NVSM12in an order recognizable to the NVSM12. The descriptor generating module103may perform address mapping instead of the NVSM control module27. The descriptor generating module103may map, for example logical block addresses for allocation units of data to physical block addresses. The physical block addresses are addresses of memory locations in the NVSM12. The dispatching of data, the generating of descriptors, and the address mapping performed by the descriptor generating module103minimize the amount of calculations performed by the NVSM control module27in performing data transfers.

The memory94may include first-in-first-out (FIFO) registers as shown, for example, inFIG. 2. Each of the FIFO registers may be the same size as an allocation unit. As a result, the sizes of the FIFO registers may be independent of a page size of data. The matching of the sizes of the FIFO registers with the sizes of the allocation units of data, prevents speed mismatching between, for example, the ECC module48ofFIG. 2and the FIFO registers. By transferring amounts of data that are smaller than a page of data, less data is transferred in an out of the FIFO registers per transfer event, which allows for quicker data transfers. This reduces data transfer latencies associated with the FIFO registers. To further reduce transfer latencies, the ECC module48may rotate through the FIFO registers and/or corresponding channels when receiving data from and transferring data to the NVSM12. A block of data may be split up into two or more portions of data during a transfer. For example, a 16 kilobytes (KB) block of data may be divided into two 8 KB portions. The first portion may be transferred to and/or from a first FIFO register while the second portion is transferred to and/or from a second FIFO register.

As stated above, the NVSM storage systems disclosed herein may be operated using numerous methods. Another example method is illustrated inFIG. 9.FIG. 9illustrates a descriptor generating method. Although the tasks ofFIG. 9are primarily described with respect to the examples ofFIGS. 1 and 8, the tasks may be applied to other embodiments of the present disclosure. The tasks of may be iteratively performed.

The method may begin at500. At502, the NVSM control module27receives and/or detects reception of access request signals from the host device13. At504, the NVSM control module27, using the firmware92, generates one or more firmware (first) descriptors based on the access request signals.FIG. 10shows an example of a firmware descriptor505generated by the NVSM control module27. The firmware descriptor505may include 3 control rows (identified as Rows 0-2) and64parameter rows (identified as Rows 3-66). Each of the control rows and parameter rows may have a word of information. Each of the words may be referred to as a descriptor word (or DWORD). Any number of control rows and parameter rows may be included in a firmware descriptor. In the parameter rows, each byte of information may be referred to as an input parameter. Each DWORD in the parameter rows may include 4 bytes of parameters. Since each firmware descriptor may include 64 parameter rows, each firmware descriptor may include 256 parameters.

The control rows of the firmware descriptor include control fields with control information.FIG. 11shows an example of control rows for the firmware descriptor505ofFIG. 10. The first control row Row 0 includes control fields PRMT_ROW_NUM, SRC_LEN and SRC_PTR. The second control row Row 2 includes control fields DF_SEL and DST_PTR. The third control row Row 3 includes control fields SC0-SC9. Reserved fields RSVD may be used for other control information. Descriptions for the control fields PRMT_ROW_NUM, SRC_LEN, SRC_PTR, DF_SEL and DST_PTR, and SC0-SC9 are provided in the below table.

Table of Firmware Descriptor FieldsDescriptor FieldDescriptionSRC_PTRThis field is a descriptor template pointer that indicateslocation of a template. May indicate physical address oftemplate in the memory 94. The descriptor generatingmodule 103 locates templates for descriptors based on thedescriptor template pointer.SRC_LENThis field is indicates a descriptor template length and/or anumber of, for example, descriptors (e.g., hardwaredescriptors) to generate. The descriptor generating module103 uses the SCR-LEN filed to determine the number ofdescriptors to generate for the corresponding templateand/or corresponding firmware descriptor.PRMT_ROW_NUMThis field indicates the number of parameter rows in thecorresponding firmware descriptor.DST_PTRThis field is a pointer indicating a location for storing thedescriptors generated by the descriptor generating module103 in the memory 94. May indicate one or more addressesin the memory 94. The descriptor generating module 103stores the generated descriptors at the addresses indicated bythe DST_PTR.DF_SELThis field is a priority selector field that indicates which type ofFIFO memory or area of memory to put the descriptorsgenerated by the descriptor generating module 103. Thememory 94 may include two or more FIFO registers. As anexample, the memory 94 may include high priority FIFOregisters and low priority FIFO registers. The DF_SEL field mayindicate whether to put the descriptors generated by thedescriptor generating module 103 in a high priority FIFOregister or a low priority FIFO register. The descriptors in highpriority FIFO registers may be executed by the commandmanagement module 60 prior to the descriptors in the lowpriority FIFO registers. The descriptors in high priority FIFOregisters may be executed quicker than the descriptors in thelow priority FIFO registers.SC0This control field indicates a channel and a device to send userdata or other data associated with one or more descriptorsgenerated by the descriptor generating module 103.Examples of channels are shown in FIG. 3. The device refersto a NVSM chip. For example, the NVSM 12 may includemultiple NVSM and/or NAND chips.SC1This control field is used for RAID control and may include acommand RAID_CMD and an identifier RAID_ID. This controlfield may be used by the descriptor generating module 103 togenerate read stripes.SC2This control field is used for streaming control of databetween a buffer managing module (e.g., the buffer managingmodule 44 of FIG. 1) and NVSM 12. This field may indicatewhether to stream and/or transfer data from the buffermanaging module to the NVSM 12 or to stream and/ortransfer data from the NVSM 12 to the buffer managingmodule. This control field may alternatively indicate tostream and/or transfer data from the buffer managingmodule to the NVSM 12 while streaming and/or transferringdata from the NVSM 12 to the buffer managing module.SC3This control field indicates an address START_ROW_ADDR inthe NVSM 12 where to start a data transfer. Data written tothe NVSM 12 may begin at the address START_ROW_ADDR ordata may be read from the NVSM 12 starting at the addressSTART_ROW_ADDR.The address START_ROW _ADDR may include threeparameters. The parameters include a page address, a blockaddress, and a lun address. The page address is used as a rowindex to identify a specific row of memory cells. The blockaddress is used as an array index to identify a specific array ofmemory cells. The lun address is used as a device, NVSM chip,and/or NAND chip index to identify a specific device, NVSMchip, and/or NAND chip.SC4This control field indicates a column addressSTART_COL_ADDR to start at when accessing the NVSM 12.SC5This control field indicates how much data is being transferredfor the one or more descriptors generated by the descriptorgenerating module 103. An amount of data per descriptormay be indicated.SC6This control field may identify the segments of the buffer 70 inthe buffer managing module 44 to be involved in a datatransfer. Data may be transferred to or from a first segmentof the buffer 70 while transferring data to or from anothersegment of the buffer 70. Data may be streamed to or frommultiple segments of the buffer 70 during the same period oftime.SC7This control field may include pointers to physical addresses inthe buffer of the buffer managing module. The buffermanaging module 44 may jump (or skip) addresses when datais being transferred. When this occurs physical addresses maybe effectively linked using the pointers. This field may beused by the descriptor generating module 103 to convertlogical block addresses to physical block addresses whileaccounting for the skipped addresses by using the providedpointers.SC8This control field may be referred to as a command groupidentifier (ID) and used to identify a group of firmwaredescriptors stored in the memory 94. The descriptorgenerating module 103 may return this ID to the NVSMcontrol module 27 subsequent to completing generation ofdescriptors by the descriptor generating module 103.SC9This control field may be used to control parameters of theNVSM 12. For example, this field may include voltagereference adjustment values VREF used by NAND todistinguish between bit values stored in memory cells of theNAND.

In addition to the information stated in the above table, each of the control fields of a firmware descriptor may also indicate whether to use either (i) default values and/or information in a template, or (ii) replace the default values and/or information in the template with corresponding values and/or information in the parameter rows of the firmware descriptor. For example, the control field SC0 may include a default bit, which may be set to ‘0’ to indicate use of a corresponding default byte value in a template. The default bit may be set to ‘1’ to indicate use of a corresponding byte value provided as one of the parameters in a parameter row of the firmware descriptor. The control fields may include more than one default bit. For example, the control field SC3 may include a default bit for each of a page address, a block address, and a lun address to indicate whether to use a default page address, a default block address, and/or a default lun address. In addition, each of the control fields may have different formats and the formats of the control fields may be set based on the application in which the corresponding NVSM system is being used.

At506, the NVSM control module27sends the firmware descriptors to the memory94. At507, the NVSM control module27may trigger the descriptor generating module103subsequent to storing the firmware descriptors. The NVSM control module27may trigger the descriptor generating module103by, for example, sending a descriptor command signal to the descriptor generating module103indicating the transfer of the one or more firmware descriptors to the memory94. Task507may not be performed. As another example, the descriptor generating module103may detect the transfer of the firmware descriptors and begin generation of hardware descriptors without receiving a command signal from the NVSM control module27.

At508, the descriptor generating module103accesses the FIFO memory104and parses command parameters from one or more of the descriptor command signals and/or the firmware descriptors. At510, the descriptor generating module103accesses one or more descriptor templates (referred to hereinafter as “templates”) from the memory94and updates descriptor fields in the templates based on the command parameters in the one or more descriptor command signals and/or firmware descriptors. Each of the templates may be a generic descriptor and/or a flexible descriptor. A generic descriptor may have a predetermined set of parameter fields with predetermined default values in each of the parameter fields. A purpose of the generic descriptor may be fixed. A flexible descriptor refers to a descriptor for which parameter fields can be updated and/or used for different purposes. For example, fields of a flexible descriptor may be used to set different control parameters of a NVSM.

At512, the descriptor generating module103stores the one or more templates as modified at510in the memory94. The one or more templates as modified do not replace the corresponding one or more templates accessed at510. This allows the same default templates and/or modified templates to be used for subsequently generated descriptors (hardware and/or firmware descriptors).

At514, the descriptor generating module103, for each of the firmware descriptors and according to the corresponding and modified template, generates one or more second descriptors (e.g., hardware descriptors). Multiple second descriptors may be generated for each of (i) the firmware descriptors generated by the NVSM control module27, and/or (ii) corresponding and modified template. The second descriptors may include hardware and/or firmware descriptors. Examples of generating multiple hardware descriptors are described below with respect to the embodiments ofFIGS. 13-14.

At516, the descriptor generating module103stores the second descriptors generated at514in the memory94. The second descriptors generated at514may be stored as part of or separate from a corresponding and modified template. At518and subsequent to generating and/or saving the second descriptors, the descriptor generating module103may indicate to the NVSM control module27that generation of the current one or more second descriptors is completed. The descriptor generating module103may provide this indication by: sending a status signal to the NVSM control module27; setting a flag accessible to the NVSM control module27via, for example, the AHB bus105; and/or by generating an interrupt. The status signal may be transmitted via the AHB bus105.

At520, the descriptor generating module103may determine whether there is another firmware descriptor generated by the NVSM control module27to convert to, for example, multiple hardware descriptors. If there is another firmware descriptor, task508may be performed, otherwise the method may end at522.

During the above-described method, for example at518, one or more status registers may be updated for each of the firmware descriptors generated, executed and/or converted to hardware descriptors. The descriptor generating module103may update the fields in the status registers during and/or subsequent to the descriptor generating module completing generation of one or more descriptors. The NVSM control module27may track these fields to determine whether firmware-to-hardware (or single-to-multiple) descriptor conversion has been executed and completed.FIG. 12illustrates an example of a status register530that may be used for these tracking purposes.

The status register530shown includes four fields. The first field, identified as DGE_GENDES_CNT, indicates a number of descriptors (e.g., number of hardware and/or firmware descriptors) generated by the descriptor generating module103for a particular firmware descriptor. The second field, identified as DES_FIFO_ADDR, is an address pointer indicating an address in the memory94where the descriptors generated by the descriptor generating module103are stored. The third field, identified as DGE_ERR_CODE, indicates whether an error has occurred during the firmware-to-hardware and/or single-to-multiple descriptor conversion process. As an example, the third field may indicate when a parameter provided in a parameter row of a firmware descriptor is “out of boundary” meaning indiscernible by the descriptor generating module103. The fourth field, identified as DES_FIFO_ADDR_WRAPPED, indicates whether a descriptor has wrapped a circular memory. For example, a buffer or FIFO register may be used as a circular memory such that upon filling the buffer or FIFO register remaining data is written over data at a beginning of the buffer or FIFO register. As a result, if a descriptor is larger than a buffer or FIFO register, a last portion of the descriptor may be written over a beginning portion of the descriptor in the buffer or FIFO register.

The above-described tasks ofFIG. 9are meant to be illustrative examples; the tasks may be performed sequentially, synchronously, simultaneously, continuously, during overlapping time periods or in a different order depending upon the application. Also, any of the tasks may not be performed or skipped depending on the implementation and/or sequence of events.

FIGS. 13 and 14respectively illustrate an example of a firmware descriptor540and an example of a template550. The firmware descriptor540may be generated by the NVSM control module27ofFIG. 1. The firmware descriptor540and the template550may be stored in the memory94ofFIG. 1. In the example shown, the firmware descriptor540is generated for a multi-level cell embodiment, where the cells of the NVSM12include triple-level cells (TLCs). Each of the TLCs may be able to store multiple bits of data.

In the example shown, the firmware descriptor540includes multiple fields, such as the fields SRC_PTR, SRC_LEN, PRMT_ROW_NUM. The firmware descriptor540may indicate which fields to include in the hardware (or second) descriptors generated by the descriptor generating module103ofFIG. 1, such as the fields SC0, SC8, SC9, and SC5. The firmware descriptor540may include values for a channel and/or device identifier CH/DEV ID, a group command identifier TRACK_ID, a control parameter DQ0, and/or an address corresponding to the fields SC0, SC8, SC9, and SC5, as shown.

The firmware descriptor540may also include values to update corresponding descriptor values in the template550. For example, bytes 0-3 of the firmware descriptor540correspond to the field SC8 of the template550. As another example, the bytes 4-19 of the firmware descriptor540include values for fields DQ0-3 of the template550. Values for the fields DQ0-3 may be provided for each of the first four descriptors in the template550. The firmware descriptor540may also include bytes (e.g., bytes 20-23) having a start row address for field SC5.

As shown, the template550includes fields for each of 5 descriptors. The template550may include and number of fields for each descriptor and may have values for any number of descriptors. Also, any number of descriptors may be generated using the template550and/or values associated with a descriptor in the template550. The number of descriptors generated based on the template550and/or a portion of the template550may be indicated via the fields SRC_PTR and SRC_LEN. The template550may be defined by a user, predetermined, and/or generated by the NVSM control module27and stored in the memory94.

For a TLC read, up to four voltage reference (VREF) threshold adjustments for the NVSM12may be performed prior to issuing a read (or fifth) descriptor (e.g., DES5). For this reason, the template550may include descriptor values for the VREF adjustments. The descriptor values provided in the template550for the descriptors DES1-4 may be used respectively for the four VREF adjustments. The descriptor values DES1-4 may include a control parameter field SC9 with value DQ0, which may be used to indicate a respective VREF. In the example shown, control parameter fields DQ1-3 are not used. As an example, NVSM control module27may generate a firmware descriptor with a VREF adjustment values for respective upper, middle, and lower bits of memory cells. The VREF adjustment values may provide thresholds for determining states of the memory cells. In a two bit per memory cell example, the VREF adjustment values may provide thresholds for memory cell states 00, 01, 10, 11. The thresholds are used to distinguish between detected voltages corresponding to states of the memory cells to determine bit values of the memory cells.

The descriptors generated based on the template550may be generic and/or flexible descriptors. Each of the descriptors may include source control fields SRC_CTRL, such as the fields SC0, SC8, SC9, and SC5, as shown. The SC0 field may indicate, as described above, a channel CH and/or a device DEV. The SC8 field may indicate, as described above, a group command (or track) identifier. The SC5 field may indicate a start row address START_ROW_ADDR where data is stored in the NVSM12. The values in the fields SC0, SC8, SC9, SC5 of the descriptor values DES1-5 are input parameter index values, which may be obtained from the firmware descriptor and may replace corresponding values in the template. For example, if the field DQ0 is equal to 4 as indicated by the first descriptor value DES1, then the fields DQ0-3 for the first descriptor values DES1 are replaced by input parameter bytes 4-7.

The descriptor generating module103generates the five descriptors based on the descriptor values DES1-5 provided in the template550and input command parameters in the firmware descriptor540, such as the input command parameters stored in bytes 4-19. In the example shown, the VREFs stored in bytes 4-19 are input command parameters. Other input command parameters (examples of which are disclosed above) may be provided via the firmware descriptor540and updated in the template550.

The disclosed embodiments allow for templates and/or descriptors to be reused. As an example, to reuse the fourth descriptor values DES4, the NVSM control module27may set the field SCR_PTR to point to the fourth descriptor values DES4 and set the field SRC_LEN=2. This may be done to generate two descriptors using the same values in the same template550.

FIG. 15illustrates a reaccess method. Although the tasks ofFIG. 15are primarily described with respect to the example ofFIG. 1, the tasks may be applied to other embodiments of the present disclosure. The tasks of may be iteratively performed. Also, although the above-described tasks are primarily described with respect to reading data from the NVSM, the tasks may be modified to write and/or rewrite data to the NVSM.

The method may begin at600. At602, the NVSM control module27receives and/or detects reception of access request signals from the host device13. At604, the NVSM control module27, using the firmware92, generates one or more firmware (or first) descriptors based on the access request signals. The firmware descriptors may be generated to read data from or write data to the NVSM12. At606, the NVSM control module27sends the firmware descriptors to the memory94and/or the descriptor generating module103and/or descriptor command signals to the descriptor generating module103. The firmware descriptors may be provided directly to the descriptor generating module103or may be provided indirectly to the descriptor generating module103via the command management module60. The descriptor command signals and/or the firmware descriptors may be used to trigger the command management module60to initiate descriptor processing and enable, for example, modules11,48,50,103and107. The storing and/or transfer of the firmware descriptors may trigger the command management module60. Tasks602-606may be similar to tasks502-506described above with respect toFIG. 9.

At607, the command management module60may parse the firmware descriptors and enable the modules11,48,50,103and107of the interface management control system26. The command management module60may enable the modules11,48,50,103and107, as follows. The command management module60may send a descriptor type bit HW_RRD to the interface management module50to indicate that a firmware descriptor is being transferred as opposed to a hardware or reaccess descriptor. For this reason, the command management module60does not trigger the linklist module107for reaccess descriptors. The descriptor type bit HW_RRD indicates the type of descriptor (e.g., firmware, hardware, or reaccess) being provided. This indicates to the interface management module50where to send a response signal with status information as described below at task617. The ECC module48fetches, based on an allocation block ID from the command management module60, linklists from the memory94.

The command management module60, for the firmware descriptors and purposes of loading information, identifies new allocation blocks to monitor and initializes a reacccess count CNT for each of the allocation blocks and/or group of allocation blocks. The reaccess count CNT may be set equal to zero. The loaded information may include default templates, reaccess templates, control information, or other information pertaining to the execution of the firmware descriptors and the transfer of corresponding data. The reaccess count may be used by the reaccess module11to identify a current reaccess event.

At608, the descriptor generating module103generates hardware (or second descriptors) as described above in tasks510-518ofFIG. 5or generates reaccess descriptors (third descriptors) depending on whether one or more reaccess events are to be performed. The second descriptors are generated if a first access event is to be performed and/or a reaccess event is not to be performed. The second descriptors are not reaccess descriptors. The descriptor generating module103generates the third descriptors when a reaccess event is to be performed. The third descriptors are generated for one or more pages and/or one or more allocation blocks. A reaccess descriptor FIFO pointer may be moved to a next descriptor to be executed prior to task609.

At609, the NVSM control module27and/or the descriptor generating module103triggers the command management module60to start processing of hardware descriptors or the reaccess descriptors. The command management module60receives the second descriptors or the third descriptors and checks availability of: data for a program (or write) operation; or space availability for a read operation. Space availability may refer to space available in FIFOs of the interface management module50. As shown above, the command management module60can receive commands (e.g., firmware descriptors, hardware descriptors and, as described further below, reaccess descriptors) from the NVSM control module27and the descriptor generating module103.

At610, the command management module60sends a start signal AU_START to the ECC module48to initiate ECC encoding and/or decoding. At612, the command management module60sends a request signal FLC_REQ to the linklist module107to prepare a linklist for one or more allocation blocks. The linklist module107may be provided with and/or may access information to prepare the linklist. The information may be provided by the command management module60and may include addresses, allocation block formats, and a number of allocation blocks per page. At614, the command management module60while sending the request signal FLC_REQ may also send a second trigger signal SET_DES to the interface management module50to trigger corresponding operations of the NVSM12. Tasks614may be performed while performing task612.

At616, subsequent to completing execution of the second descriptors or the third descriptors, the interface management module50and/or the ECC module48(i) process data transferred due to the execution of the second descriptors or the third descriptors, and (ii) generate status information (e.g., descriptor ID, NVSM parameter updates, and error information) for each of the allocation blocks and/or groups of allocation blocks transferred. As an example, the parameter updates may include voltage reference Vref changes or other NVSM control information changes. The parameter changes may be indicated by the interface management module50. The error information may indicate the type of error, the number of errors, whether there is an error, and/or whether no error exists. The error information may indicate that execution of a descriptor is completed and no error exists. The error information may be indicated via the interface management module50and/or the ECC module48.

At617, status information is reported. The interface management module50and the ECC module48reports status information to the reaccess module11, the NVSM control module27, and/or the command management module60. The interface management module50may report status information to and the reaccess module11, the ECC module48, and/or the command management module60. The status information may be based on the descriptor type bit HW_RRD and include descriptor status information and current states of control parameters, such as current states of the voltage references Vrefs. The descriptor status information may include information pertaining to hardware descriptors and/or reaccess descriptors executed. This may include, for a current access event: descriptor IDs; allocation block IDs; an indication of whether execution of each of the descriptors is completed; indications of whether there are any errors associated with executing each of the descriptors; and/or indications of whether there are any errors associated with data transferred as a result of executing the descriptors.

The ECC module48may provide status updates and/or corresponding signals for each allocation block or group of allocation blocks. The status updates and/or corresponding signals may include a data error update AU_FAIL, an allocation block transfer update AU_DONE, and a first reaccess signal REACCESS1. The ECC module48may report a first reaccess signal REACCESS1 to the reaccess module11to trigger a reaccess event if conditions for performing a reaccess event have been satisfied and a maximum number of reaccess events for the one or more allocation blocks has not been exceeded. A reaccess information FIFO109in the memory94may store an indication of whether a reaccess event is to be performed. The data error update AU_FAIL indicates whether there is an error associated with the data transferred. The error may have occurred during accessing of the NVSM12and/or during the encoding or decoding performed in the ECC module48. The allocation block transfer update AU_DONE indicates whether the transfer of the allocation blocks is completed and/or whether the ECC module48is done processing and transferring the allocation blocks.

The reaccess module11may send a reaccess status update to the status FIFOs110after a reaccess event is done. The NVSM control module27, via the firmware92, may check the reaccess status stored in the status FIFOs110.

At618, the command management module60monitors and stores the status information generated by the ECC module48and/or interface management module50into status FIFOs110in the memory94. The command management module60may monitor the status FIFOs110and interrupt the NVSM control module27when certain conditions exist (e.g., generation and/or execution of one or more hardware descriptors is completed, one or more allocation block errors have been detected, etc.). The interrupt may be based on the status information received from the interface management module50at110. The command management module60may send a second reaccess signal REACCESS2 to the reaccess module11and/or the ECC module48indicating whether a reaccess event is to be performed for one or more allocation blocks. The second reaccess signal REACCESS2 may be based on a control signal from the NVSM control module27.

At620, the NVSM control module27, while executing the firmware92, may set up, select, and/or change reaccess templates, which may be stored as part of the templates106in the memory94. The reaccess templates may be the same as, similar to, or different than the templates (e.g., templates described with respect to the method ofFIG. 9) used to generate the hardware descriptors. A different reaccess template may be used for each successive reaccess event associated with one or more memory cells and/or one or more addresses in the NVSM12. As an example, if the maximum number of reaccess attempts is 4, then 4 different templates may be used, one template for each reaccess attempt. As an alternative the NVSM control module27and/or the descriptor generating module103may adjust the same template between reaccess events. The use and/or adjustment of the templates increases the potential of correcting errors. Parameters of the templates used for the reaccess events may be different and/or adjusted. For example, the above-described control parameters, provided in corresponding descriptors and templates such as the voltage references Vrefs may be different and/or adjusted to better determine states of memory cells. The parameters of the reaccess templates may be updated based on the status information.

The templates used for successive reaccess events associated with the same memory cells and/or addresses of the NVSM12is referred to as a group of templates. Each group of templates may be associated with a flow of descriptors and corresponding data. As an example, a predetermined number (e.g., 16) of flows of descriptors and corresponding data may be executed and transferred in parallel.

Although task620is shown as being performed subsequent to task618and in response to the status information, task620may be performed prior to task618and may not be performed based on the status information. For example, task620may be performed at604and/or the reaccess templates may be predetermined and stored in memory.

At622, the reaccess module11monitors the status information. Task622may be performed while tasks618,620are performed. Task622may be performed subsequent to ECC module48and the interface management module50updating the status information.

At624, the reaccess module11determines: (i) whether the ECC module48(identified as the logical domain) is done processing the allocation blocks, and (ii) whether the interface management module50(identified as the physical domain) is done executing the hardware and/or reaccess descriptors. If the logical and physical domains are done, task626is performed, otherwise one or more of tasks617-622is performed.

At626, the reaccess module11determines whether there is one or more allocation blocks to be reaccessed and/or whether there are one or more reaccess events to be performed. Task628is performed when there are one or more reaccess events to be performed, otherwise task634is performed.

At628, the reaccess module11determines whether the reaccess count CNT is greater than the maximum number of permitted reaccess events for the corresponding allocation blocks. If the reaccess count CNT is greater than the maximum number, task634may be performed, otherwise task629is performed.

The allocation block IDs, the reaccess count, and the maximum number may be stored in the reaccess information FIFO109and accessed and updated by the reaccess module11. The ECC module48may also access the reaccess information FIFO109to determine whether the allocation blocks have passed (i.e. no reaccess event to be performed) or failed (i.e. conditions satisfy performing a reaccess event). The reaccess module11may perform up to the maximum number of reaccess events for each allocation block and/or group of allocation blocks. If after the maximum number of reaccess events the corresponding allocation blocks and/or group of allocation blocks still have corresponding errors justifying that a reaccess event be performed, the reaccess module11may report to the ECC module48the status of the allocation blocks as failed. The ECC module48may determine this status by accessing the reaccess information FIFO109and indicate a pass or a failure at629. Task634may be performed subsequent to task629.

At630, the reaccess module11, increments the reaccess count CNT. At631, status values, for each of the allocation blocks to be transferred again during a reaccess event, may be reset. This allows the status values to be set during the next reaccess events.

At632, the reaccess module11, based on the status information, triggers the descriptor generating module103to generate reaccess descriptors (e.g., reread descriptors or rewrite descriptors). The reaccess descriptors are for the allocation blocks for which a reaccess event is to be performed. Task608may be performed subsequent to task632.

At634, if a reaccess event is not to be performed, allocation blocks and/or the corresponding information loaded in the reaccess module11is cleared. The method may end at636.

The above-described tasks ofFIG. 15are meant to be illustrative examples; the tasks may be performed sequentially, synchronously, simultaneously, continuously, during overlapping time periods or in a different order depending upon the application. Also, any of the tasks may not be performed or skipped depending on the implementation and/or sequence of events.

Because there are numerous implementations of the present disclosure, the arrangements do not explicitly show all of the implementations. For example, the adjacent and non-adjacent elements shown in, for example,FIGS. 1-5may be directly or indirectly connected to each other. The adjacent and non-adjacent elements may wirelessly communicate with each other and/or may communicate with each other via wired links. The wireless communications described in the present disclosure can be conducted in full or partial compliance with IEEE standard 802.11-2012, IEEE standard 802.16-2009, IEEE standard 802.20-2008, and/or Bluetooth Core Specification v4.0. In various implementations, Bluetooth Core Specification v4.0 may be modified by one or more of Bluetooth Core Specification Addendums 2, 3, or 4. In various implementations, IEEE 802.11-2012 may be supplemented by draft IEEE standard 802.11ac, draft IEEE standard 802.11ad, and/or draft IEEE standard 802.11ah.

The foregoing description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses. The broad teachings of the disclosure can be implemented in a variety of forms. Therefore, while this disclosure includes particular examples, the true scope of the disclosure should not be so limited since other modifications will become apparent upon a study of the drawings, the specification, and the following claims. As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A or B or C), using a non-exclusive logical OR. It should be understood that one or more steps within a method may be executed in different order (or concurrently) without altering the principles of the present disclosure.

The term code, as used above, may include software, firmware, and/or microcode, and may refer to programs, routines, functions, classes, and/or objects. The term shared processor encompasses a single processor that executes some or all code from multiple modules. The term group processor encompasses a processor that, in combination with additional processors, executes some or all code from one or more modules. The term shared memory encompasses a single memory that stores some or all code from multiple modules. The term group memory encompasses a memory that, in combination with additional memories, stores some or all code from one or more modules. The term memory is a subset of the term computer-readable medium. The term computer-readable medium, as used herein, does not encompass transitory electrical or electromagnetic signals propagating through a medium (such as on a carrier wave); the term computer-readable medium may therefore be considered tangible and non-transitory. Non-limiting examples of a non-transitory, tangible computer-readable medium include nonvolatile memory (such as flash memory), volatile memory (such as static random access memory and dynamic random access memory), magnetic storage (such as magnetic tape or hard disk drive), and optical storage.

The apparatuses and methods described in this application may be partially or fully implemented by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions that are stored on at least one non-transitory, tangible computer-readable medium. The computer programs may also include and/or rely on stored data.

Although the terms first, second, third, etc. may be used herein to describe various elements, components, channels, modules, and/or devices, these elements, components, channels, modules, and/or devices should not be limited by these terms. These terms may be only used to distinguish one elements, components, channels, modules, and/or devices from another elements, components, channels, modules, and/or devices. Terms such as “first,” “second,” and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first elements, components, channels, modules, and/or devices discussed below could be termed a second elements, components, channels, modules, and/or devices without departing from the teachings of the example embodiments.