Patent Application
20160034187
A storage module may receive host commands from a host, including read commands and write commands. To execute the host commands, the storage module may include a plurality of processing modules and queues that generate and queue commands, so that data may be successfully read from or written to memory in the storage module. In some situations, the host may subsequently send an abort command to abort one or more pending host commands. Upon receipt, the abort command may be broadcast or spread out across the various processing modules. In turn, the processing modules may analyze associated queues and filter out any commands that are associated with the host command or commands to be aborted. Additionally, during this time, any hardware components, including those in the host interface, may be paused, and data communication may be halted to ensure that the hardware components do not execute any commands that should be aborted. Given that several host commands may be pending at single time, performance may be significantly degraded when operation is halted, and the various processing modules have to filter out associated queues to successfully abort a host command.
Embodiments of the present invention are defined by the claims, and nothing in this section should be taken as a limitation on those claims.
By way of introduction, the below embodiments relate to a storage module and method for virtual abort. In one embodiment, a virtual abort of a read command is provided. The read command triggers a read operation that comprises reading data from the storage module's memory, processing the data by at least one processing module as the data moves along a data path from the memory to the storage module's host interface module, and then providing the data to a host via the host interface module. When an abort command is received, the storage module allows the data that is read from the memory to be processed by the at least one processing module as the data moves along the data path to the host interface module but prevents the host interface module from providing the data to the host.
In another embodiment, a virtual abort of a write command is provided. The write command triggers a write operation that comprises generating one or more context commands used to initiate a transfer of data associated with the write command from the host to the storage module. In response to receiving an abort command, the host interface module ignores the one or more context commands to transfer data.
Other embodiments are possible, and each of the embodiments can be used alone or together in combination. Accordingly, various embodiments will now be described with reference to the attached drawings.
The following embodiments can be used to perform a virtual abort command to overcome the problems discussed in the background section above. Before turning to these and other embodiments, the following paragraphs provide a discussion of exemplary storage modules that can be used with these embodiments. Of course, these are just examples, and other suitable types of storage modules can be used.
As illustrated in
As shown in
As shown in
In
Returning to
The non-volatile memory 120 can also take any suitable form. For example, in one embodiment, the non-volatile memory 120 takes the form of a solid-state (e.g., flash) memory and can be one-time programmable, few-time programmable, or many-time programmable. The non-volatile memory 120 can also use single-level cell (SLC), multiple-level cell (MLC), triple-level cell (TLC), or other memory technologies, now known or later developed. Also, the non-volatile memory 120 can be a two-dimensional memory or a three-dimensional memory.
With an exemplary storage device now described, the following paragraphs discuss embodiments that can be used to perform a virtual abort. As mentioned in the background section above, in prior storage modules, when an abort command is received for a read operation, commands to abort various internal processes are propagated to various processing modules in the data path from the memory to the host interface module. Such propagation and the actions associated therewith can degrade performance of the storage module. To address this problem, the following embodiments provide a “virtual abort” scenario in which, instead of propagating the abort commands to the various processing modules, the data flows through the data path and is processed as normal, but the host interface module is prevented from providing the data to the host. A virtual abort can also be performed for a write operation, in which case the host interface module ignores one or more context commands to transfer data.
With this general overview of virtual abort now provided, the following paragraphs describe several exemplary implementations.
Returning to
Referring to
In further detail, when a host read command is received by the storage controller 110, it may be placed in a command queue 306, which may queue the host read command along with other media and non-media related host commands. A front end (FE) module 308 may retrieve the read command, along with other media-related commands, and place the read command in a request queue 310. A media control processing (MCP) module 312 may retrieve the read command in the request queue 310 and generate one or more sets of one or more context commands. The context commands may be commands used internally by other modules of the storage module 100 to identify and properly process the data for execution of the associated read command. Among other information, each context command may include an attribute or identifier that identifies the host command with which the context command is associated. Additionally, a number of context commands that are generated may correspond to the size of the data to be read as identified in the associated host read command. Each context command may correspond to a portion or sector of the data to be read. To illustrate, suppose the host read command is for 64 kB of data to be read. Further, suppose that each context command corresponds 8 kB of the 64 kB of data. The MCP module 312 may then generate 8 context commands in a set for reading, processing, and sending the all 64 kB of the data to the host.
The MCP module 312 may generate multiple sets of context commands for multiple processing modules. For example, as described in further detail below, the MCP module 312 may generate and place in a HIM context queue 314 a set of context commands for use by the HIM module 304 for transferring data from the buffer pool 302 to the host. In addition, the MCP module 312 may generate and place one or more sets of context commands in one or more command processing queues (CPQ) 316(1) to 316(N) of one or more control paths 317a, 317b.
The MCP module 312 may queue context commands in one or more of the control processing queues 316(1) to 316(N) in the control paths 317a, 317b, which may be retrieved and used by one or more of the control processing modules 318(1) to 318(M) in the control paths 317a, 317b to perform their respective operations. The control processing modules 318(1) to 318(M) may also queue commands or other information in the control processing queues 316(1) to 316(N) for retrieval by other control processing modules 318(1) to 318(M). Various configurations or implementations of the control processing modules 318(1) to 318(M) and the control processing queues 316(1) to 316(N) in the control paths 317a, 317b may be possible.
Data transferred from the non-volatile memory areas 320(1) to 320(P) to the controller 110 may be transferred along one or more data paths 332a, 332b.
Each of the data paths 332a, 332b may include an R-number of data processing (DP) modules 334(1) to 334(R) that perform various processes or operations on the data before the data is sent to the host. Example processes or operations may include error correction, decryption and/or decoding. Other processes or operations performed on the data in the data paths 332a, 332b may be possible.
For some example configurations, one or more control processing modules 318(1) to 318(M) in the control paths 317a, 317b may generate sets of context commands for the data processing modules 334(1) to 334(R) in the control paths 332a, 332b. These context commands may include information that the data processing modules 334(1) to 334(R) may use when performing their respective data processing operations on the data. The control processing modules 318(1) to 318(M) may queue the context commands in data path (DP) context queues 336(1) to 336(R), and the data processing modules 334(1) to 334(R) in the data paths 332a, 332b may retrieve the context commands from the data path context queues 336(1) to 336(R) when processing the data.
The data may be sent to and processed by some or all of the data processing modules 334(1) to 334(R). After the data is processed in the data paths 332a, 332b, the data may be sent to the buffer pool 302 for temporary storage before it is sent to the host.
As previously described, the MCP module 312 may generate a set of context commands including information that the HIM module 304 may use to transfer data stored in the buffer pool 302 to the host. An arbiter module 340 may be configured to determine when data associated with a host read command is ready to be sent to the host. For some example configurations, the arbiter module 340 may determine that data stored in the buffer pool 302 is ready to be sent to the host when the data in the buffer pool 302 comprises all or at least a threshold amount of the data requested to be read by the read host command. When the arbiter determines that data is available to be sent to the host, the arbiter module 340 may pull out a HIM context command associated with the data and send the HIM context command to the HIM module 304. In response to the HIM context command, the HIM module 304 may enter or transition to a data transfer mode and receive a data packet from the buffer pool 302 that includes data identified by the HIM context command. The HIM module 304 may then send the received data packet to the host. After sending the data packet to the host, the HIM module 304 may release any context command resources used to store the HIM context command in the HIM context queue 314 as well as release any buffer resources used to store the data in the buffer pool 302.
Additionally, when sending the data packet to the host, the HIM module 304 may update a counter that keeps track of the HIM context queues and/or data packets associated with a read request. When the counter reaches a threshold count or value, the HIM module 304 may identify that it has received all of the HIM context commands and/or has sent all of the data packets associated with the host read command to the host. For example, using the illustration above where the MCP module 312 determined to generate 8 context commands, after the counter counts that eight HIM context commands have been received or eight data packets have been received from the buffer pool 302 and sent to the host, the counter may determine that all of the data associated with the host read command has been sent to the host.
For some example configurations, the threshold count or value may be based on a length or size of the data to be sent to the host to complete a host read request. Each HIM context command and associated data packet may be used to transfer a sector of the maximum length of the data. The counter may keep track of an amount of sectors of data that have been sent. Each time the HIM module 304 receives a HIM context command or transfers a data packet, the HIM module 304 may update a sector value. When the sector value equals the length of the data, the HIM module 304 may know that all of the data associated with the host read command has been sent to the host. Additionally, after the HIM module 304 is finished sending the data associated with the host read command to the host, the HIM module 304 may issue an interrupt signal, which notifies the host and/or the other modules in the storage controller 110 that the HIM module 304 is finished sending the data associated the host read command to the host.
In some situations, the storage controller 110 may receive an abort command that instructs the storage controller 110 to abort one or more pending host read commands. If none of the data associated with a host read command to be aborted has been sent to the host, the storage controller 110 may perform an abort procedure to abort the one or more host read commands requested to be aborted.
For some example configurations, when an abort command is received, the front end module 308 may broadcast the abort command to the various control and data processing modules 318(1) to 318(M), 334(1) to 334(R) in the control and data paths 317a, 317b, 332a, 332b. In response to receiving the abort command, the processing modules 318(1) to 318(M), 334(1) to 334(R) may check associated control and data processing queues 316(1) to 316(N), 336(1) to 336(N), remove any context commands associated with the host command to be aborted, and notify the front end module 308 or other higher layer modules when it is finished. Additionally, any hardware components may be paused to ensure that they do not process any context commands that need to be removed in response to the abort command. When all of the context commands are removed, the storage controller 110 may notify the host that the abort command has been executed. Alternatively, rather than remove only the context commands from the queues that are associated with the host commands requested to be aborted, all of the host commands may be aborted and the host commands not to be aborted may be resubmitted.
As shown in
Alternatively to performing the above-described abort processes, when the storage controller 110 receives an abort command to abort one or more host read commands, the control and data processing modules 318(1) to 318(M), 334(1) to 334(R) in the control and data paths 317a, 317b, 332a, 332b may operate normally as if the abort command was not received such that data associated with the one or more read commands requested to be aborted may be communicated along one of the data path 332a, 332b, processed by the data processing modules 334(1) to 334(R) in the data paths 332a, 332b, and sent to the HIM module 304 for transmission to the host. However, the HIM module 304 may recognize the data that is associated with the one or more read commands to be aborted and in turn, may prevent transmitting the data to the host.
The command attributes that are determined and/or how they are determined may depend on the type of abort command that is received from the host. One type of abort command may be an abort command to abort a particular host read command. This type of abort command may include a command ID that identifies the host command to be aborted. When the storage controller 110 receives an abort command to abort a particular host read command, the storage controller 110 may use the command ID included in the abort command as the attribute. Another type of abort command may be a reset logic unit number (LUN) command that identifies a LUN of the non-volatile memory 120. The non-volatile memory 120 may be divided or partitioned into a plurality of portions, with each portion being assigned a LUN. A LUN reset command may be a command to abort all commands involving data to be read from or written to the portion of the non-volatile memory 120 having the LUN identified in the LUN reset command. When this type of command is received, the storage controller 110 may determine the command IDs for all of the host commands involving data to be read from and/or written to the portion of the storage having the identified LUN. A third type of abort command may be an abort-all command that requests that all pending host commands be aborted. When an abort-all command is received, the storage controller 110 may determine the command IDs for all of the pending host commands. In addition or alternatively to determining command IDs for all of the pending host commands, the data processing modules 334(1) to 334(R) may be configured to operate in a bypass mode. In the bypass mode, the data processing modules 334(1) to 334(R) may simply pass the data to a next data processing module or to the data pool 302 without performing their respective operations.
As shown in
As an example, the storage controller 110 may receive an abort command that includes a command ID identifying a particular host read command to be aborted. Upon receipt of the abort command, the front end module 308 may program the comparator module 402 with the command ID. During operation of processing host read commands, the arbiter module 340 may retrieve HIM context commands from the HIM context queue 314 and send the HIM context commands to the HIM module 304 when the arbiter module 340 determines that associated data is available to be sent to the host, just as the arbiter module 340 normally would if an abort command was not received. The HIM context commands may each include a command ID that identifies the host command for which the HIM context command was generated. Upon receipt of the HIM context command from the arbiter module 340, the comparator module 402 may compare the programmed command ID with the command ID included in the HIM context command. A match between the two command IDs may indicate to the comparator module 402, or the HIM module 304 generally, that the data associated with the HIM context command is not to be sent to the host because it is associated with a host read command that the host wants aborted. Alternatively, a mismatch between the two command IDs may indicate that the data associated with the HIM context command is to be sent to the host because it is not associated with a host read command that the host wants aborted.
Receipt of the HIM context command may trigger the HIM module 304 to receive a data packet that includes the data associated with the HIM context command, just as what normally would happen without receipt of an abort command. The comparator module 402 may receive the data packet and compare the programmed command ID included in the data packet with a command ID included in the data packet. If the command IDs match, then the comparator module 402 may determine that the data packet is not to be sent to the host and prevent the data packet from being sent to the host. Alternatively, if the command IDs do not match, then the comparator module 402 may determine that the data is not associated with the aborted host read command and that the data should be sent to the host. The comparator module 402 may subsequently pass the data packet to a HIM transfer module 404, which may transfer the data packet to the host. The HIM transfer module 404 may be a direct memory access (DMA) controller or other similar logic controller that is operable to communicate with and transfer data to the host.
By configuring the HIM module 304 to receive HIM context commands and data packets for any host read command, regardless of whether an abort command is received, and by comparing command attributes and preventing data packets associated with aborted host read commands from being sent to the host while allowing data packets not associated with aborted host read commands to be sent to the host when an abort command is received, multiple host read commands may be received and those not associated with an abort command may be processed and have associated data sent back to the host, even if one or more abort commands for other host read commands are pending in the storage controller.
In the event that the comparator module 402 identifies a match between a programmed command ID and a received command ID from either a context command or a data packet, the HIM module 304 may take any number of various actions to prevent the data packet from being sent to the host. For some example configurations, the HIM module 304 may drop the data packet. For other example configurations, the HIM module 304 may send the data packet to an internal memory location within the storage module 100, such as to ROM 116 as an example. Other ways of preventing the data packet from being sent to the host may be possible.
For other example configurations, rather than perform two comparisons—i.e., a first comparison involving a programmed command ID and command IDs included in a HIM context command and a second comparison involving the programmed command ID and command IDs included in received data packets—the comparator module 402 may perform only a single comparison before determining whether or not to send a received data packet to the host. For example, the comparator module 402 may only compare the programmed command ID with a command ID included the HIM context command and based on that comparison, determine whether or not to send an associated received data packet to the host. Alternatively, the comparator module 402 may not compare a programmed ID with command IDs included in the HIM context commands and instead, wait until an associated data packet is received from the buffer pool 302 before comparing command IDs.
After the HIM module 304 either sends the data packet to the host or prevents the data packet from being sent to the host, the HIM module 304 may release any resources associated with the data packet, including resources used to queue the HIM context command in the HIM context queue 314 and resources used to store the data in the buffer pool 302. Additionally, the HIM module 304 may update a counter to determine whether the comparator module 402 has received all of the HIM context commands and has prevented from sending all of the data associated with a host read command that the host wants aborted. The counter may be updated in the same way that a counter is updated when the HIM module 304 sends a data packet to the host, as previously described. If the counter reaches a threshold value, indicating that there are no more data packets to be prevented from being sent to the host, then the HIM module 304 may generate an interrupt signal indicating that execution of the abort command is complete.
Additionally, the comparator module 402 may perform similar actions when it is programmed with multiple command IDs, such as if a reset LUN command or an abort-all command is received. That is, the comparator module may compare received command IDs included in HIM context commands and/or data packets with a plurality of command IDs and determine whether the received command IDs match any of the plurality of programmed command IDs.
In addition or alternatively to command IDs, the HIM module may use a bypass flag as an attribute to determine whether to send a data packet to a host. In some situations, if an abort-all command is received from the host, a bypass flag included in the HIM context commands may have a positive indication, indicating to the HIM module 304 to bypass sending an associated data packet to the host. When the HIM module 304 detects the bypass flag with the positive indication, the HIM module 304 may prevent an associated data packet from being sent to the host, just as it would when determining a match between compared command IDs.
For some example configurations, the comparator module 402 may be configured to operate in and switch between operating in a normal mode of operation and an abort mode of operation, and may determine whether to prevent a received data packet from being sent to the host only when it is configured in the abort mode. Alternatively, when configured in the normal mode, the comparator module 402 may pass received HIM context commands and data packets to the HIM transfer module 404 without analyzing command attributes and/or performing attribute comparisons.
The front end module 308 may be configured to set the comparator module 402 in either the normal mode or the abort mode. If there are no pending abort commands, then the comparator module 402 may be configured in the normal mode. Upon receipt of an abort command, the front end module 308 may configure the comparator module 402 in the abort mode. In the abort mode, when the HIM module 304 determines that there are no more data packets to prevent from being sent to the host, such as when the counter reaches a threshold count, the HIM module 304 may issue an interrupt signal as previously described. The issuance of the interrupt signal may cause the HIM module 304 to be configured back into the normal mode, assuming there are no other pending abort commands such that the comparator module 402 should still be configured in the abort mode. For some example configurations, the HIM module 304 may issue the interrupt signal to the host. In response, the host may send a reset signal back to the storage module 100, which may cause the front end module 308 to reconfigure the comparator module 402 in the normal mode.
When the arbiter module 340 determines that the HIM module 304 is ready to receive data from the host, the arbiter module 340 may retrieve a HIM context command associated with the write command from the HIM context queue 314 and send the HIM context command or information included in the HIM context command to the HIM module 304. Assuming that an abort command to abort the write command associated with the HIM context command has not been received, the comparator module 402 may send the HIM context command to the HIM transfer module 404, which may initiate a data transfer for data associated with the HIM context command. The data may then be transferred from the host to the buffer pool 302 via the HIM module 304. After the data is transferred, the HIM module 304 may update a counter indicating when a last HIM context command and/or a last data packet associated with the write command is received. In the event that the count indicates that no more HIM context commands or data packets associated with the write commands are to be received, the HIM module 304 may issue an interrupt signal indicating that all of the data packets are in the buffer pool 302.
In the event that the controller module 110 receives an abort command to abort a host write command, the host will not send data associated with that host write command. For some example configurations, when an abort command is received, the front end module 308 may broadcast the abort command to other processing modules within the storage module 100, which may cause the processing modules to filter out any context commands associated with the aborted write command from respective queues. Additionally, hardware modules, including one or more components of the HIM module 304, may be paused to ensure that context commands associated with the aborted write command are not processed in hardware while the context commands are being filtered out of the queues. Eventually, the HIM module 304 in a paused state may timeout and issue a timeout notification to the host, which may respond by sending a signal that reconfigures the HIM module 304 back into a normal state of operation.
Alternatively to the above-described abort process to abort a host write command, the storage controller 110 may be configured to determine a command attribute that identifies or associates HIM context commands with host write commands to be aborted. The HIM module 304 may use the command attribute to prevent initiating the data transfer when it receives a HIM context command for an aborted write command. This way, the HIM module 304 does not have to be paused when an abort command to abort a host write command is received and instead, can continue to receive and process HIM context commands received from the arbiter module 340.
In one example, when an abort command is received, the abort command may include a command ID identifying the host write command to be aborted. The front end module 308 may program the comparator module 402 with the command ID. When the comparator module 402 receives HIM context commands from the arbiter module 340, the comparator module 402 may compare the programmed command ID with a command ID in the HIM context command. A mismatch between the command IDs may indicate that the received context command was not generated for a host write command to be aborted. In response to the mismatch, the comparator module 402 may pass the HIM context command to the HIM transfer module 404 which may initiate a data transfer for associated data from the host to the buffer pool 302.
Alternatively, a match between the command IDs may indicate that the received context command was generated for a host write command to be aborted. In response to the match, the HIM transfer module 404 may not initiate a data transfer for associated data from the host to the buffer pool. In particular, the HIM transfer module 404 may not identify or store within any registers information need to perform the data transfer, including the source address, the destination address, and the length of the data. In addition, the HIM transfer module 304 may not reserve any space or other resources for the data to be stored in the buffer pool 302. Further, the HIM module 304 may release any resources used to queue the HIM context command in the HIM context queue 314. The HIM module 304 may perform these actions without being paused and may be ready for a next HIM context command from the arbiter module 340.
Additionally, when an abort command to abort a host write command is received, the front end module 308 may be configured to switch the comparator module 402 from a normal mode of operation to an abort mode of operation, as previously described with respect to aborting host read commands. When the HIM module 304 determines that there are no more HIM context commands associated with the host write command to be received, the HIM module 304 may issue an interrupt signal, which may cause the host to send a reset signal to storage module 100 that causes the front end module 308 to switch the comparator module 402 back to the normal mode of operation.
At block 606, the storage controller may receive an abort command to abort the host read command. At block 608, a front end module of the storage controller may determine a command attribute that identifies the host read command to be aborted or otherwise associates the abort command with the host read command. The command attribute may be the same attribute that is included in generated HIM context commands associated with the host read command, such as a command ID. Additionally, when the abort command is received, if all of the data associated with the host read command to be aborted is not stored in the internal buffer pool, the processing modules may allow any remaining data associated with the aborted host read command to be transferred along the data path to the buffer pool.
At block 610, the front end module may program the HIM module, such as a comparator of the HIM module, with the command attribute. The front end module may also switch the comparator from being configured in a normal mode of operation to an abort mode of operation as previously described. The front end module may program the comparator and/or switch the comparator to the abort mode without broadcasting the abort command to other processing modules in the storage controller and without pausing any hardware components, including any hardware components of the HIM module.
At block 612, the comparator may receive a HIM context command from an arbiter module to start a transfer of an associated data packet from the buffer pool to the host. At block 614, in response to receiving the HIM context command, the comparator, in the abort mode, may compare the programmed command attribute with a command attribute in either the received HIM context command and/or the associated data packet. The comparator may perform the comparison(s) to prevent any data packets associated with the aborted host read command from being sent to the host while allowing data packets not associated with the aborted host read command to be sent to the host.
If the command attributes match, then at block 616 the comparator may determine that the data packet is associated with an aborted host read command and prevent the data packet from being sent to the host. For some example methods, the comparator may prevent the data packet from being sent to the host by dropping the data packet. For other example methods, the comparator may prevent the data packet from being sent to the host by sending the data packet to an internal location, such as a portion of a read-only memory, in the storage module.
At block 618, the comparator may release any resources associated with storing the data packet in the buffer pool and queuing the HIM context command in the HIM context queue. At block 620, the HIM module may update a counter associated with HIM context command and the data packet. At block 622, based on the update of the counter, the HIM module may determine if all of data packets associated with a host read command have been processed. If so, then at block 624, the HIM module may issue an interrupt signal indicating that it has received and processed all of the HIM context commands and data packets associated with a host read command. Issuing an interrupt signal may also cause the comparator to be switched back to the normal mode of operation if it is not in the normal mode already. Referring back to block 622, if all of the data packets associated with a host read command have not been processed, then the method may proceed back to 612 without issuing an interrupt signal, where the comparator may receive another HIM context command from the arbiter module.
Proceeding back to block 614, if the command attributes do not match, then at block 626, the comparator may determine that the data packet is not associated with an aborted host read command and may send the data packet to the host. The method may then proceed to blocks 618-624 to release any resources, update a counter, and issue an interrupt signal if all of the data packets associated with a host read command have been received and processed.
At block 706, the storage controller may receive an abort command to abort the host write command. At block 708, a front end module of the storage controller may determine a command attribute that identifies the host write command to be aborted or otherwise associates the abort command with the host write command. The command attribute may be the same attribute that is included in generated HIM context commands associated with the host read command, such as a command ID.
At block 710, the front end module may program the HIM module, such as a comparator of the HIM module, with the command attribute. The front end module may also switch the comparator from being configured in a normal mode of operation to an abort mode of operation as previously described. The front end module may program the comparator and/or switch the comparator to the abort mode without broadcasting the abort command to other processing modules in the storage controller and without pausing any hardware components, including any hardware components of the HIM module.
At block 712, the comparator may receive a HIM context command from an arbiter module to start a transfer of an associated data packet from the host to the buffer pool. At block 714, in response to receiving the HIM context command, the comparator, in the abort mode, may compare the programmed command attribute with a command attribute in the received HIM context command.
If the command attributes match, then at block 716 the comparator may determine that the HIM context command is associated with an aborted host write command and not initiate the data transfer. In doing so, the comparator may not store a source address, destination address, length information, or reserve any resources in the buffer pool that may otherwise be reserved for the transfer of data associated with the HIM context command.
At block 718, the comparator may release any resources associated with queuing the HIM context command in the HIM context queue. At block 720, the HIM module may update a counter associated with HIM context command. At block 722, based on the update of the counter, the HIM module may determine if all of the HIM context commands associated with a host write command have been received and processed. If so, then at block 724, the HIM module may issue an interrupt signal indicating that it has received and processed all of the HIM context commands. Issuing an interrupt signal may also cause the comparator to be switched back to the normal mode of operation if it is not in the normal mode already. Referring back to block 722, if all of the HIM context commands associated with the host write command have not been processed, then the method may proceed back to 712 without issuing an interrupt signal, where the comparator may receive another HIM context command from the arbiter module.
Proceeding back to block 714, if the command attributes do not match, then at block 726, the comparator may determine that the HIM context command is not associated with an aborted host write command and may initiate the data transfer, including storing any information related to the data transfer such as the source address, destination address, and length, and reserve any resources for storing the data packet in the buffer pool, and then start the data transfer. The method may then proceed to blocks 718-724 to release any resources associated with queueing the HIM context command, updating a counter, and issuing an interrupt signal if all of the HIM context queues associated with a host write command have been received and processed.
Finally, as mentioned above, any suitable type of memory can be used. Semiconductor memory devices include volatile memory devices, such as dynamic random access memory (“DRAM”) or static random access memory (“SRAM”) devices, non-volatile memory devices, such as resistive random access memory (“ReRAM”), electrically erasable programmable read only memory (“EEPROM”), flash memory (which can also be considered a subset of EEPROM), ferroelectric random access memory (“FRAM”), and magnetoresistive random access memory (“MRAM”), and other semiconductor elements capable of storing information. Each type of memory device may have different configurations. For example, flash memory devices may be configured in a NAND or a NOR configuration.
The memory devices can be formed from passive and/or active elements, in any combinations. By way of non-limiting example, passive semiconductor memory elements include ReRAM device elements, which in some embodiments include a resistivity switching storage element, such as an anti-fuse, phase change material, etc., and optionally a steering element, such as a diode, etc. Further by way of non-limiting example, active semiconductor memory elements include EEPROM and flash memory device elements, which in some embodiments include elements containing a charge storage region, such as a floating gate, conductive nanoparticles, or a charge storage dielectric material.
Multiple memory elements may be configured so that they are connected in series or so that each element is individually accessible. By way of non-limiting example, flash memory devices in a NAND configuration (NAND memory) typically contain memory elements connected in series. A NAND memory array may be configured so that the array is composed of multiple strings of memory in which a string is composed of multiple memory elements sharing a single bit line and accessed as a group. Alternatively, memory elements may be configured so that each element is individually accessible, e.g., a NOR memory array. NAND and NOR memory configurations are exemplary, and memory elements may be otherwise configured.
The semiconductor memory elements located within and/or over a substrate may be arranged in two or three dimensions, such as a two dimensional memory structure or a three dimensional memory structure.
In a two dimensional memory structure, the semiconductor memory elements are arranged in a single plane or a single memory device level. Typically, in a two dimensional memory structure, memory elements are arranged in a plane (e.g., in an x-z direction plane) which extends substantially parallel to a major surface of a substrate that supports the memory elements. The substrate may be a wafer over or in which the layer of the memory elements are formed or it may be a carrier substrate which is attached to the memory elements after they are formed. As a non-limiting example, the substrate may include a semiconductor such as silicon.
The memory elements may be arranged in the single memory device level in an ordered array, such as in a plurality of rows and/or columns. However, the memory elements may be arrayed in non-regular or non-orthogonal configurations. The memory elements may each have two or more electrodes or contact lines, such as bit lines and word lines.
A three dimensional memory array is arranged so that memory elements occupy multiple planes or multiple memory device levels, thereby forming a structure in three dimensions (i.e., in the x, y and z directions, where the y direction is substantially perpendicular and the x and z directions are substantially parallel to the major surface of the substrate).
As a non-limiting example, a three dimensional memory structure may be vertically arranged as a stack of multiple two dimensional memory device levels. As another non-limiting example, a three dimensional memory array may be arranged as multiple vertical columns (e.g., columns extending substantially perpendicular to the major surface of the substrate, i.e., in the y direction) with each column having multiple memory elements in each column. The columns may be arranged in a two dimensional configuration, e.g., in an x-z plane, resulting in a three dimensional arrangement of memory elements with elements on multiple vertically stacked memory planes. Other configurations of memory elements in three dimensions can also constitute a three dimensional memory array.
By way of non-limiting example, in a three dimensional NAND memory array, the memory elements may be coupled together to form a NAND string within a single horizontal (e.g., x-z) memory device levels. Alternatively, the memory elements may be coupled together to form a vertical NAND string that traverses across multiple horizontal memory device levels. Other three dimensional configurations can be envisioned wherein some NAND strings contain memory elements in a single memory level while other strings contain memory elements which span through multiple memory levels. Three dimensional memory arrays may also be designed in a NOR configuration and in a ReRAM configuration.
Typically, in a monolithic three dimensional memory array, one or more memory device levels are formed above a single substrate. Optionally, the monolithic three dimensional memory array may also have one or more memory layers at least partially within the single substrate. As a non-limiting example, the substrate may include a semiconductor such as silicon. In a monolithic three dimensional array, the layers constituting each memory device level of the array are typically formed on the layers of the underlying memory device levels of the array. However, layers of adjacent memory device levels of a monolithic three dimensional memory array may be shared or have intervening layers between memory device levels.
Then again, two dimensional arrays may be formed separately and then packaged together to form a non-monolithic memory device having multiple layers of memory. For example, non-monolithic stacked memories can be constructed by forming memory levels on separate substrates and then stacking the memory levels atop each other. The substrates may be thinned or removed from the memory device levels before stacking, but as the memory device levels are initially formed over separate substrates, the resulting memory arrays are not monolithic three dimensional memory arrays. Further, multiple two dimensional memory arrays or three dimensional memory arrays (monolithic or non-monolithic) may be formed on separate chips and then packaged together to form a stacked-chip memory device.
Associated circuitry is typically required for operation of the memory elements and for communication with the memory elements. As non-limiting examples, memory devices may have circuitry used for controlling and driving memory elements to accomplish functions such as programming and reading. This associated circuitry may be on the same substrate as the memory elements and/or on a separate substrate. For example, a controller for memory read-write operations may be located on a separate controller chip and/or on the same substrate as the memory elements.
One of skill in the art will recognize that this invention is not limited to the two dimensional and three dimensional exemplary structures described but cover all relevant memory structures within the spirit and scope of the invention as described herein and as understood by one of skill in the art.
It is intended that the foregoing detailed description be understood as an illustration of selected forms that the invention can take and not as a definition of the invention. It is only the following claims, including all equivalents, that are intended to define the scope of the claimed invention. Finally, it should be noted that any aspect of any of the preferred embodiments described herein can be used alone or in combination with one another.
