Systems and methods for nand multi-plane and multi-die state signaling

Abstract

This invention relates to a system and method for state signaling in NAND multi-plane and multi-die applications. A method is provided for state signaling in a non-volatile memory comprising multiple logic unit (LUN) arrays, each of the LUNs having a state terminal coupled to a common state terminal of the non-volatile memory and a data bus coupled to a common data bus of the non-volatile memory. The method includes: performing a first set of one or more operations by a first LUN of the plurality of LUNs; completing the first set of one or more operations by the first LUN of the plurality of LUNs; and transmitting a pulse from the first LUN to a controller via the common terminal in response to the completion of the first set of one or more operations.

Description

[0001] Divisional application

[0002] This application is a divisional application of the invention patent application filed on September 17, 2021, with application number 202111094920.0 and entitled "System and Method for NAND Multi-plane and Multi-die State Signaling". Technical Field

[0003] This disclosure generally relates to NAND memory, and more specifically to systems and methods for NAND multi-plane and multi-die status signaling. Background Technology

[0004] Solid-state drives (SSDs) comprise several non-volatile memory devices, such as, but not limited to, NAND flash memory devices controlled by a controller, making the NAND flash memory devices behave like a single hard drive. The NAND flash memory devices are subject to host-initiated I / O operations, such as reading and writing data stored in the NAND flash memory devices. These I / O operations may be initiated based on multiple completely different applications running on one or more hosts. A NAND flash memory device may consist of multiple dies, but a single die can only handle a single I / O operation at any given time, and a memory bus / channel connecting multiple NAND flash devices to a memory controller can only transfer data to a single memory device at any given time. Summary of the Invention

[0005] The exemplary embodiments disclosed herein are intended to solve problems related to one or more of the difficulties presented in the prior art, and additional features are provided that will readily become apparent from the following detailed description taken in conjunction with the accompanying drawings. Exemplary systems, methods, apparatuses, and computer program products are disclosed herein according to various embodiments. However, it should be understood that these embodiments are presented by way of example and are not limiting, and that various modifications to the disclosed embodiments can be made while remaining within the scope of this disclosure, as will be apparent to those skilled in the art to which this disclosure pertains.

[0006] In one aspect, this disclosure relates to a method for NAND multi-plane and multi-die state signaling. The method includes performing a first set of one or more operations by a first LUN of a plurality of logic units (LUNs). In some embodiments, the non-volatile memory includes the plurality of LUNs. In some embodiments, each of the plurality of LUNs includes a state terminal coupled to a common state terminal of the non-volatile memory and a data bus coupled to a common data bus of the non-volatile memory. The method includes completing the first set of one or more operations by the first LUN of the plurality of LUNs. The method includes sending a pulse from the first LUN to a controller via the common terminal in response to completing the first set of one or more operations.

[0007] In another aspect, this disclosure relates to a method for NAND multi-plane and multi-die status signaling. The method includes performing a first set of one or more operations by a first LUN of a plurality of logic units (LUNs). In some embodiments, the non-volatile memory includes the plurality of LUNs. In some embodiments, each of the plurality of LUNs includes a status terminal coupled to a common status terminal of the non-volatile memory and a data bus coupled to a common data bus of the non-volatile memory. The method includes performing a second set of one or more operations by a second LUN of the plurality of LUNs. The method includes completing the first set of one or more operations by the first LUN of the plurality of LUNs. The method includes sending a status message indicating the status of the first LUN via the common status terminal in response to completing the first set of one or more operations.

[0008] The above and other aspects and their embodiments are described in more detail in the drawings, description and claims. Attached Figure Description

[0009] Various exemplary embodiments of the solutions disclosed herein are described in detail below with reference to the accompanying drawings or illustrations. These drawings are provided for illustrative purposes only and merely depict exemplary embodiments of the solutions disclosed herein to facilitate the reader's understanding. Therefore, these drawings should not be construed as limiting the breadth, scope, or applicability of the solutions disclosed herein. It should be noted that these drawings are not necessarily drawn to scale for clarity and ease of illustration.

[0010] Figure 1 Some embodiments of this disclosure illustrate exemplary SSD environments in which the techniques disclosed herein may be implemented.

[0011] Figure 2 An exemplary block diagram of an SSD architecture is illustrated according to some embodiments of this disclosure.

[0012] Figure 3 This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of the present disclosure.

[0013] Figure 4A This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of the present disclosure.

[0014] Figure 4B This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of the present disclosure.

[0015] Figure 5A This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of the present disclosure.

[0016] Figure 5B This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of the present disclosure.

[0017] Figure 5C This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of the present disclosure. Detailed Implementation

[0018] The following description, with reference to the accompanying drawings, describes various exemplary embodiments of the solutions disclosed herein to enable those skilled in the art to make and use the solutions disclosed herein. As will be appreciated by those skilled in the art, various changes or modifications to the examples described herein can be made after reading this disclosure without departing from the scope of the solutions disclosed herein. Therefore, the solutions disclosed herein are not limited to the exemplary embodiments and applications described and illustrated herein. Furthermore, the specific order or hierarchy of steps in the methods disclosed herein is merely exemplary. Based on design preferences, the specific order or hierarchy of steps in the disclosed methods or processes may be rearranged while remaining within the scope of the solutions disclosed herein. Therefore, those skilled in the art will understand that the methods and techniques disclosed herein present various steps or actions in a sample order, and the solutions disclosed herein are not limited to the specific order or hierarchy presented, unless otherwise expressly stated.

[0019] The following acronyms are used throughout this publication:

[0020] DRAM (Dynamic Random Access Memory)

[0021] ESDI Enhanced Small Disk Interface

[0022] FeRAM (Ferroelectric RAM)

[0023] FTL Flash Conversion Layer

[0024] LBA logical block address

[0025] LUN (Logic Unit)

[0026] MRAM (Magnetic Random Access Memory)

[0027] NAND (not AND)

[0028] NVMe high-speed non-volatile memory

[0029] PCI peripheral component interconnect

[0030] PCM phase change memory

[0031] RAM (Random Access Memory)

[0032] SATA Serial Advanced Technology Accessory

[0033] SCSI Component Small Interface

[0034] SRAM (Static Random Access Memory)

[0035] SSD solid-state drive

[0036] USB Universal Serial Bus

[0037] Conventional NAND devices (e.g., each is a semiconductor die) are equipped with ready / busy (sometimes referred to as "ready / busy", "RY / BY", or "R / B#") pins to indicate when the NAND device is processing a PROGRAM or ERASE operation. A controller can determine the ready / busy state of the NAND device by monitoring these pins. If the device is ready to accept a new command (e.g., read, write, etc.), the ready / busy pin will be in a first state (e.g., high). If the device is busy, the ready / busy pin will be in a second state (e.g., low).

[0038] In conventional NAND packages, the ready / busy (sometimes referred to as "ready / busy" or "RY / BY") pins cannot individually indicate the state of each NAND device or plane. For example, a NAND package may comprise multiple NAND devices that are individual semiconductor dies, each with its own ready / busy pin. The ready / busy pin of each NAND die is typically connected to a single ready / busy pin on the NAND package and indicates the combined state of the die. Similarly, for NAND devices incorporating Asynchronous Independent Plane Read (AIPR), the ready / busy pin of the die indicates the combined state of AIPR reads on all planes within a single die. NAND dies are also commonly referred to as logic cells (LUNs), a term used below.

[0039] Furthermore, the ready / busy pin only indicates that an operation has been completed, regardless of whether the operation was successful. Additionally, if multiple commands are issued consecutively to the NAND package, the ready / busy pin will remain busy until all operations are completed. The controller still needs to issue status commands (e.g., send, transmit, etc.) to each of the one or more NAND devices performing the operation (because it cannot determine which of the consecutively issued operations has now been completed) to obtain the pass / fail status of the operation (e.g., for programming or erasing operations). The controller sends status commands to each NAND device performing the operation at the estimated completion time of each operation and periodically sends status commands every polling interval in the absence of operation. However, this introduces a delay from the time the operation is performed to the time the controller sends the status command. For example, if the polling interval is 5 µs, then a status command may be sent up to 5 µs after the operation is completed.

[0040] Therefore, a more efficient mechanism is needed to determine the exact moment when a NAND operation is completed, so as to obtain the operation status (e.g., pass / fail) when there are multiple planes that can operate independently in a LUN and / or multiple LUNs connected to the same ready / busy pin.

[0041] Therefore, the systems and methods discussed in this paper enhance the circuitry within NAND devices to reduce the overhead of status polling from the controller on the NAND bus and to reduce the waiting time for status messages received by the controller.

[0042] In the “first” example, discussed in more detail below, a pulse on the ready / busy pin can indicate the completion of an operation. The controller can monitor the ready / busy pin and, in response to detecting a pulse, can send a multi-LUN multi-plane status command (e.g., as a broadcast signal / command) to all LUNs (e.g., dies) connected to the ready / busy pin to efficiently retrieve the status of all planes and LUNs on the multi-bit data bus (e.g., the DQ pin). Accordingly, the controller knows when at least one LUN has completed its operation based on the pulse on the ready / busy pin, thereby allowing the controller to obtain the status of multiple LUNs and multiple planes within each LUN using a single status command (with minimal or even no delay).

[0043] In the "Second Example," which is discussed in more detail below, status messages are sent autonomously by the NAND device without any explicit status commands from the controller. They are sent serially (e.g., bit-by-bit) on the ready / busy pin itself when a multi-bit data bus (e.g., the DQ pin) is used to transmit data and / or commands. Therefore, the controller can receive status from each of one or more NAND devices without having to wait for any ongoing data transfers to complete, further reducing status reception latency.

[0044] The embodiments disclosed herein address the aforementioned problems and other issues.

[0045] 1. Solid-state drive technology and environment

[0046] To aid in illustrating specific aspects of this disclosure, Figure 1 The illustrations of some embodiments of this disclosure depict exemplary SSD environments in which the techniques disclosed herein can be implemented. Figure 1 As shown, environment 100 includes host 101 and SSD 102. SSD 102 includes host interface 110, controller 120, volatile memory device 130, and non-volatile memory 140. Non-volatile memory 140 (sometimes referred to as "NAND device") includes an array of non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d (sometimes collectively referred to as "LUN" or "NAND device").

[0047] Controller 120 (e.g., an SSD memory controller) communicates with and is operatively coupled to host 101 via host interface 110. Host 101 may be one or more host devices and / or host applications. Host 101 may include any suitable device, such as, but not limited to, computing devices and / or storage devices. In some instances, host 101 may be a user device operated by a user. In some embodiments, host 101 and / or SSD 102 reside in a data center (not shown). The data center includes multiple platforms, each of which may support multiple hosts (e.g., but not limited to host 101) and / or SSD devices (e.g., but not limited to SSD 102).

[0048] The host device (for example) accesses the SSD 102 by sending write and read commands to the SSD 102. Examples of host interface 110 include, but are not limited to, Universal Serial Bus (USB) interface, Serial Advanced Technology Attachment (SATA) interface, Enhanced Small Form Factor (ESDI) interface, Small Component Interface (SCSI), Peripheral Component Interconnect (PCI) interface, High Speed ​​Serial Attached SCSI (SAS) interface, Integrated Drive Electronics (IDE) interface, and / or High Speed ​​Non-Volatile Memory (NVMe) interface. In some embodiments, host interface 110 may be a network interface, and host 101 is connected to the host interface via a network structure that may include multiple network routers, network switches, and such (not shown for clarity). Examples of host interface 110 that is a network interface include, but are not limited to, Ethernet and Fibre Channel (FC).

[0049] SSD 102 includes volatile memory device 130 and non-volatile memory 140. Volatile memory device 130 and non-volatile memory 140 communicate with controller 120. Figure 1 As shown, the controller 120 is connected via a bidirectional multi-bit data bus configured to carry data, address information, and / or command information (in... Figure 1 The non-volatile memory 140 communicates with the device (displayed as "DQ [n:0]"). In some embodiments, 'n' can be any integer, including (for example) 2, 4, 8, 16, 32, 64, or 128.

[0050] The controller 120 also communicates with the non-volatile memory 140 via a ready / busy (sometimes referred to as "ready / busy" or "RY / BY") pin, which the non-volatile memory 140 uses to send ready / busy signals (e.g., voltage levels, voltage levels corresponding to high or low levels, pulses, etc.) indicating when one or more of the non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, or 148a to 148d are performing an operation (e.g., busy, occupied, active, unavailable, etc.) or are ready for the next operation (e.g., idle, unoccupied, inactive, available, etc.).

[0051] The non-volatile memory 140 generates a ready / busy signal based on the ready / busy state of one or more of the non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d. For example, Figure 2 Illustrations based on some embodiments of this disclosure Figure 1An exemplary block diagram of the architecture of the non-volatile memory 140 is provided. As discussed herein, the non-volatile memory 140 includes non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, or 148a to 148d. The ready / busy output of each non-volatile memory die 142a to 142d, 144a to 144d, 146a to 146d, or 148a to 148d is coupled and / or connected via an internal bus to the ready / busy contacts (e.g., balls, pins, leads, pads, etc.) of the non-volatile memory 140. Accordingly, the nonvolatile memory 140 generates (e.g., produces) a ready / busy signal to be sent to the controller 120 via the ready / busy output by combining (e.g., aggregating, summing, etc.) the ready / busy signals from each of the nonvolatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, or 148a to 148d.

[0052] The bidirectional multi-bit data bus of the non-volatile memory 140 is connected and / or coupled to the bidirectional multi-bit data bus of each of the non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d and 148a to 148d via an internal bus.

[0053] Return to reference Figure 1 The input / output (I / O) of the non-volatile memory 140 (e.g., ready / busy pins, each bit of a bidirectional multi-bit data bus, etc.) can each correspond to any type of I / O contact in a semiconductor package. For example, the I / O contact can be a ball on a ball grid array (BGA) package, a pin on a pin grid array (PGA) package, or a lead on a chip carrier package.

[0054] although Figure 1 Not shown, but controller 120 can communicate with nonvolatile memory 140 via any number of buses and / or inputs, including (for example): a chip enable (CE or CE#) input configured to select the means for data transfer with host 101; an address latch enable (ALE) input configured to indicate the bus cycle type (e.g., command, address, and / or data); a read enable (RE or RE#) input configured to facilitate read data transfer; a write enable (WE or WE#) input configured to facilitate write data transfer; and / or a write protect (WP or WP#) input configured to disable flash array programming and / or erase operations.

[0055] In some embodiments, the non-volatile memory 140 may be an array of non-volatile memory devices as shown. The non-volatile memory 140 includes non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d that can be arranged in one or more memory communication channels connected to the controller 120. For example, dies 142a to d may be configured on one memory channel, dies 144a to d may be configured on another memory channel, and so on. Although in Figure 1 The diagram shows 16 non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d and 148a to 148d, but the non-volatile memory 140 of the SSD 102 may include any suitable number of non-volatile memory devices arranged in one or more channels communicating with the controller 120.

[0056] In some embodiments, non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d include NAND flash memory. The NAND flash memory includes flash memory. For example, each NAND flash memory device includes one or more individual NAND flash devices that are non-volatile memory devices capable of retaining data in the event of a power outage. Each of the non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d has one or more planes. Each plane has multiple blocks, and each block has multiple pages. Data can be written sequentially to the pages in a block. Once all pages are written, data cannot be written again until the block is erased, and then the pages can be written to again in sequential order, and so on.

[0057] Although the NAND flash memory device is described as an example of non-volatile memory 140, other examples of non-volatile memory technologies used to implement non-volatile memory storage device 120 include, but are not limited to, magnetic random access memory (MRAM), phase change memory (PCM), ferroelectric RAM (FeRAM), and the like.

[0058] In some embodiments, the volatile memory device 130 includes a volatile memory RAM buffer. In some embodiments, the volatile memory device 130 may be wholly or partially incorporated within a controller. The volatile memory device 130 may be a single device of a single type capable of providing a volatile memory buffer for the SSD 102, or multiple devices of different types. Examples of volatile memory technologies used to implement the volatile memory storage device 130 include, but are not limited to, static random access memory (SRAM) and dynamic random access memory (DRAM), etc.

[0059] Controller 120 can combine raw data storage in non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d, enabling those non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d to function as a single storage device. Controller 120 may include a microcontroller, buffers, error correction functionality, a flash translation layer (FTL), a flash interface layer (FTL), a flash controller, flash management layer software, an address mapping table, and firmware for implementing such functionality, as further described herein. In some arrangements, the software / firmware may be stored in non-volatile memory 140 or any other suitable computer-readable storage medium.

[0060] Controller 120 includes suitable processing and memory capabilities for performing the functions described herein and other functions. For example, controller 120 includes one or more processors (e.g., central processing unit (CPU)) for implementing various functions of SSD 102. As described, controller 120 manages various features of non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d, including but not limited to input / output (I / O) processing, reading, writing, erasing, monitoring, logging, error handling, useless cell collection, wear leveling, logical-to-physical (L2P) address mapping, etc. Therefore, controller 120 provides visibility into non-volatile memory 140 and its associated FTL.

[0061] Controller 120 (e.g., an FTL interface module) can perform logic-to-physical (L2P) operations based on an L2P table. For example, controller 120 can translate a logical block address (LBA) (e.g., an address provided by the host using a block storage protocol such as High-Speed ​​NVM (NVMe) or Serial ATA (SATA)) into a physical address (e.g., a reference to a location within a non-volatile memory die), thus resolving the physical address corresponding to the LBA. In response to receiving a write or read command (containing an LBA) from a host device, controller 120 (e.g., an FTL interface module) can look up the physical address corresponding to the LBA in order to write or read the physical address.

[0062] 2. Apply a pulse to the ready / busy pin.

[0063] Introducing a new state signaling mode, where when the LUN (e.g., Figure 1When the non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d and 148a to 148d in the NAND device complete their operation on any one (e.g., one, more than one or all) in their plane, the NAND device (e.g., Figure 1 The non-volatile memory 140 in the memory sends one or more pulses on the ready / busy pin. The new status signaling mode allows the controller (e.g., Figure 1 The controller 120 detects when at least one plane has completed its operation, thereby allowing the controller 120 to issue status commands to the NAND without delay. The pulse ensures that if multiple commands are sent consecutively to multiple planes in the NAND package or NAND die, each command can be detected upon completion; however, conventionally, the ready / busy pin remains busy until all commands have been completed. The pulse is a brief transition from a first logic state to a second logic state, followed by an almost immediate return to the first state. In some embodiments, the pulse width (the period when in the second logic state) is determined to be no longer than the time required for the controller to detect the pulse, while remaining short enough to minimize the probability that two commands completing at approximately the same time would cause the two completion pulses to merge into a single pulse.

[0064] For example, controller 120 may be configured to generate commands and transmit them via its multidimensional data bus (e.g., Figure 1 The DQ[n:0] in the LUN sends (e.g., provide, transmit, deliver) a command to the non-volatile memory 140. In response to receiving the command, the non-volatile memory 140 enters (e.g., transition, change, configure, initialize, etc.) a new state signaling mode. In some embodiments, the non-volatile memory 140 enters a new state signaling mode by sending (e.g., via an internal bus) a message to one or more of its LUNs, thereby causing one or more LUNs to be configured according to the new state signaling mode.

[0065] Upon entering a new state signaling mode, the non-volatile memory 140 can immediately generate (e.g., produce) a pulse on the ready / busy pin indicating that at least one plane and / or LUN has completed operation. The ready / busy pin is common to one or more LUNs, and any of the LUNs can independently drive the ready / busy pin to a logic state such that the state of the ready / busy pin is a logical combination of individual states driven by the LUNs. For example, the non-volatile memory 140 can cause the ready / busy pin to remain (e.g., sustain, hold, retain, etc.) in a first voltage and / or logic state (e.g., high or low) when idle and / or during NAND operation. When the NAND operation is complete, the non-volatile memory 140 can transition the ready / busy pin to a second alternating voltage and / or logic state (e.g., high or low) within a predetermined amount of time, and then transition the ready / busy pin back to the first voltage and / or logic state. In such operation, the non-volatile memory 140 generates a pulse of a duration (sometimes referred to as "tReady") and / or sends the pulse to the controller 120. In some embodiments, the pulse may correspond to a rapid transient change in the amplitude of a signal from a baseline value to a higher or lower value, followed by a rapid return to the baseline value.

[0066] The controller 120 can be configured to monitor (e.g., detect, observe) the status and / or condition of the ready / busy pin. Accordingly, the controller 120 can receive and / or detect pulses on the ready / busy pin.

[0067] In response to receiving and / or detecting a pulse, controller 120 may determine (based on the pulse) that one or more LUNs have completed one or more operations. In response to receiving and / or detecting a pulse, non-volatile memory 140 may retrieve (e.g., acquire) the status (e.g., pass / fail) of the completed operation by sending one or more status commands to the NAND and / or one or more selected LUNs. The one or more status commands are interpreted by each of the one or more selected LUNs reporting their status. In some embodiments, non-volatile memory 140 sends only the status command corresponding to the detected pulse to the LUN.

[0068] In some embodiments, as discussed in more detail below, the non-volatile memory 140 determines a subgroup of LUNs that may have sent pulses on the ready / busy pins (i.e., may have completed an operation) and sends one or more status commands only to those LUNs.

[0069] In some embodiments, controller 120 may detect only one pulse in the presence of multiple completed instances. For example, if multiple planes and / or multiple LUNs complete their operations simultaneously, their corresponding pulses may overlap in time (e.g., coincidentally) such that controller 120 detects only one pulse. In this example, controller 120 may identify a completed plane and / or LUN by checking the status of all incomplete operations or subgroups of incomplete operations on the ready / busy pin.

[0070] In some embodiments, the controller 120 may send a command via its multidimensional data bus to the non-volatile memory 140 causing it to leave a new state signaling mode and / or enter a default mode of ready / busy pin operation. In some embodiments, the default mode of ready / busy pin operation causes the non-volatile memory 140 to generate a signal on the ready / busy pin of the NAND package indicating a combined state (e.g., ready or busy) of the NAND packaged NAND device and / or LUN.

[0071] 2.1 Obtaining LUN Status via Multi-LUN Status Command

[0072] Controller 120 may be configured to send multiple LUN status commands to LUNs, wherein the multiple LUN status commands are single-byte commands without any LUN or row address. In some embodiments, controller 120 may be configured to send multiple LUN status commands to non-volatile memory devices 140, wherein the LUNs of the memory devices (e.g., non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d) are individually directly interpreted and responded to by the multiple LUN status commands.

[0073] In response to receiving a multi-LUN status command via a chip enable (CE), each LUN on the CE can send its status one after another in the order of its LUN number.

[0074] In some embodiments, the LUN may use the following 2-bit state per plane:

[0075] 00 = No operation.

[0076] 01 = Operation completed successfully.

[0077] 10 = Operation completed incorrectly.

[0078] 11 = Busy operation.

[0079] In some embodiments, LUNs may use other encodings of status with different numbers of status bits. In an instance where 2 bits of status are used per plane and there are 4 planes, 8 bits of status per LUN are expected. With 4 LUNs on the ready / busy pin, there will be 4 status bytes, where the first status byte is sent by LUN0, the second status byte by LUN1, the third status byte by LUN1, and the fourth status byte by LUN1.

[0080] The duration of the status byte allows for gaps between each transmitted data byte (e.g., where the LUN is not transmitting) to avoid overlap when driving status from one LUN to the next. Initially, controller 120 can be configured in each LUN to specify the duration of the status byte when the LUN is supposed to transmit its status byte and / or the time offset from the status command. Controller 120 can be configured to track (e.g., stored in memory) the operations it requests on each plane of each LUN, and thus know which pending operations the status is for when it receives a status bit from the LUN.

[0081] 2.2 Benefits of Multi-LUN State Commands

[0082] Multiple LUN status commands offer advantages over conventional methods. In existing ready / busy operation modes available in conventional NAND devices, controller 120 can know from the ready / busy pin that at least one of the LUNs (e.g., non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d) is busy, but it cannot know whether one of the other LUNs has completed its operation. However, by using multiple LUN status commands, controller 120 can detect when at least one LUN has completed its operation, and controller 120 can then issue a status command to the LUN with minimal or even no delay.

[0083] For example, in a conventional NAND device, the command sequence for retrieving the state of a plane in a LUN is as follows:

[0084] (1)Command_78h, 3-byte-row-address, Twhr, 1-byte-status

[0085] Command_78h is a command byte with the hexadecimal number 78, which tells the NAND send plane the status corresponding to the given row address.

[0086] Where tWHR is the amount of time to wait after the send line address before reading the status.

[0087] The command sequence (1) has a total of 5 bytes transmitted on the NAND bus.

[0088] Conversely, in some embodiments, the sequence of multiple LUN states may be as follows:

[0089] (2) Multi-LUN status command byte, tWHR, all LUN 4-byte status

[0090] All LUN 4-byte states can be composed of LUN0 1-byte state, LUN1 1-byte state, LUN2 1-byte state and / or LUN3 1-byte state.

[0091] The multi-LUN status sequence can also be 5 bytes on the bus. Therefore, in the same or nearly the same bus transfer time spent on the status of one plane in a conventional NAND device, under this new multi-LUN status command, the controller 120 can detect the status of all planes on all LUNs, and / or retrieve the status of one or more completed operations. Since the controller 120 initiates read operations across multiple planes and LUNs, the status may indicate the completion of more than one operation after data output from one or more NAND devices, reducing the number of status commands to less than one per operation.

[0092] 2.3 Obtaining LUN Status via Multi-CE Multi-LUN Status Command

[0093] The multi-LUN status command can be extended to support retrieving the status of multiple chip-enabled (CE) LUNs. For this reason, the controller 120 can configure (e.g., adjust) the delay of the multi-LUN status command when LUNs (e.g., non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d) send their status, so that, according to the embodiments discussed herein, the status is sent for the LUN of CE0, and then the LUN in CE1 begins after a gap following the last LUN of CE0, and / or the LUN in CE2 begins after a gap following the last LUN of CE1, and so on. Under this configuration, the controller 120 can then send the multi-LUN status command to the LUNs of multiple CEs simultaneously. For example, if controller 120 wants to obtain (e.g., acquire, retrieve) the status of all LUNs in CE0 and CE1, it can enable CE0 and CE1 when issuing a multi-LUN status command and obtaining the status of all LUNs in CE0 followed by the status of all LUNs in CE1. In this example, in some embodiments, the proposed multi-LUN status command sequence can be sent with CE0 and CE1 enabled, as follows:

[0094] (3) Multi-LUN status command byte, tWHR, CE0 all LUN 4-byte status, CE1 all LUN 4-byte status

[0095] 2.4 Requested LUN Status Command :

[0096] In some embodiments, a multi-CE multi-LUN status command may have one or more bytes in the command sequence specifying which LUNs on which CEs will report status. Accordingly, each device may be configured to use a unique reporting LUN number across all CEs.

[0097] In some embodiments, only the requested LUN will be reported. In some embodiments, the requested LUNs will be reported sequentially from the lowest reporting LUN to the highest reporting LUN. In some embodiments, the requested LUNs will be reported sequentially from the highest reporting LUN to the lowest reporting LUN. For example, the reporting LUN number can be a combination of the CE number and the LUN numbers within the CE (in any order). As in conventional NAND, each device may already know its LUN number within the CE. Controller 120 may initially configure (e.g., initialize, send, etc.) the reporting LUN number of LUN0 in the CE to the devices connected to the CE. Then, one or more devices in the CE can calculate (e.g., determine, evaluate) their unique reporting LUN number by adding their LUN number to the reporting LUN number of LUN0.

[0098] In some embodiments, a multi-LUN status command can specify the LUN whose status will be reported by sending a report request bitmap in a command sequence, where bit number 'k' indicates the LUN whose report LUN number is 'k'. For example, in the case of 4 LUNs per CE and 2 CEs, the report bitmap can have bits 0 to 3 indicating LUNs 0 to 3 of CE 0, and bits 4 to 7 indicating LUNs 0 to 3 of CE 1. In this example, to obtain the status of LUN 1 of CE-0 and LUNs 1 and 2 of CE-1, the report bitmap could be 62h (hexadecimal 62).

[0099] In some embodiments, the proposed multi-LUN state command sequence may be as follows:

[0100] (4) Multi-LUN state command byte, 62h, tWHR, CE-0 LUN1 state, CE-1 LUN1 state, CE-1 LUN2 state

[0101] 2.5 LUN Status Transmitted by LUN Using Only One DQ Bit :

[0102] NAND may have at least eight DQ pins configured to transmit one byte of state at a time (e.g., Figure 2 In the embodiments described herein, each LUN can send its status one LUN at a time using all DQ pins, and the status is sent one LUN after another.

[0103] In this alternative embodiment using 8 DQ pins, the state can be sent in parallel by up to 8 LUNs, each LUN driving its own dedicated DQ pin.

[0104] In some embodiments, if there are more than 8 LUNs, the next group of 8 LUNs can send their status after the first group of 8 LUNs has finished sending their status. Thus, status can be sent in groups of 8 LUNs.

[0105] 2.6 Additional Examples :

[0106] The controller 120 can initially set the following parameters in each LUN via commands of the set feature type:

[0107] tStatusByte period: The duration for which the status of the LUN should be sent.

[0108] tStartOffsetTime: How long after the tWHR wait period should this LUN begin its tStatusByte period. This value can be zero for the first LUN.

[0109] Then, in the command sequence, after tWHR, each LUN may wait for its tStartOffsetTime and / or send its status within the duration tStatusByte.

[0110] In some embodiments, the controller 120 may configure a different value for tStartOffsetTime for each LUN, such that LUNs do not overlap during their transmission states. For example, this tStartOffsetTime may be set as follows for the case of 4 LUNs:

[0111] LUN 0: tGap0

[0112] LUN 1: tGap0 + tStatusByte + tGap1

[0113] LUN 2: tGap0 + tStatusByte + tGap1 + tStatusByte + tGap2

[0114] LUN 3: tGap0 + tStatusByte + tGap1 + tStatusByte + tGap2 + tStatusByte + tGap3

[0115] Where tGap0 is the gap between the end of tWHR and the first data.

[0116] ; where tGapk (where k = 1, 2, 3) is the required gap between LUN k-1 and LUN k.

[0117] tGapk can be determined based on the delay from each LUN to the controller 120 on the board.

[0118] 3. Automatically send LUN status

[0119] In some embodiments, the non-volatile memory 140 may be configured to autonomously send status on the ready / busy pin without needing to receive status commands from the controller 120. In some embodiments, the non-volatile memory 140 may send status bit by bit in a serial manner.

[0120] In some embodiments, the controller 120 may be configured to track (e.g., store, record) the operations it requests on each plane of each LUN, and thus know which pending operations the status is for when it receives a status bit from the LUN.

[0121] This method (embodiment) of independently sending status information on the ready / busy pin of the non-volatile memory 140 without receiving status commands from the controller 120 reduces the latency of receiving and processing status information. For example, considering a data output transfer performed for LUN0 during the specified time, LUN1 reads the sensing completion and independently sends its ready status to the controller 120. The controller 120, with separate hardware for processing status information in parallel with the data transfer, can process the status and create a command sequence for the data output transfer of LUN1. Then, as soon as the LUN0 data transfer is complete, the LUN1 data transfer command can be sent. In conventional NAND, after the LUN0 data transfer is complete, the controller 120 sends a status command and receives the status, then processes the status and creates a command sequence for the data output transfer of LUN1. Therefore, in conventional NAND, there is a delay between the command for the end of the LUN0 data transfer and the command for the start of the LUN1 data transfer, and this delay can be avoided by means of this independent (autonomous) status reporting method.

[0122] When only one LUN is present on the ready / busy pin, this method allows the LUN (via non-volatile memory 140) to begin sending status bits as soon as the operation is complete. When there are multiple LUNs connected to the same ready / busy pin (e.g., ... Figure 2 When using LUNs (e.g., multiple dies) that can operate simultaneously, it may be necessary to indicate which LUN sends the status bit and to avoid having more than one LUN driving the ready / busy pin at the same time.

[0123] 3.1 Identification by time slot

[0124] One approach to transmitting multiple LUNs on the same ready / busy pin is to use the time slot of each LUN to transmit the status in a known LUN sequence. For example, when there are 'n' LUNs on the ready / busy pin, the time slot sequence could be LUN 0, LUN 1, ..., LUN n-1. Controller 120 can initially configure (e.g., initialize) each LUN on the ready / busy pin with the LUN's time slot number and / or time slot duration. Then, controller 120 can send a broadcast command (e.g., 'Time slot sequence start') indicating the start of the time slot sequence at the beginning of the first time slot to all LUNs. The broadcast command (e.g., 'Time slot sequence start') can be sent periodically as needed to resynchronize all LUNs.

[0125] When a LUN's time slot begins, the LUN may begin sending its status bits. When the LUN completes its operation, its status may change and / or may be sent when the LUN obtains its next time slot. The LUN may continue to repeatedly send its current status (e.g., busy, ready, success, error) in each of its time slots.

[0126] Since operations on NAND can take tens of microseconds to milliseconds, this can lead to many duplicate transmissions of the same information. To avoid duplicate transmissions, in some embodiments, the LUN may only transmit its state in its time slot if there is a state change compared to its previous time slot. When there is no change compared to its previous time slot, the LUN will not transmit and / or the time slot is idle. As the controller 120 is sending a command to begin operation on the LUN, the controller 120 knows that the LUN will transition from a ready state to a busy state. Therefore, this transition from a ready state to a busy state does not necessarily have to be reported to the controller 120 (but it may), and only the state change from a busy state to a ready state needs to be reported to the controller 120.

[0127] In some embodiments, bits may be sent on the ready / busy pin using any of the known methods (e.g., zeroing), and the bits may optionally have a parity bit for detecting / correcting errors.

[0128] 3.2 Identify by LUN number

[0129] Instead of having a fixed time slot and waiting for it, a LUN can transmit as it changes state from busy to ready. Here, the LUN may first send its unique (e.g., proprietary, corresponding, etc.) report LUN number and then send its status, allowing the controller 120 to know which LUN the status applies to. Typically, there are only a few LUNs (4 or 8) on the NAND bus, and the probability of multiple LUNs terminating simultaneously is very low.

[0130] In some embodiments, to handle situations where multiple LUNs attempt to transmit status simultaneously, the LUNs may use an existing collision detection and avoidance method, such as carrier sense multiple access and collision detection (CSMA / CD).

[0131] 4. A method for implementing exemplary embodiments

[0132] Figure 3 This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of this disclosure. Additional, fewer, or different operations may be performed in the method depending on the specific embodiment. In some embodiments, the operation may be performed by an SSD (or one or more components of the SSD) (e.g., Figure 1 The SSD (102) performs some or all of the operations of method 300. Each operation can be reordered, added, removed, or repeated.

[0133] As shown, in some embodiments, method 300 includes operation 302 where a first LUN of a plurality of logic units (LUNs) performs a first set of one or more operations. In some embodiments, the non-volatile memory includes the plurality of LUNs. In some embodiments, each of the plurality of LUNs includes a state terminal coupled to a common state terminal of the non-volatile memory and a data bus coupled to a common data bus of the non-volatile memory. In some embodiments, method 300 includes operation 304 where a second LUN of the plurality of LUNs performs a second set of one or more operations. In some embodiments, method 300 includes operation 306 where the first LUN of the plurality of LUNs completes the first set of one or more operations. Operation 304 may be omitted if only the first LUN is performing the first set of operations at a time. In some embodiments, in addition to the first and second LUNs, there may be additional LUNs among the plurality of LUNs that each perform their own set of operations. In this case, operation 304 may be repeated for each of the additional LUNs among the plurality of LUNs. In some embodiments, method 300 includes sending a pulse from the first LUN to a controller via the common terminal in response to completion of the first group of one or more operations (e.g., Figure 1 Operation 308 of the controller 120 in the middle.

[0134] Figure 4A This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of this disclosure. Additional, fewer, or different operations may be performed in the method depending on the specific embodiment. In some embodiments, the operation may be performed by an SSD (or one or more components of the SSD) (e.g., Figure 1 The SSD 102 in the process performs some or all of the operations of method 400A. Each operation can be reordered, added, removed, or repeated.

[0135] As shown, in some embodiments, method 400A includes operation 402A of a first LUN among a plurality of logic units (LUNs) performing a first set of one or more operations. In some embodiments, the non-volatile memory includes the LUN. In some embodiments, each of the plurality of LUNs includes a status terminal coupled to a common status terminal of the non-volatile memory and a data bus coupled to a common data bus of the non-volatile memory. In some embodiments, method 400A includes operation 406A of the first LUN among the plurality of LUNs completing the first set of one or more operations. In some embodiments, method 400A includes operation 408A of the first LUN autonomously sending a status message indicating the status of the first LUN via the common status terminal in response to completing the first set of one or more operations.

[0136] Figure 4B This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of this disclosure. Additional, fewer, or different operations may be performed in the method depending on the specific embodiment. In some embodiments, the operation may be performed by an SSD (or one or more components of the SSD) (e.g., Figure 1 The SSD (102) performs some or all of the operations of method 400B. Each operation can be reordered, added, removed, or repeated.

[0137] As shown, in some embodiments, method 400B includes operation 402B in which a first LUN of a plurality of logic units (LUNs) performs a first set of one or more operations. In some embodiments, a non-volatile memory includes the LUN. In some embodiments, each of the plurality of LUNs includes a status terminal coupled to a common status terminal of the non-volatile memory and a data bus coupled to a common data bus of the non-volatile memory. In some embodiments, method 400B includes operation 404B in which a second LUN of the plurality of LUNs performs a second set of one or more operations. In some embodiments, method 400B includes operation 406B in which the first LUN of the plurality of LUNs completes the first set of one or more operations. In some embodiments, method 400B includes operation 408B in which the controller sends a multi-LUN status command causing each LUN to send a status message to the controller to the plurality of LUNs. In some embodiments, method 400B includes operation 410B in which the first LUN, in response to the multi-LUN status command, sends a status message indicating the status of the first LUN via the common status terminal in response to completion of the first set of one or more operations. In some embodiments, method 400B includes operation 412B in which the second LUN sends a status message indicating the status of the second LUN via the common status terminal in response to the multi-LUN status command in response to continuing processing (e.g., not completed) of the second group of one or more operations.

[0138] Figure 5A This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of this disclosure. Additional, fewer, or different operations may be performed in the method depending on the specific embodiment. In some embodiments, the operation may be performed by an SSD (or one or more components of the SSD) (e.g., Figure 1 The SSD 102 in the SSD performs some or all of the operations of method 500A. For example, the controller of the SSD (e.g., Figure 1 The controller 120 in the middle executes some or all of the operations of method 500A. Each operation can be reordered, added, removed, or repeated.

[0139] As shown, in some embodiments, method 500A includes operation 502A of a controller monitoring a common state terminal of a non-volatile memory, wherein the non-volatile memory includes a plurality of logic units (LUNs), each having a state terminal coupled to the common state terminal of the non-volatile memory. In some embodiments, method 500A includes operation 504A of the controller detecting a pulse on the common state terminal indicating that one of the plurality of LUNs has completed an operation. In some embodiments, method 500A includes operation 506A of the controller sending a state command to the plurality of LUNs, causing each LUN to send a state message to the controller.

[0140] Figure 5B This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of this disclosure. Additional, fewer, or different operations may be performed in the method depending on the specific embodiment. In some embodiments, the operation may be performed by an SSD (or one or more components of the SSD) (e.g., Figure 1 The SSD 102 in the SSD performs some or all of the operations of method 500B. For example, the controller of the SSD (e.g., Figure 1 The controller 120 in the middle executes some or all of the operations of method 500B. Each operation can be reordered, added, removed, or repeated.

[0141] As shown, in some embodiments, method 500B includes operation 502B of a controller monitoring a common state terminal of a non-volatile memory, wherein the non-volatile memory includes a plurality of logic units (LUNs), each having a state terminal coupled to the common state terminal of the non-volatile memory. In some embodiments, method 500B includes operation 504B of the controller detecting a message on the common state terminal from one of the plurality of LUNs. In some embodiments, method 500B includes operation 506B of the controller decoding the message received on the common state terminal and determining that it instructs the first LUN to complete an operation.

[0142] Figure 5C This is a flowchart depicting a method for NAND multi-plane and multi-die state signaling according to some embodiments of this disclosure. Additional, fewer, or different operations may be performed in the method depending on the specific embodiment. In some embodiments, the operation may be performed by an SSD (or one or more components of the SSD) (e.g., Figure 1 The SSD (102) performs some or all of the operations of method 500C. Each operation can be reordered, added, removed, or repeated.

[0143] As shown, in some embodiments, method 500C includes operation 502C in which a controller sends one or more operations to a first LUN among a plurality of logic units (LUNs), causing the first LUN to perform the one or more operations. In some embodiments, a non-volatile memory includes the plurality of LUNs. In some embodiments, each of the plurality of LUNs includes a state terminal coupled to a common state terminal of the non-volatile memory and a data bus coupled to a common data bus of the non-volatile memory. In some embodiments, method 500C includes operation 504C in which a controller sends one or more operations to a second LUN among the plurality of LUNs, causing the second LUN to perform the second set of one or more operations. In some embodiments, method 500C includes operation 506C in which the controller receives a pulse from the first LUN via the common terminal in response to the first LUN completing the one or more operations.

[0144] The preceding description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will readily become apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects presented herein, but should be given the full scope consistent with the language of the claims, wherein a reference to an element in the singular is not intended to mean “one and only one” (unless specifically stated so), but rather “one or more.” Unless specifically stated otherwise, the term “some” means one or more. All structural and functional equivalents of the elements of the various aspects described throughout the preceding description, as known or subsequently learned by a person skilled in the art, are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be public, whether or not such disclosure is expressly stated in the claims. Claim elements should not be construed as components and functions unless the element is expressly stated using the phrase “component for…”.

[0145] It should be understood that the specific order or hierarchy of steps in the disclosed process is an example of illustrative method. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process may be rearranged while remaining within the scope of the previously described process. The appended method claims present elements of various steps in an exemplary order and are not necessarily intended to limit the scope to the specific order or hierarchy presented.

[0146] The prior description of the disclosed embodiments is provided to enable those skilled in the art to make or use the disclosed object. Various modifications to these embodiments will readily become apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the spirit or scope of the prior description. Therefore, the prior description is not intended to be limited to the embodiments shown herein, but rather to be given the broadest scope consistent with the principles and novel features disclosed herein.

[0147] The various examples illustrated and described are provided merely as examples to illustrate the various features of the claims. However, the features shown and described with respect to any given example are not necessarily limited to the associated example and may be used or combined with other examples shown and described. Furthermore, the claims are not intended to be limited to any single example.

[0148] The foregoing method descriptions and process flowcharts are provided merely as illustrative examples and are not intended to require or imply that the steps in the various examples must be performed in the presented order. As those skilled in the art will understand, the steps in the foregoing examples can be performed in any order. For example, words such as "afterwards," "next," and "next" are not intended to limit the order of steps; these words are merely used to guide the reader in the description of the method. Furthermore, (for example) any reference to an element of the claim in the singular using the articles "a" or "the" should not be construed as limiting the element to the singular.

[0149] The various illustrative logic blocks, modules, circuits, and algorithmic steps described in conjunction with the examples disclosed herein can be implemented as electronic hardware, computer hardware, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various illustrative components, blocks, modules, circuits, and steps have been broadly described above in terms of their functionality. Whether this functionality is implemented in hardware or software depends on the specific application and design constraints imposed on the overall system. Skilled individuals may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as departing from the scope of this disclosure.

[0150] The hardware used to implement the various illustrative logics, logic blocks, modules, and circuits described in conjunction with the examples disclosed herein can be implemented or executed by means of a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but alternatively, it may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a combination of multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, steps or methods may be performed by a circuit system specific to a given function.

[0151] In some exemplary instances, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or codes on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The steps of the methods or algorithms disclosed herein may be embodied in a processor-executable software module residing on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example, but not limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible by a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. The combinations of the above items are also included within the scope of non-transitory computer-readable and processor-readable media. Furthermore, the operation of a method or algorithm may reside as one or a combination or set of code and / or instructions on a non-transitory processor-readable and / or computer-readable storage medium that can be incorporated into a computer program product.

[0152] The foregoing description of the disclosed examples is provided to enable those skilled in the art to make or use this disclosure. Various modifications to these examples will readily become apparent to those skilled in the art, and the general principles defined herein may be applied to some examples without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not intended to be limited to the examples shown herein but should be given the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A solid-state drive (SSD) comprising: Non-volatile memory (NVM) has multiple memory devices; A controller for causing the plurality of memory devices in the NVM to perform corresponding operations; A status contact, located between the controller and the NVM, wherein each of the plurality of memory devices is commonly connected to the status contact; and A mechanism through which each of the plurality of memory devices provides the controller with an independent completion status of its corresponding operation via the status contact.

2. The SSD of claim 1, wherein the plurality of memory devices comprises a plurality of memory dies.

3. The SSD of claim 2, wherein each of the plurality of memory dies has an RDY / BSY pin connected to the status contact.

4. The SSD of claim 2, wherein the plurality of memory dies are configured to be connected in parallel to an array of a plurality of channels of the status contact, and the plurality of dies are connected in parallel to each of the channels.

5. The SSD of claim 1, wherein the plurality of memory devices comprises a plurality of planes of a memory die, each plane being connected in parallel to the status contacts.

6. The SSD of claim 1, further comprising a multi-bit bidirectional memory bus between the controller and the NVM, wherein the status contacts are separate from the memory bus, and wherein the plurality of memory devices are further commonly connected to the memory bus.

7. The SSD of claim 6, wherein the mechanism comprises each of the plurality of memory devices being configured to: Execute a corresponding set of the operations in response to a command sent by the controller via the memory bus; Complete the corresponding set in the operation; and In response to the completion of the corresponding set of operations, a pulse is sent to the controller via the status contact.

8. The SSD of claim 7, wherein the NVM comprises a first memory device and a second memory device among the plurality of memory devices, and wherein the first memory device is configured to send the pulse while the second memory device is busy performing a corresponding set of the operations.

9. The SSD of claim 8, wherein the first memory device and the second memory device comprise a first plane and a second plane of a plurality of planes in a single die.

10. The SSD of claim 8, wherein the mechanism further comprises the controller being configured to: Receive the pulse via the status contact; and In response to receiving the pulse, a status request is broadcast to the plurality of memory devices via the memory bus.

11. The SSD of claim 10, wherein the mechanism further comprises each of the plurality of memory devices being configured to: The status request is received via the memory bus; In response to the first memory device receiving the status request, a first status message indicating the status of the first memory device is sent via the memory bus and in a predetermined order through the first memory device; and In response to the second memory device receiving the status request, a second status message indicating the status of the second memory device is sent via the memory bus and in the predetermined order by the second memory device.

12. The SSD of claim 11, wherein the predetermined order is based on a first memory device report number associated with the first memory device and a second memory device report number associated with the second memory device.

13. The SSD of claim 11, wherein the second memory device sends the second status message after the first memory device sends the first status message, and wherein the mechanism further comprises each of the plurality of memory devices being configured to: Receive messages indicating one or more status message formats from the controller via the memory bus. The second memory device sends the second status message based on one or more status message formats to prevent the first status message from overlapping with the second status message.

14. The SSD of claim 13, wherein the one or more status message formats include at least one of the duration of the status message or the time offset by which the LUN sends the status message after receiving the status request from the controller.

15. The SSD of claim 11, wherein the first memory device and the second memory device are associated with a first chip enable, and wherein the third memory device of the plurality of memory devices is associated with a second chip enable, and wherein the mechanism further comprises each of the plurality of memory devices being configured to: In response to the third memory device receiving the status request, a third status message indicating the status of the third memory device is sent via the memory bus and according to the predetermined order. The third memory device sends the third status message based on one or more status message formats to prevent overlap between status messages associated with the first chip enable and status messages associated with the second chip enable.

16. The SSD of claim 8, wherein sending the pulse to the controller causes the controller to send a status request via the memory bus, and wherein the mechanism further comprises each of the plurality of memory devices being configured to: The status request is received via the memory bus, wherein the memory bus includes multiple pins; In response to the corresponding memory device receiving the status request, the corresponding status message among a plurality of status messages indicating the status of the corresponding memory device is sent via a corresponding pin of the memory bus through each of the plurality of memory devices.

17. The SSD of claim 11, wherein the predetermined order is based on a first time slot associated with the first memory device and a second time slot associated with the second memory device.

18. The SSD of claim 10, wherein the mechanism further comprises each of the plurality of memory devices being configured to: Receive the status request via the memory bus; and In response to the corresponding memory device receiving the status request, a corresponding status message indicating the status of the corresponding memory device is sent via the status contact.

19. The SSD of claim 19, wherein the mechanism further comprises each of the plurality of memory devices being configured to: To prevent the corresponding status message from conflicting with other status messages sent to the status contact by other memory devices through the plurality of memory devices.

20. The SSD of claim 6, wherein the mechanism comprises each of the plurality of memory devices being configured to: Execute a corresponding set of the operations in response to a command sent by the controller via the memory bus; Complete the corresponding set in the operation; and In response to the completion of the corresponding set of operations, a status message comprising multiple bits is serially sent to the controller via the status contact.

Images