KR102675509B1 - Memory controller and operating method thereof - Google Patents

Abstract

This technology relates to electronic devices. A memory controller that determines the risk of a storage device based on retry information of operations performed on the memory device and outputs information about the risk of the storage device controls the memory device. In the memory controller, the memory controller includes a retry command for re-performing a failed operation based on fail information received from the memory device and retry information indicating the number of retry operations performed by the memory device. It includes a fail control unit that generates and a telemetry log data control unit that generates telemetry log data indicating the state of a storage device including the memory device based on the retry information.

Description

Memory controller and its operating method {MEMORY CONTROLLER AND OPERATING METHOD THEREOF}

The present invention relates to electronic devices, and more specifically, to a memory controller and a method of operating the same.

A storage device is a device that stores data under the control of a host device such as a computer, smartphone, or smart pad. Depending on the device that stores data, storage devices include devices that store data on magnetic disks such as hard disk drives (HDD), semiconductor memory, such as solid state drives (SSD) and memory cards, etc. In particular, it includes devices for storing data in non-volatile memory.

The storage device may include a memory device that stores data and a memory controller that stores data in the memory device. Memory devices can be divided into volatile memory and non-volatile memory. Here, non-volatile memory includes ROM (Read Only Memory), PROM (Programmable ROM), EPROM (Electrically Programmable ROM), EEPROM (Electrically Erasable and Programmable ROM), flash memory, PRAM (Phase-change RAM), and MRAM (Magnetic RAM). , RRAM (Resistive RAM), FRAM (Ferroelectric RAM), etc.

Embodiments of the present invention provide a memory controller and a method of operating the same that can determine the risk of a storage device based on retry information of an operation performed on the memory device and output information about the risk of the storage device.

A memory controller according to an embodiment of the present invention is a memory controller that controls a memory device, wherein the memory controller includes a retry command for re-performing a failed operation based on fail information received from the memory device and the A fail control unit that generates retry information indicating the number of retry operations performed by the memory device, and a telemetry unit that generates telemetry log data indicating the state of the storage device including the memory device based on the retry information. It may include a tree log data control unit.

A method of operating a memory controller according to an embodiment of the present invention includes: receiving fail information from the memory device indicating that an operation performed by the memory device has failed; Generating a retry command for re-performing a failed operation performed by the memory device based on fail information and retry information regarding the number of retry operations performed by the memory device, and retrying the memory device based on the retry information. It may include generating telemetry log data indicating the state of a storage device including the memory device.

A host according to an embodiment of the present invention controls a plurality of storage devices, wherein the host performs a retry operation performed by the plurality of storage devices when an operation performed by the plurality of storage devices fails. Outputs a telemetry log data request requesting telemetry log data generated based on the number of times to the plurality of storage devices, and transmits telemetry log data received in response to the telemetry log data request. Based on this, risk information indicating the need for a flush operation is generated in the plurality of storage devices, and the risk information is output to at least one of the plurality of storage devices.

According to the present technology, when an operation performed on a memory device fails, retry information is generated based on the number of retry operations related to the failed operation, and information about the risk of the device is generated based on the retry information. By outputting, operations can be performed according to the risk level of the storage device.

1 is a block diagram for explaining a storage device.
Figure 2 is a diagram for explaining storage devices and a system management bus connected to a host.
Figure 3 is a diagram to explain a case where a plurality of storage devices are connected to one bus.
Figure 4 is a diagram for explaining lines of the system management bus.
FIG. 5 is a diagram for explaining the configuration of the memory controller of FIG. 1 for generating telemetry log data.
Figure 6 is a diagram for explaining information included in telemetry log data.
Figure 7 is a diagram for explaining an embodiment of storing risk information.
Figure 8 is a diagram for explaining another embodiment of storing risk information.
FIG. 9 is a diagram illustrating a process in which the host outputs a flush request based on risk information before outputting the request to the storage device.
FIG. 10 is a diagram illustrating the rate of flush light determined according to a flush request output by the host.
FIG. 11 is a diagram for explaining the structure of the memory device of FIG. 1.
Figure 12 is a diagram for explaining a memory block.
Figure 13 is a diagram for explaining the operation of the host, memory controller, and memory device in the present invention.
Figure 14 is a diagram for explaining the operation of a host according to an embodiment of the present invention.
Figure 15 is a diagram for explaining the operation of a memory controller according to an embodiment of the present invention.
Figure 16 is a diagram for explaining the operation of a host according to an embodiment of the present invention.
FIG. 17 is a diagram for explaining another embodiment of the memory controller of FIG. 1.
Figure 18 is a block diagram showing a memory card system to which a storage device according to an embodiment of the present invention is applied.
Figure 19 is a block diagram illustrating an SSD (Solid State Drive) system to which a storage device according to an embodiment of the present invention is applied.
Figure 20 is a block diagram showing a user system to which a storage device according to an embodiment of the present invention is applied.

Specific structural and functional descriptions of the embodiments according to the concept of the present invention disclosed in this specification or application are merely illustrative for the purpose of explaining the embodiments according to the concept of the present invention, and the implementation according to the concept of the present invention The examples may be implemented in various forms and should not be construed as limited to the embodiments described in this specification or application.

Hereinafter, embodiments of the present invention will be described with reference to the attached drawings in order to explain in detail enough to enable those skilled in the art of the present invention to easily implement the technical idea of the present invention. .

1 is a block diagram for explaining a storage device.

Referring to FIG. 1 , the storage device 50 may include a memory device 100 and a memory controller 200.

The storage device 50 stores data under the control of the host 300, such as a mobile phone, smartphone, MP3 player, laptop computer, desktop computer, game console, TV, tablet PC, or in-vehicle infotainment system. It could be a device.

The storage device 50 may be manufactured as one of various types of storage devices depending on the host interface, which is a communication method with the host 300. For example, the storage device 50 is a multimedia card in the form of SSD, MMC, eMMC, RS-MMC, micro-MMC, and secure digital in the form of SD, mini-SD, and micro-SD. Card, USB (universal storage bus) storage device, UFS (universal flash storage) device, PCMCIA (personal computer memory card international association) card type storage device, PCI (peripheral component interconnection) card type storage device, PCI-E ( It may be composed of any one of various types of storage devices, such as a PCI express) card type storage device, compact flash (CF) card, smart media card, memory stick, etc.

The storage device 50 may be manufactured in any one of various types of package forms. For example, the storage device 50 may include package on package (POP), system in package (SIP), system on chip (SOC), multi chip package (MCP), chip on board (COB), and wafer-level (WFP). It can be manufactured in any one of various types of package forms, such as fabricated package (WSP), wafer-level stack package (WSP), etc.

The memory device 100 can store data. The memory device 100 operates in response to control by the memory controller 200. The memory device 100 may include a memory cell array including a plurality of memory cells that store data. A memory cell array may include a plurality of memory blocks. Each memory block may include a plurality of memory cells, and the plurality of memory cells may configure a plurality of pages. In an embodiment, a page may be a unit for storing data in the memory device 100 or reading data stored in the memory device 100. A memory block may be a unit for erasing data.

In an embodiment, the memory device 100 includes double data rate synchronous dynamic random access memory (DDR SDRAM), low power double data rate4 (LPDDR4) SDRAM, graphics double data rate (GDDR) SDRAM, low power DDR (LPDDR), and RDRAM. (Rambus Dynamic Random Access Memory), NAND flash memory, Vertical NAND, NOR flash memory, resistive random access memory (RRAM), phase change memory (phase-change memory: PRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), spin transfer torque random access memory (STT-RAM), etc. This can be. For convenience of explanation, this specification will assume that the memory device 100 is a NAND flash memory.

The memory device 100 may be implemented as a two-dimensional array structure or a three-dimensional array structure. Below, a three-dimensional array structure is described as an example, but the present invention is not limited to the three-dimensional array structure. The present invention can be applied to a flash memory device in which the charge storage layer is composed of a conductive floating gate (FG), as well as a charge trap flash (CTF) in which the charge storage layer is composed of an insulating film.

In an embodiment, the memory device 100 may operate in a single level cell (SLC) method that stores one data bit in one memory cell. Alternatively, the memory device 100 may operate by storing at least two data bits in one memory cell. For example, the memory device 100 has a multi-level cell (MLC) that stores two data bits in one memory cell, and a triple-level cell (TLC) that stores three data bits in one memory cell. Alternatively, it can operate in a quadruple level cell (QLC) method that can store four data bits.

The memory device 100 is configured to receive commands and addresses from the memory controller 200 and access a region selected by the address in the memory cell array. That is, the memory device 100 can perform an operation corresponding to a command for an area selected by an address. For example, the memory device 100 may perform a write operation (program operation), a read operation, or an erase operation depending on the received command. For example, when a program command is received, the memory device 100 will program data in an area selected by the address. When a read command is received, the memory device 100 will read data from the area selected by the address. When an erase command is received, the memory device 100 will erase data stored in the area selected by the address.

The memory controller 200 may control the overall operation of the storage device 50.

When a power voltage is applied to the storage device 50, the memory controller 200 can execute firmware (FW). When the memory device 100 is a flash memory device 100, the memory controller 200 includes firmware such as a flash translation layer (FTL) to control communication between the host 300 and the memory device 100. You can run .

In an embodiment, the memory controller 200 receives data and a logical block address (LBA) from the host 300, and uses the logical block address (LBA) to store data included in the memory device 100. It may include firmware (not shown) that can convert the address of memory cells into a physical block address (PBA). Additionally, the memory controller 200 may store a physical-physical address mapping table that configures the mapping relationship between logical block addresses (LBA) and physical block addresses (PBA) in the buffer memory. .

The memory controller 200 may control the memory device 100 to perform a program operation, read operation, or erase operation according to a request from the host 300. For example, when a program request is received from the host 300, the memory controller 200 changes the program request into a program command and sends the program command, physical block address (PBA), and data to the memory device 100. ) can be provided. When a read request along with a logical block address is received from the host 300, the memory controller 200 changes the read request to a read command, selects a physical block address corresponding to the logical block address, and then executes the read command and the physical block address. (PBA) may be provided to the memory device 100. When an erase request along with a logical block address is received from the host 300, the memory controller 200 changes the erase request to an erase command, selects a physical block address corresponding to the logical block address, and then executes the erase command and the physical block address. (PBA) may be provided to the memory device 100.

In an embodiment, the memory controller 200 may generate program commands, addresses, and data on its own, without a request from the host 300, and transmit them to the memory device 100. For example, the memory controller 200 sends commands, addresses, and data to a memory device to perform background operations such as program operations for wear leveling and program operations for garbage collection. It can be provided as (100).

In an embodiment, the memory controller 200 may include a fail control unit 210. The fail control unit 210 may control failed operations among operations performed by the memory device 100. The operation performed by the memory device 100 may be a program operation, a read operation, or an erase operation.

Specifically, when an operation performed by the memory device 100 fails, the fail control unit 210 may receive fail information from the memory device 100. The fail control unit 210 may output a retry command to the memory device 100 to re-perform the failed operation based on the fail information. At this time, the retry command may be a command instructing to re-perform the failed program operation, failed read operation, or failed erase operation. Accordingly, the memory device 100 may re-perform the failed operation in response to the retry command.

In an embodiment, the fail control unit 210 may generate retry information indicating the number of times a retry command has been output. That is, the fail control unit 210 may generate a retry command to re-perform the failed operation and generate retry information regarding the number of retry operations performed until the failed operation is passed. The generated retry information may be transmitted to the telemetry log data control unit 220.

In an embodiment, the telemetry log data control unit 220 may generate telemetry log data based on retry information received from the fail control unit 210. Telemetry log data may include information about the risk of the storage device 50. The risk level of the storage device 50 may mean that the power will be turned off soon, an error may occur, or there may be a conflict between operations between storage devices. In an embodiment, the risk level of the storage device 50 may be determined based on the number of times a retry operation is performed.

Specifically, telemetry log data may include a bus connecting the storage device 50 and the host 300, the number of devices, device functions, and telemetry bits. The telemetry bit is information about the risk of the storage device 50 and can be determined according to the number of times a retry operation has been performed. For example, if the number of retry operations performed by the memory device 100 is 1, the telemetry bit is '00', and if the number of retry operations performed by the memory device 100 is less than 5, the telemetry bit is set to '00'. The tree bit may be '01', and if the number of retry operations performed by the memory device 100 is 6 or more, the telemetry bit may be '10'.

In an embodiment, telemetry log data may be output to the host 300 and/or the device risk determination unit 230.

In an embodiment, the memory controller 200 may include a device risk determination unit 230. The device risk determination unit 230 may determine the risk of the storage device 50 including the memory controller 200 based on telemetry log data. At this time, the memory controller 200 can only determine the risk level of the storage device 50 including the memory controller 200, and can determine the risk level of other storage devices connected to the host 300.

In an embodiment, the device risk determination unit 230 may determine the risk of the storage device 50, generate risk information, and output the risk information to the host 300.

In another embodiment, the memory controller 200 may not include the device risk determination unit 230. In this case, the host 300 may determine the risk level of the storage device 50 based on the telemetry log data received from the telemetry log data control unit 220. The host 300 may also determine the risk level of other storage devices based on telemetry log data received from other storage devices. At this time, the host 300 can determine the risk level of all devices connected to the host 300.

In an embodiment, the storage device 50 may further include a buffer memory (not shown). The memory controller 200 may control data exchange between the host 300 and a buffer memory (not shown). Alternatively, the memory controller 200 may temporarily store system data for controlling the memory device 100 in a buffer memory. For example, the memory controller 200 may temporarily store data input from the host 300 in a buffer memory, and then transmit the data temporarily stored in the buffer memory to the memory device 100.

In various embodiments, the buffer memory may be used as an operation memory or cache memory of the memory controller 200. The buffer memory may store codes or commands that the memory controller 200 executes. Alternatively, the buffer memory may store data processed by the memory controller 200.

In embodiments, the buffer memory is Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM), DDR4 SDRAM, Low Power Double Data Rate4 (LPDDR4) SDRAM, Graphics Double Data Rate (GDDR) SDRAM, Low Power DDR (LPDDR), or RDRAM. It can be implemented as dynamic random access memory (DRAM) such as (Rambus Dynamic Random Access Memory) or static random access memory (SRAM).

In various embodiments, the buffer memory may be connected external to storage device 50. In this case, volatile memory devices connected to the outside of the storage device 50 may serve as a buffer memory.

In an embodiment, the memory controller 200 may control at least two memory devices. In this case, the memory controller 200 may control memory devices according to an interleaving method to improve operating performance.

The host 300 supports USB (Universal Serial Bus), SATA (Serial AT Attachment), SAS (Serial Attached SCSI), HSIC (High Speed Interchip), SCSI (Small Computer System Interface), PCI (Peripheral Component Interconnection), and PCIe ( PCI express), NVMe (NonVolatile Memory express), UFS (Universal Flash Storage), SD (Secure Digital), MMC (Multi-Media Card), eMMC (embedded MMC), DIMM (Dual In-line Memory Module), RDIMM ( It is possible to communicate with the storage device 50 using at least one of various communication methods such as Registered DIMM (Registered DIMM), LRDIMM (Load Reduced DIMM), etc.

In an embodiment, a plurality of storage devices may be connected to the host 300. That is, the host 300 can communicate with a plurality of storage devices.

For example, the host 300 may receive information about the operation of storage devices from the storage devices and determine the level of risk of the storage devices. The risk of storage devices may mean that the power of the storage devices will soon be turned off, an error may occur, or there may be a conflict between operations between the storage devices. In an embodiment, the risk level of storage devices may be determined based on the number of times a retry operation is performed.

The host 300 may determine the risk of storage devices and output risk information regarding the risk of storage devices. Additionally, the host 300 may request the risk information stored in the storage device 50, receive the risk information, and determine a flush write rate for a subsequent operation based on the received risk information.

Figure 2 is a diagram for explaining storage devices and a system management bus connected to a host.

Referring to FIG. 2, FIG. 2 shows the connection relationship between the host 300 and storage devices 50_1 to 50_4. In FIG. 2, it is assumed that the number of storage devices connected to the host 300 is four. In other embodiments, fewer or more storage devices may be connected to the host 300. Additionally, in another embodiment, in addition to storage devices, other components such as a universal serial bus (USB) and a graphics card may be connected to the host 300.

In an embodiment, the host 300 connects the first storage device 50_1 to the first bus BUS1, the second storage device 50_2 to the second bus BUS2, and the third bus BUS3 to the first storage device 50_1. 3 The storage device 50_3 may be connected to the fourth storage device 50_4 through the fourth bus BUS4. The first to fourth storage devices 50_1 to 50_4 can store data.

In an embodiment, the host 300 may communicate with the first to fourth storage devices 50_1 to 50_4 through the first to fourth buses BUS1 to 4.

For example, the host 300 outputs requests and data or requests to the first to fourth storage devices 50_1 to 50_4 through the first to fourth buses BUS1 to 4, and stores the first to fourth storage devices 50_1 to 50_4. Devices 50_1 to 50_4 may store data received from the host 300 or output the stored data to the host 300 in response to a request received from the host 300.

In an embodiment, the host 300 connects the first to fourth storage devices 50_1 to 50_4 through the first to fourth system management buses (SMBUS1 to 4) in addition to the first to fourth buses (BUS1 to 4). can be connected That is, the host 300 connects the first storage device 50_1 through the first system management bus (SMBUS1), the second storage device 50_2 through the second system management bus (SMBUS2), and the third system management bus (SMBUS3). ) can be connected to the third storage device 50_3, and can be connected to the fourth storage device 50_4 through the fourth system management bus (SMBUS4). The first to fourth system management buses SMBUS1 to 4 may be dedicated buses for transmitting or receiving specific information of the first to fourth storage devices 50_1 to 50_4, respectively.

For example, the first to fourth system management buses (SMBUS1 to 4) transmit or receive at least one of temperature information, backup information, recovery information, and background information of the first to fourth storage devices (50_1 to 50_4). It could be a bus for. At this time, the recovery information is information indicating whether the first to fourth storage devices (50_1 to 50_4) are in a state in which the error can be recovered when an error occurs in the first to fourth storage devices (50_1 to 50_4). You can.

Accordingly, according to the request of the host 300, the first storage device 50_1 is connected to the first storage device 50_1 through the first system management bus SMBUS1, and the second storage device 50_2 is connected to the second storage device 50_2 through the second system management bus SMBUS2. The third storage device 50_3 may output specific information to the host 300 through the third system management bus (SMBUS3), and the fourth storage device 50_4 may output specific information to the host 300 through the fourth system management bus (SMBUS4).

Figure 3 is a diagram to explain a case where a plurality of storage devices are connected to one bus.

Referring to FIGS. 2 and 3, in FIG. 3, the first selector 500 is connected to the host 300 through the first bus (BUS1) and the first system management bus (SMBUS1), and the first selector 500 Since it is the same as FIG. 2 except that the 1A storage device 50_1A or the 1B storage device 50_1B is connected through , description of content overlapping with FIG. 2 will be omitted.

In an embodiment, multiple storage devices may be connected to one bus. That is, the host 300 can be connected to multiple storage devices through one bus. At this time, one of the storage devices connected to the host may be selected by a selector and connected to the host.

Figure 3 shows two storage devices, for example, a 1A storage device 50_1A and a 1B storage device ( 50_1B) shows a configuration connected to the host 300. However, in other embodiments, other configurations such as fewer or more storage devices or fewer or more universal serial buses (USBs), graphics cards, etc. may be connected to the first bus (BUS1). ) and can be connected to the host 300 through the first selector 500 connected to the first system management bus (SMBUS1).

In addition, although not shown in this drawing, a second bus (BUS2) and a second system management bus (SMBUS2), a third bus (BUS3) and a third system management bus (SMBUS3), a fourth bus (BUS4), and a fourth bus (BUS2) A plurality of devices may also be connected through second to fourth selectors respectively connected to the system management bus (SMBUS4). Additionally, the number of devices connected through the second to fourth selectors may be the same or different from each other.

Referring to FIG. 3 , the host 300, the 1A storage device 50_1A, and the 1B storage device 50_1B may be connected to each other through the first selector 500. Specifically, the host 300 and the first selector 500 are connected through a first bus (BUS1) and a first system management bus (SMBUS1), and the first selector 500 and the first storage device 1A (50_1A) It is connected through the 1_A bus (BUS1_A) and the 1_A system management bus (SMBUS1_A), and the first selector 500 and the 1B storage device 50_1B are connected to the 1_B bus (BUS1_B) and the 1_B system management bus (SMBUS1_B). It can be connected through .

In an embodiment, the host 300 may output a request and data or a request to the first selector 500 through the first bus (BUS1). After determining the storage device corresponding to the request, the first selector 500 may connect the storage device.

For example, when the storage device corresponding to the request output by the host 300 is the 1A storage device 50_1A, that is, the host 300 makes a program request, read request, or erase request to the 1A storage device 50_1A. When any one of them is output, the first selector 500 may transmit the request and data or request to the 1A storage device 50_1A through the 1_A bus (BUS1_A). The 1A storage device 50_1A may perform operations corresponding to requests and data or requests received through the 1_A bus (BUS1_A).

Likewise, if the storage device corresponding to the request output by the host 300 is the 1B storage device 50_1B, the first selector 500 stores the request and data or request through the 1_B bus BUS1_B. It can be transmitted to device (50_1B). The 1B storage device 50_1B may perform operations corresponding to requests and data or requests received through the 1_B bus (BUS1_B).

In an embodiment, the 1_A system management bus (SMBUS1_A) and the 1_B system management bus (SMBUS1_B) are dedicated buses for transmitting or receiving specific information, similar to the 2nd to 4th system management buses (SMBUS2 to 4). You can.

That is, as described in FIG. 2, the 1_A system management bus (SMBUS1_A) is the 1A storage device (50_1A), the 1_B system management bus (SMBUS1_B) is the temperature information, backup information, and backup information of the 1B storage device (50_1B). It may be a bus for transmitting or receiving at least one of recovery information and background information. At this time, the recovery information is information that allows the 1A storage device 50_1A or the 1B storage device 50_1B to recover the error when an error occurs in the 1A storage device 50_1A or the 1B storage device 50_1B. This may be information indicating the status.

Accordingly, if the request of the host 300 is to obtain specific information about the first storage device 50_1A, the first system management bus (SMBUS1) connecting the host 300 and the first selector 500 is used. The request from the host 300 is output to the first selector 500, and the first selector 500 may transmit the request to the 1A storage device 50_1A through the 1_A system management bus (SMBUS1_A). In response to a request from the host 300, the 1A storage device 50_1A may output specific information to the host 300 through the 1_A system management bus (SMBUS1_A) and the first system management bus (SMBUS1).

If the request of the host 300 is to obtain specific information about the first storage device 50_1B, the first system management bus (SMBUS1) connecting the host 300 and the first selector 500 is connected. The request from the host 300 is output to the first selector 500, and the first selector 500 may transmit the request to the 1B storage device 50_1B through the 1_B system management bus (SMBUS1_B). In response to a request from the host 300, the 1B storage device 50_1B may output specific information to the host 300 through the 1_B system management bus (SMBUS1_B) and the first system management bus (SMBUS1).

As a result, the host 300 can be connected to a storage device through a bus, and in this case, one storage device or a plurality of storage devices can be connected to one bus. When a plurality of storage devices are connected to one bus, one of the plurality of storage devices can be selected by a selector.

Figure 4 is a diagram for explaining lines of the system management bus.

2 to 4, FIG. 4 shows a clock line (CLOCK_LINE) and a data line (DATA_LINE) of the system management bus (SMBUS). That is, the system management bus (SMBUS) in FIG. 4 may be any one of the first to fourth system management buses (SMBUS1 to 4) and the 1_A and 1_B system management buses (SMBUS1_A, B) in FIGS. 2 and 3. there is.

In an embodiment, the system management clock signal (SM_CLOCK) may be output to the storage device through the clock line (CLOCK_LINE) of the system management bus (SMBUS). The system management clock signal (SM_CLOCK) may be a signal that repeats high and low states at regular intervals.

When the storage device receives the system management clock signal (SM_CLOCK) through the clock line (CLOCK_LINE), the storage device hosts telemetry log data (TLD) through the data line (DATA_LINE) (300 in FIG. 2). ) can be output. In an embodiment, the storage device may output telemetry log data (TLD) to the host (300 in FIG. 2) when the system management clock signal (SM_CLOCK) changes from a high state to a low state. .

In embodiments, telemetry log data (TLD) may include information regarding the risk of storage devices including memory controllers and memory devices. The risk level of a device can mean that the power is about to be turned off, an error has occurred, or there is a conflict between operations between devices. In an embodiment, the risk level of a device may be determined based on the number of times a retry operation is performed. Telemetry log data (TLD) will be described in more detail with reference to FIG. 6.

FIG. 5 is a diagram for explaining the configuration of the memory controller of FIG. 1 for generating telemetry log data.

Referring to FIG. 5 , the memory controller 200 of FIG. 5 may include a fail control unit 210, a telemetry log data control unit 220, and a device risk determination unit 230. In another embodiment, the device risk determination unit 230 may not be included in the memory controller 200.

In an embodiment, the memory device 100 may perform an operation corresponding to a request from the host 300. The request from the host 300 may be one of a program request, a read request, or an erase request, and an operation corresponding to each request may be a program operation, a read operation, or an erase operation.

An operation performed by the memory device 100 in response to a request from the host 300 may not pass and may fail. That is, any one of the program operation, read operation, or erase operation may fail. In this case, the memory device 100 may output fail information (FAIL_INF) indicating that the operation has failed to the memory controller 200.

In an embodiment, the fail control unit 210 may receive fail information (FAIL_INF). When the fail control unit 210 receives the fail information (FAIL_INF), the fail control unit 210 may output a retry command (RETRY_CMD) to the memory device 100 to re-perform the failed operation. The retry command (RETRY_CMD) may be any one of a command for re-performing a program operation, a command for re-performing a read operation, or a command for re-performing an erase operation.

For example, if the retry command (RETRY_CMD) is a command to re-perform a program operation, the retry command (RETRY_CMD) is a command that instructs the program operation to a word line other than the word line where the failed program operation was performed. You can. If the retry command (RETRY_CMD) is a command for performing a read operation again, the retry command (RETRY_CMD) may be a command that instructs a read operation with a read voltage different from the read voltage used in the failed read operation. If the retry command (RETRY_CMD) is a command to perform an erase operation again, the retry command (RETRY_CMD) may be a command that instructs an erase operation with an erase voltage different from the erase voltage used in the failed erase operation.

In an embodiment, the memory device 100 may perform an operation corresponding to the retry command (RETRY_CMD). If the operation corresponding to the retry command (RETRY_CMD) also fails, the fail control unit 210 may output a new retry command (RETRY_CMD) based on the received fail information (FAIL_INF). At this time, the fail control unit 210 may output a preset number of retry commands to the memory device 100.

The fail control unit 210 generates a number indicating the number of times the retry command (RETRY_CMD) has been output, that is, the number of times the memory device 100 has performed a retry operation corresponding to the retry command (RETRY_CMD) to process a failed operation. Try information (RETRY_INF) can be generated. Retry information (RETRY_INF) may be output to the telemetry log data control unit 220.

In an embodiment, the telemetry log data control unit 220 may generate telemetry log data (TLD) based on retry information (RETRY_INF). Telemetry log data (TLD) may include telemetry bits indicating the risk of a storage device including the memory controller 200 and the memory device 100. The risk of a storage device may mean that the power will be turned off soon, an error may occur, or a conflict between operations between storage devices may occur. In an embodiment, the telemetry bit may be determined based on the number of times a retry operation is performed.

Furthermore, the telemetry log data (TLD) additionally includes information about the bus connecting the storage device including the memory controller 200 and the memory device 100 and the host 300, the number of devices, and the function of the device. can do.

In an embodiment, when the memory controller 200 includes the device risk determination unit 230, the telemetry log data control unit 220 outputs telemetry log data (TLD) to the device risk determination unit 230. can do. The device risk determination unit 230 may determine the device risk of a storage device including the memory controller 200 and the memory device 100 based on telemetry log data (TLD).

For example, based on telemetry log data (TLD), the device risk determination unit 230 determines whether the temperature of the storage device is high, whether a backup is needed, whether an error can be recovered, and whether a background operation is performed. You can determine whether it is necessary. At this time, the device risk level can only determine the risk level for the storage device in question, but cannot determine the risk level for other devices connected to the host 300. The device risk determination unit 230 may determine the risk of the storage device, generate risk information (RISK_INF), and output the generated risk information (RISK_INF) to the host 300. The host 300 may control the next operation to be performed on the storage device based on risk information (RISK_INF).

For example, if the memory controller 200 includes a device risk determination unit 230, the risk information (RISK_INF) generated by the device risk determination unit 230 is output to the host 300, and the host 300 A request may be made to store information in at least one of a plurality of storage devices connected to the host 300. When risk information (RISK_INF) is stored in at least one of the plurality of storage devices, the host 300 outputs a risk information request to the storage device in which the risk information (RISK_INF) is stored before outputting the next request to the storage device, The host 300 may receive risk information (RISK_INF) from the corresponding storage device. Before outputting the next request, the host 300 may determine whether to perform a flush operation on the storage device based on risk information (RISK_INF) and then output a flush request to the storage device. At this time, the flush request may be output to all storage devices connected to the host 300.

If the risk information (RISK_INF) is not stored in at least one of the plurality of storage devices connected to the host 300, the host 300 receives the risk information (RISK_INF) from the device risk determination unit 230 and then Before outputting the request, it is possible to determine whether to perform a flush operation on the storage device based on risk information (RISK_INF) and then output the flush request to the storage device.

In an embodiment, the memory controller 200 may not include the device risk determination unit 230. In this case, the host 300 may output a telemetry log data request (TLD_REQ) to the storage device to determine the risk level of devices connected to the host 300.

For example, the telemetry log data control unit 220 may receive a telemetry log data request (TLD_REQ) from the host 300. The telemetry log data control unit 220 may output telemetry log data (TLD) in response to a request from the host 300. Afterwards, the host 300 may determine the risk level of the storage device based on telemetry log data (TLD).

In an embodiment, the host 300 may receive telemetry log data from various devices connected to the host 300. The host 300 can control devices based on received telemetry log data.

For example, if any of the telemetry log data indicates an emergency situation, the host 300 sends a flush request to flush commands queued in each storage device before outputting a program, read, or erase request. can be output.

The ratio of flush lights according to flush requests will be explained in more detail with reference to FIG. 10.

Figure 6 is a diagram for explaining information included in telemetry log data.

Referring to FIG. 6, the first column of FIG. 6 represents the bus number (BUS#) connecting the host (300 in FIG. 1) and the device, the second column represents the device number (DEVICE#) of the device connected through the bus, The third column is the function of the device (FUNCTION), the fourth column is the telemetry bit (TELEMETRY BIT), and the fifth column is telemetry log data output from the device to the host (300 in FIG. 1). TLD) is shown. The telemetry bit (TELEMETRY BIT) is information about the risk of a storage device (50 in FIG. 1) and can be determined according to the number of times a retry operation has been performed.

In the embodiment, it is assumed that the host (300 in FIG. 1) and the devices are connected through the first to third buses (BUS1 to 3). In FIG. 6, it is assumed that all devices connected to the host (300 in FIG. 1) through a bus are storage devices. In another embodiment, devices other than storage devices may be connected to the host (300 in FIG. 1) through a bus.

In an embodiment, three devices are connected to the host (300 in FIG. 1) through the first bus (BUS1), and two devices are connected to the host (300 in FIG. 1) through the second bus (BUS2). A host (300 in FIG. 1) and one device can be connected through the third bus (BUS3).

At this time, the bus number (BUS#) representing the first bus (BUS1) is '1', the bus number (BUS#) representing the second bus (BUS2) is '2', and the bus number representing the third bus (BUS3) is '2'. The number (BUS#) may be '3'.

Additionally, the device number (DEVICE#) indicating the storage devices connected through the first bus (BUS1) may be '1', '2', or '3' in the order in which they are connected to the host (300 in FIG. 1). Likewise, the device number (DEVICE#) indicating the storage devices connected through the second bus (BUS2) may be '1' or '2' in the order in which they are connected to the host (300 in FIG. 1). Since there is only one storage device connected through the third bus (BUS3), the device number (DEVICE#) indicating the storage device connected through the third bus (BUS3) may be '1'.

In an embodiment, data representing the function (FUNCTION) of a device may be set for each device. For example, if the device connected to the host (300 in FIG. 1) through a bus is a storage device, the data representing the function of the device is '1' and connected to the host (300 in FIG. 1) through the bus. If the device is a graphics card, the data representing the function (FUNCTION) of the device is '2', and if the device connected to the host (300 in FIG. 1) through the bus is USB (universal serial bus), the data representing the function (FUNCTION) of the device is '2'. ) may be '3'.

In another embodiment, the types of devices connected to the host (300 in FIG. 1) through a bus may vary, and data corresponding to the function of the device may be set for each type of device.

In an embodiment, a telemetry bit (TELEMETRY BIT) may indicate information about the risk of a storage device (50 in FIG. 1). The risk level of a storage device (50 in FIG. 1) may mean that the power will soon be turned off, an error may occur, or a conflict between operations between storage devices may occur. The telemetry bit (TELEMETRY BIT) may be set based on the number of retry operations performed by the storage device.

For example, if the number of retry operations performed by the memory device 100 is 1, the telemetry bit is '00', and if the number of retry operations performed by the memory device 100 is less than 5, the telemetry bit is set to '00'. The tree bit may be '01', and if the number of retry operations performed by the memory device 100 is 6 or more, the telemetry bit may be '10'.

Once the bus number (BUS#), device number (DEVICE#), device function (FUNCTION), and telemetry bit (TELEMETRY BIT) are determined, the telemetry log data control unit (220 in FIG. 1) records the telemetry log. Data (TELEMETRY LOG DATA, TLD) can be created.

In an embodiment, telemetry log data (TLD) may be generated to include a bus number (BUS#), a device number (DEVICE#), a function of the device (FUNCTION), and a telemetry bit (TELEMETRY BIT). For example, the highest bit of the telemetry log data (TLD) is set as the telemetry bit (TELEMETRY BIT), and the subsequent bits are the bus number (BUS#), device number (DEVICE#), and device function ( FUNCTION) can be set in order.

For example, in the case of the 11th telemetry log data (TLD11), which is the telemetry log data of the first storage device connected to the first bus (BUS1), the telemetry bit (TELEMETRY BIT) is '00', and the bus The number (BUS#) is '1', the device number (DEVICE#) is '1', and the data corresponding to the device function (FUNCTION) is '1', so the 11th telemetry log data (TLD11) is '00111'. ' can be created.

For example, in the case of the 12th telemetry log data (TLD12), which is the telemetry log data of the second storage device connected to the first bus (BUS1), the telemetry bit (TELEMETRY BIT) is '01', and the bus The number (BUS#) is '1', the device number (DEVICE#) is '2', and the data corresponding to the device function (FUNCTION) is '1', so the 12th telemetry log data (TLD12) is '01121'. ' can be created.

As described above, the 13th telemetry log data (TLD13) of the third storage device connected to the first bus (BUS1) is '00131', and the 21st telemetry log data (TLD13) of the first storage device connected to the second bus (BUS2) is '00131'. The metrics log data (TLD21) is '10211', the 22nd telemetry log data (TLD22) of the second storage device connected to the second bus (BUS2) is '00221', and the 22nd telemetry log data (TLD22) of the second storage device connected to the third bus (BUS3) is '00221'. The 31st telemetry log data (TLD31) of the storage device may be generated as '00311'.

As a result, telemetry log data (TLD) can be generated on a per-device basis. Telemetry log data (TLD) generated for each device may be output to the host (300 in FIG. 1) in response to a telemetry log data request from the host (300 in FIG. 1). Alternatively, telemetry log data (TLD) generated for each device may be output to the device risk determination unit 230 included in the memory controller 200.

In an embodiment, if the telemetry bit (TELEMETRY BIT) is '00', the host (300 in FIG. 1) may not output a flush request to each storage device after receiving the telemetry log data (TLD). .

However, if the telemetry bit (TELEMETRY BIT) is '01' or '10', the host (300 in FIG. 1) can output a flush request to each storage device after receiving the telemetry log data (TLD). there is. At this time, the ratio of host lights and flush lights corresponding to flush requests may be different.

Figure 7 is a diagram for explaining an embodiment of storing risk information.

Referring to FIG. 7, FIG. 7 shows the first to fourth storage devices 50_1 to 50_4 and the host 300 after receiving a telemetry log data request (TLD_REQ) from the host (300 in FIG. 5). ) shows the operation.

In FIG. 7, it is assumed that the number of storage devices connected to the host 300 is four. In other embodiments, the number of storage devices connected to host 300 may be fewer or more. In addition, the first to fourth telemetry log data (TLD1 to 4) output from the first to fourth storage devices (50_1 to 50_4) and the risk information (RISK_INF) output from the host 300 are the system of FIG. 2. Can be output through the management bus (SMBUS1~4).

In an embodiment, the first to fourth storage devices 50_1 to 50_4 each send the first to fourth telemetry log data TLD1 to 4 in response to a telemetry log data request from the host 300. It can be output as (300). As explained in FIG. 6, the first to fourth telemetry log data (TLD1 to 4) include a bus number (BUS#), device number (DEVICE#), device function (FUNCTION), and telemetry bit, respectively. (TELEMETRY BIT) may be included.

When the first to fourth telemetry log data (TLD1 to 4) are transmitted to the host 300, the host 300 connects each storage device based on the first to fourth telemetry log data (TLD1 to 4). The degree of risk can be determined. At this time, the risk level of the storage device may be determined based on the telemetry bits (TELEMETRY BIT) included in the first to fourth telemetry log data (TLD1 to 4), respectively. The risk of a storage device may mean that the power will be turned off soon, an error may occur, or a conflict between operations between storage devices may occur.

In an embodiment, the host 300 may determine the risk of a storage device and generate risk information (RISK_INF).

For example, if all telemetry bits included in the first to fourth telemetry log data (TLD1 to 4) received by the host 300 are '00', the host 300 can generate risk information (RISK_INF) indicating that all storage devices are in a normal state.

For example, if at least one of the telemetry bits included in the first to fourth telemetry log data TLD1 to 4 received by the host 300 is '01', the host ( 300) may generate risk information (RISK_INF) indicating that a flush operation is required internally in the storage devices.

For example, if at least one of the telemetry bits included in the first to fourth telemetry log data TLD1 to 4 received by the host 300 is '10', the host ( 300) may generate risk information (RISK_INF) indicating that operations of all storage devices must be urgently completed.

The risk information (RISK_INF) generated by the host 300 is output to at least one of the first to fourth storage devices 50_1 to 50_4, and the storage device that receives the risk information (RISK_INF) can store the information. Risk information (RISK_INF) stored in at least one of the first to fourth storage devices 50_1 to 50_4 may be output to the host 300 when there is a request from the host 300.

Figure 8 is a diagram for explaining another embodiment of storing risk information.

Referring to FIGS. 7 and 8, FIG. 8 shows first to fifth storage devices 50_1 to 50_5 after receiving a telemetry log data request (TLD_REQ) from the host of FIG. 5 (300 in FIG. 5) and The operation of the host 300 is shown.

In FIG. 8, the fifth storage device 50_5 is connected to the host 300, and FIG. 8 is the same as FIG. 7 except that risk information (RISK_INF) is transmitted to the fifth storage device 50_5, so the content overlaps. The explanation will be omitted.

In FIG. 8, it is assumed that the fifth storage device 50_5 only functions to store risk information (RISK_INF) received from the host 300 and output risk information (RISK_INF) at the request of the host 300. .

In an embodiment, the first to fourth storage devices 50_1 to 50_4 each send the first to fourth telemetry log data TLD1 to 4 in response to a telemetry log data request from the host 300. It can be output as (300). As explained in FIG. 7, the first to fourth telemetry log data (TLD1 to 4) include a bus number (BUS#), device number (DEVICE#), device function (FUNCTION), and telemetry bit, respectively. (TELEMETRY BIT) may be included.

When the first to fourth telemetry log data (TLD1 to 4) are transmitted to the host 300, the host 300 connects each storage device based on the first to fourth telemetry log data (TLD1 to 4). You can determine the level of risk and generate and output risk information (RISK_INF).

However, unlike FIG. 7, the host 300 outputs the risk information (RISK_INF) to the fifth storage device 50_5, which stores only the risk information (RISK_INF), rather than to the first to fourth storage devices 50_1 to 50_4. can do. In this case, the fifth storage device 50_5 stores risk information (RISK_INF) and can output the stored risk information (RISK_INF) only when there is a request from the host 300.

FIG. 9 is a diagram illustrating a process in which the host outputs a flush request based on risk information before outputting the request to the storage device.

Referring to FIGS. 7 to 9 , FIG. 9 shows the operations of the host 300 and the first to fourth storage devices 50_1 to 50_4 after the host 300 outputs risk information (RISK_INF) to the storage device. It shows.

In this drawing, the embodiment in which risk information (RISK_INF) is stored in the fifth storage device is omitted, but the content of this drawing can be applied even when risk information (RISK_INF) is stored in the fifth storage device. That is, even if risk information (RISK_INF) is stored in the fifth storage device, the host 300 outputs a risk information request (RISK_INF_REQ) to the fifth storage device and receives risk information (RISK_INF) from the fifth storage device. You can.

Also, in FIG. 7, it is assumed that risk information (RISK_INF) is stored only in the first storage device 50_1. In another embodiment, risk information (RISK_INF) may be stored not only in the first storage device 50_1 but also in other storage devices.

In an embodiment, after the host 300 stores risk information (RISK_INF) in the first storage device 50_1 and before the host 300 outputs the next request to the storage device, the host 300 determines the risk information of the storage device. To determine, a risk information request (RISK_INF_REQ) may be output to the first storage device 50_1. The first storage device 50_1 may provide the stored risk information (RISK_INF) to the host 300 in response to the risk information request (RISK_INF_REQ).

The host 300 may determine whether to output a flush request (FLUSH_REQ) before outputting the next request based on risk information (RISK_INF). For example, if the risk information (RISK_INF) indicates that all storage devices connected to the host 300 are in a normal state, the host 300 may not output the flush request (FLUSH_REQ).

However, if the risk information (RISK_INF) indicates that the storage devices connected to the host 300 internally require a flush operation, or that the operations of all storage devices must be urgently completed, the host 300 performs the flush operation. The request (FLUSH_REQ) can be output to the first to fourth storage devices 50_1 to 50_4. At this time, the ratio of HOST WRITE and FLUSH WRITE corresponding to the flush request (FLUSH_REQ) may be set differently depending on risk information (RISK_INF).

For example, when the risk information (RISK_INF) indicates that the operations of all storage devices must be completed urgently, the flush light ( The rate of FLUSH WRITE can be set relatively high.

The ratio of HOST WRITE and FLUSH WRITE will be explained in more detail with reference to FIG. 10.

FIG. 10 is a diagram illustrating the flush light ratio determined according to the flush request output by the host.

Referring to Figures 9 and 10, Figure 10 shows the ratio of host write (HOST WRITE) and flush write (FLUSH WRITE) performed in each storage device according to the flush request (FLUSH_REQ) of Figure 9. At this time, HOST WRITE refers to an operation corresponding to a request output from the host 300, and FLUSH WRITE is a command queued in the memory controller (200 in FIG. 1) included in the storage device. This means a flush operation for .

In an embodiment, if risk information (RISK_INF) received from the first storage device 50_1 indicates that operations of all storage devices must be urgently completed (Emergency FLUSH), that is, if it indicates that a flush operation must be performed urgently, The ratio of HOST WRITE and FLUSH WRITE corresponding to a flush request (FLUSH_REQ) may be 1:9. That is, after the operation corresponding to the nine commands queued in the memory controller (200 in FIG. 1) is performed, the operation corresponding to the request received from the host 300 may be performed.

However, when the ratio of HOST WRITE and FLUSH WRITE is set to 1:9, the time required to execute commands queued in the memory controller (200 in FIG. 1) increases, resulting in a timeout phenomenon. This may occur. That is, even though an operation corresponding to the request received from the host 300 must be performed within a certain period of time after receiving the request from the host 300, it may not be performed. In this case, the host 300 may output a flush request (FLUSH_REQ) that sets a different ratio between HOST WRITE and FLUSH WRITE to the storage device. In other words, a flush request (FLUSH_REQ) that changes the ratio of HOST WRITE and FLUSH WRITE from 1:9 to the next ratio of 2:8 can be output to the storage device.

As a result, the host 300 can sequentially reduce the flush write rate. The rate of FLUSH WRITE can be reduced until timeouts do not occur.

In an embodiment, if the risk information (RISK_INF) received from the first storage device 50_1 indicates that a flush operation is required internally (Internal FLUSH), that is, if it is determined that a flush operation is required internally although it is not urgent, a flush request is made. The ratio of HOST WRITE and FLUSH WRITE corresponding to (FLUSH_REQ) may be 4:6. That is, after operations corresponding to six commands queued in the memory controller (200 in FIG. 1) are performed, operations corresponding to four requests received from the host 300 may be performed.

However, even when the ratio of HOST WRITE and FLUSH WRITE is set to 4:6, the ratio of HOST WRITE and FLUSH WRITE is set to 1:9. Likewise, a timeout phenomenon may occur. In this case, however, just as when setting the ratio of HOST WRITE and FLUSH WRITE to 1:9, the ratio of HOST WRITE to FLUSH WRITE is set to 4:6. A flush request (FLUSH_REQ) that changes from to 5:5 can be output to the storage device.

As a result, the host 300 can sequentially reduce the flush write rate. The rate of FLUSH WRITE can be reduced until timeouts do not occur.

FIG. 11 is a diagram for explaining the structure of the memory device of FIG. 1.

Referring to FIG. 11 , the memory device 100 may include a memory cell array 110, a peripheral circuit 120, and control logic 130.

The memory cell array 110 includes a plurality of memory blocks BLK1 to BLKz. A plurality of memory blocks (BLK1 to BLKz) are connected to the row decoder 121 through row lines (RL). A plurality of memory blocks (BLK1 to BLKz) may be connected to the page buffer group 123 through bit lines (BL1 to BLn). Each of the memory blocks BLK1 to BLKz includes a plurality of memory cells. In one embodiment, the plurality of memory cells are non-volatile memory cells. Memory cells connected to the same word line can be defined as one page. Accordingly, one memory block may include a plurality of pages.

The row lines RL may include at least one source selection line, a plurality of word lines, and at least one drain selection line.

The memory cells included in the memory cell array 110 include a single level cell (SLC) that stores one data bit each, a multi-level cell (MLC) that stores two data bits, and three cell types. It can be configured as a triple level cell (TLC) that stores two data bits or a quadruple level cell (QLC) that can store four data bits.

The peripheral circuit 120 may be configured to perform a program operation, a read operation, or an erase operation on a selected area of the memory cell array 110 under the control of the control logic 130. The peripheral circuit 120 may drive the memory cell array 110 . For example, the peripheral circuit 120 may apply various operating voltages to the row lines RL and bit lines BL1 to BLn under the control of the control logic 130, or discharge the applied voltages. there is.

The peripheral circuit 120 may include a row decoder 121, a voltage generator 122, a page buffer group 123, a column decoder 124, an input/output circuit 125, and a sensing circuit 126.

The row decoder 121 is connected to the memory cell array 110 through row lines RL. The row lines RL may include at least one source selection line, a plurality of word lines, and at least one drain selection line. In an embodiment, word lines may include normal word lines and dummy word lines. In an embodiment, the row lines RL may further include a pipe select line.

The row decoder 121 is configured to decode the row address (RADD) received from the control logic 130. The row decoder 121 selects at least one memory block among the memory blocks BLK1 to BLKz according to the decoded address. Additionally, the row decoder 121 may select at least one word line of the selected memory block to apply the voltages generated by the voltage generator 122 to at least one word line (WL) according to the decoded address.

For example, during a program operation, the row decoder 121 will apply a program voltage to the selected word lines and a program pass voltage of a lower level than the program voltage to unselected word lines. During a program verify operation, the row decoder 121 will apply a verify voltage to the selected word lines and a verify pass voltage higher than the verify voltage to unselected word lines. During a read operation, the row decoder 121 will apply a read voltage to the selected word lines and a read pass voltage higher than the read voltage to the unselected word lines.

In an embodiment, the erase operation of the memory device 100 is performed on a memory block basis. During an erase operation, the row decoder 121 can select one memory block according to the decoded address. During an erase operation, the row decoder 121 may apply a ground voltage to word lines connected to the selected memory block.

The voltage generator 122 operates in response to control by the control logic 130. The voltage generator 122 is configured to generate a plurality of voltages using an external power voltage supplied to the memory device 100. Specifically, the voltage generator 122 may generate various operating voltages Vop used for program, read, and erase operations in response to the operation signal OPSIG. For example, the voltage generator 122 may generate a program voltage, verification voltage, pass voltage, read voltage, and erase voltage in response to control by the control logic 130.

As an embodiment, the voltage generator 122 may generate an internal power voltage by regulating an external power supply voltage. The internal power voltage generated by the voltage generator 122 is used as the operating voltage of the memory device 100.

As an embodiment, the voltage generator 122 may generate a plurality of voltages using an external power supply voltage or an internal power supply voltage.

For example, the voltage generator 122 includes a plurality of pumping capacitors that receive an internal power voltage, and generates a plurality of voltages by selectively activating the plurality of pumping capacitors in response to control of the control logic 130. will be.

The plurality of generated voltages may be supplied to the memory cell array 110 by the row decoder 121.

The page buffer group 123 includes first to nth page buffers (PB1 to PBn). The first to nth page buffers (PB1 to PBn) are connected to the memory cell array 110 through the first to nth bit lines (BL1 to BLn), respectively. The first to nth page buffers (PB1 to PBn) operate in response to the control of the control logic 130. Specifically, the first to nth page buffers (PB1 to PBn) may operate in response to page buffer control signals (PBSIGNALS). For example, the first to nth page buffers (PB1 to PBn) temporarily store data received through the first to nth bit lines (BL1 to BLn) or, during a read or verify operation, the bit lines The voltage or current of BL1 to BLn can be sensed.

Specifically, during a program operation, the first to nth page buffers (PB1 to PBn) transfer data (DATA) received through the input/output circuit 125 to the first to nth page buffers (PB1 to PBn) when a program voltage is applied to the selected word line. It will be delivered to the selected memory cells through n bit lines (BL1 to BLn). Memory cells of the selected page are programmed according to the transmitted data (DATA). During a program verification operation, the first to nth page buffers (PB1 to PBn) sense the voltage or current received from the selected memory cells through the first to nth bit lines (BL1 to BLn) to generate page data. read

During a read operation, the first to nth page buffers (PB1 to PBn) read data (DATA) from the memory cells of the selected page through the first to nth bit lines (BL1 to BLn), and the read data ( DATA) is output to the input/output circuit 125 under the control of the column decoder 124.

During an erase operation, the first to nth page buffers PB1 to PBn may float the first to nth bit lines BL1 to BLn or apply an erase voltage.

The column decoder 124 can transfer data between the input/output circuit 125 and the page buffer group 123 in response to the column address (CADD). For example, the column decoder 124 exchanges data with the first to nth page buffers (PB1 to PBn) through the data lines (DL) or the input/output circuit 125 through the column lines (CL). You can exchange data with.

The input/output circuit 125 transfers the command (CMD) and address (ADDR) received from the memory controller (200 in FIG. 1) described with reference to FIG. 1 to the control logic 130, or transmits data (DATA) to the column decoder. You can exchange with (124).

During a read operation or verify operation, the sensing circuit 126 generates a reference current in response to the allowable bit signal (VRYBIT) and detects the sensing voltage (VPB) received from the page buffer group 123. A pass signal (PASS) or a fail signal (FAIL) can be output by comparing the reference voltage generated by the and reference current.

The control logic 130 outputs an operation signal (OPSIG), a row address (RADD), page buffer control signals (PBSIGNALS), and a permission bit (VRYBIT) in response to the command (CMD) and address (ADDR) to connect peripheral circuits ( 120) can be controlled. For example, the control logic 130 may control a read operation of the selected memory block in response to a sub-block read command and address. Additionally, the control logic 130 may control an erase operation of the selected sub-block included in the selected memory block in response to the sub-block erase command and address. Additionally, the control logic 130 may determine whether the verification operation passed or failed in response to a pass or fail signal (PASS or FAIL).

Memory cells included in the memory cell array 110 may be programmed to one of a plurality of program states according to data stored in each memory cell. The target program state of the memory cell may be determined as one of a plurality of program states depending on the stored data.

Figure 12 is a diagram for explaining a memory block.

Referring to FIGS. 11 and 12 , FIG. 12 is a circuit diagram showing one memory block BLKa among the plurality of memory blocks BLK1 to BLKz included in the memory cell array 110 of FIG. 11 .

A first select line, word lines, and a second select line arranged in parallel to each other may be connected to the memory block BLKa. For example, word lines may be arranged parallel to each other between first and second select lines. Here, the first select line may be a source select line (SSL), and the second select line may be a drain select line (DSL).

To be more specific, the memory block BLKa may include a plurality of strings connected between the bit lines BL1 to BLn and the source line SL. The bit lines BL1 to BLn may be respectively connected to strings, and the source line SL may be commonly connected to the strings. Since the strings may be configured identically to each other, the string ST connected to the first bit line BL1 will be described in detail as an example.

The string (ST) may include a source select transistor (SST), a plurality of memory cells (F1 to F16), and a drain select transistor (DST) connected in series between the source line (SL) and the first bit line (BL1). You can. One string (ST) may include at least one source select transistor (SST) and at least one drain select transistor (DST), and may also include more memory cells (F1 to F16) than the number shown in the drawing.

The source of the source select transistor (SST) may be connected to the source line (SL), and the drain of the drain select transistor (DST) may be connected to the first bit line (BL1). The memory cells F1 to F16 may be connected in series between the source select transistor (SST) and the drain select transistor (DST). The gates of the source select transistors included in different strings may be connected to the source select line (SSL), the gates of the drain select transistors may be connected to the drain select line (DSL), and the gates of the memory cells F1 to F16 They may be connected to multiple word lines (WL1 to WL16). Among memory cells included in different strings, a group of memory cells connected to the same word line may be referred to as a physical page (PPG). Accordingly, the memory block BLKa may include as many physical pages as the number of word lines WL1 to WL16.

One memory cell can store 1 bit of data. This is commonly called a single level cell (SLC). In this case, one physical page (PPG) can store one logical page (LPG) data. One logical page (LPG) data may include as many data bits as the number of memory cells included in one physical page (PPG). Alternatively, one memory cell can store 2 bits or more of data. This is commonly called a multi-level cell (MLC). In this case, one physical page (PPG) can store data of two or more logical pages (LPG).

Memory cells in which more than 2 bits of data are stored in one memory cell are called multi-level cells (MLC), but recently, as the number of bits of data stored in one memory cell increases, multi-level cells (MLCs) have 2 bits of data. It has come to mean a memory cell in which data is stored. A memory cell that stores 3 bits or more of data is called a triple level cell (TLC), and a memory cell that stores 4 bits or more of data is called a quadruple level cell (QLC). In addition, a memory cell method in which multiple bits of data is stored is being developed, and this embodiment can be applied to the memory device 100 in which two or more bits of data are stored.

In another embodiment, the memory block may have a three-dimensional structure. Each memory block includes a plurality of memory cells stacked on a substrate. These plurality of memory cells are arranged along the +X direction, +Y direction, and +Z direction.

Figure 13 is a diagram for explaining the operation of the host, memory controller, and memory device in the present invention.

Referring to FIG. 13, an operation performed by a memory device (MEMORY DEVICE 100 in FIG. 1) at the request of a host (300 in FIG. 1, HOST) may not pass and may fail. In this case, the memory device (MEMORY DEVICE) may output fail information (FAIL_INF) indicating that the operation has failed to the memory controller (MEMORY CONTROLLER 200 in FIG. 1).

The memory controller (MEMORY CONTROLLER) may generate retry information (RETRY_INF) after receiving fail information (FAIL_INF) from the memory device (MEMORY DEVICE). In an embodiment, the memory controller (MEMORY CONTROLLER) may generate retry information (RETRY_INF) regarding the number of retry operations performed until the failed operation is passed.

Afterwards, the memory controller (MEMORY CONTROLLER) may generate telemetry log data (TLD) based on the retry information (RETRY_INF). Telemetry log data (TLD) may include information about the bus connecting the storage device and the host (HOST), the number of devices, the functionality of the devices, and telemetry bits.

In an embodiment, the telemetry bit is information about the risk of a storage device and may be determined based on the number of times a retry operation has been performed. For example, if the number of retry operations performed by the memory device (MEMORY DEVICE) is 1, the telemetry bit is '00', and if the number of retry operations performed by the memory device (MEMORY DEVICE) is less than 5, the telemetry bit is set to '00'. The telemetry bit may be '01', and if the number of retry operations performed by the memory device (MEMORY DEVICE) is 6 or more, the telemetry bit may be '10'.

After receiving a telemetry log data request (TLD_REQ) from the host (HOST), the memory controller (MEMORY CONTROLLER) sends telemetry log data (TLD) to the host (HOST) in response to the telemetry log data request (TLD_REQ). ) can be output. In other words, telemetry log data (TLD) generated by the memory controller (MEMORY CONTROLLER) can be output to the host (HOST) according to the host's request.

The host (HOST) can generate risk information (RISK_INF) based on telemetry log data (TLD) received from the memory controller (MEMORY CONTROLLER). Risk information (RISK_INF) is information about the risk of storage devices including the MEMORY CONTROLLER and memory devices (MEMORY DEVICE). All storage devices are in a normal state, a state in which a flush operation is required internally, or This may indicate a state in which operations of all storage devices must be completed urgently.

In an embodiment, the risk information (RISK_INF) generated by the host (HOST) is transmitted to the storage device, and the risk information (RISK_INF) is stored in the memory controller (MEMORY CONTROLLER) and/or memory device (MEMORY DEVICE) included in the storage device. It can be saved. At this time, risk information (RISK_INF) may be stored in at least one of the storage devices connected to the host (HOST).

After this, the host (HOST) may output a risk information request (RISK_INF_REQ) to the storage device before outputting the next request to the storage device. The memory controller and/or MEMORY DEVICE included in the storage device can output risk information (RISK_INF) to the host (HOST) in response to the host's risk information request (RISK_INF_REQ). .

The host (HOST) may output a flush request (FLUSH_REQ) based on risk information (RISK_INF) received from the storage device.

For example, if risk information (RISK_INF) indicates that all storage devices connected to the host (HOST) are in a normal state, the host (HOST) may not output a flush request (FLUSH_REQ).

However, if the risk information (RISK_INF) indicates that the storage devices connected to the host (HOST) require a flush operation internally, or that the operations of all storage devices must be completed urgently, the host (HOST) flushes. The request (FLUSH_REQ) can be output to all storage devices connected to the host (HOST). At this time, the ratio of the host light and flush light corresponding to the flush request (FLUSH_REQ) may be set differently depending on the risk information (RISK_INF).

Figure 14 is a diagram for explaining the operation of a host according to an embodiment of the present invention.

Referring to FIG. 14, in step S1401, the host may output a telemetry log data request to the storage device. Telemetry log data is data generated based on retry information and may be data stored in a telemetry log data control unit included in the memory controller. Here, the retry information may be generated based on the number of retry operations performed by the memory device.

In step S1403, the host may determine the risk level of the device based on the received telemetry log data. The risk level of a device may mean that the device's power is about to be turned off, an error has occurred, or there is a conflict between operations between devices.

In step S1405, the host may generate risk information based on the result of determining the risk level of the device and output the risk information to the storage device. At this time, the host outputs risk information to at least one storage device, and the storage device that receives the risk information can store the risk information. The stored risk information can be output upon the host's request.

After this, in step S1407, the host may output a risk information request to the storage device. At this time, the host may output a request for risk information to at least one storage device, similar to when outputting risk information. When the host outputs a risk information request, the host can receive risk information from the storage device.

In step S1409, the host may output a flush request based on risk information received from the storage device. For example, if the risk information indicates that all storage devices connected to the host are in a normal state, the host may not output a flush request. However, if the risk information indicates that storage devices connected to the host are in a state that internally requires a flush operation, or that operations on all storage devices must be completed urgently, the host sends a flush request to all storage devices connected to the host. It can be output as . At this time, the ratio of host lights and flush lights corresponding to flush requests may be set differently depending on risk information.

Figure 15 is a diagram for explaining the operation of a memory controller according to an embodiment of the present invention.

Referring to FIG. 15, in step S1501, the memory controller may receive fail information from the memory device. Fail information may be information output from a memory device when an operation performed by the memory device fails.

In step S1503, the memory controller may output a retry command to the memory device. That is, the memory controller may receive fail information from the memory device and output a retry command to re-perform the failed operation based on the fail information to the memory device. For example, the retry command may be a command that instructs to re-perform a failed program operation, a failed read operation, or a failed erase operation.

After the memory device performs the failed operation again, the failed operation may finally pass or fail. At this time, the memory controller may determine whether the number of retry operations performed by the memory device, that is, the number of retry commands output by the memory controller, exceeds the first reference value (S1505). The first reference value may be set in advance.

In an embodiment, when the number of retry commands output by the memory controller exceeds the first reference value (Y), the memory controller may generate telemetry log data in which the most significant bit is '10'.

For example, telemetry log data may include bus number, device number, device function, and telemetry bits. Additionally, the most significant bit of telemetry log data may be set as a telemetry bit. That is, if the number of retry commands output by the memory controller is greater than or equal to the first reference value, telemetry log data with a telemetry bit of '10' can be generated.

In an embodiment, if the number of retry commands output by the memory controller does not exceed the first reference value (N), that is, if it is less than the reference value, the memory controller may determine whether the number of retry commands output is within the second reference value ( S1509). The second reference value may be set in advance. For example, if the second reference value is '1', the memory controller can determine whether the number of output retry commands is one or less.

Afterwards, if the number of retry commands output by the memory controller is within the second reference value (Y), the memory controller may generate telemetry log data with the most significant bit being '00' (S1511).

However, if the number of retry commands output by the memory controller is not within the second reference value (N), the memory controller may generate telemetry log data with the most significant bit being '01' (S1511). That is, if the number of retry commands output by the memory controller exceeds the second reference value but is less than the first reference value, the memory controller may generate telemetry log data in which the most significant bit is '01'.

Figure 16 is a diagram for explaining the operation of a host according to an embodiment of the present invention.

Referring to FIG. 16, in step S1601, the host may output a risk information request to the storage device and receive risk information corresponding to the risk information request from the storage device. Risk information is generated based on telemetry log data and can indicate the risk level of the storage device.

In an embodiment, the risk level of a storage device may be determined according to telemetry bits included in telemetry log data. For example, if the telemetry bit is '00', the risk level of the storage device indicates that the storage device is in a normal state, and if the telemetry bit is '01', the risk level of the storage device is internally determined by the storage devices. This indicates that a flush operation is required, and if the telemetry bit is '10', the risk level of the storage device may indicate that the operations of all storage devices must be urgently completed.

In step S1603, the host may determine the rate of flush light based on risk information. For example, if risk information received from at least one of the storage devices connected to the host indicates that the operations of all storage devices must be urgently completed, the host may determine the ratio of host writes to flush lights to be 1:9. there is. Additionally, if risk information received from at least one of the storage devices connected to the host indicates that a flush operation is required internally in the storage devices, the host may determine the ratio of host writes and flush writes to be 4:6.

In step S1605, the host may output a flush request requesting to perform a flush operation to the storage device based on the determined ratio of host lights and flush lights. The storage device may perform a flush operation based on the flush request. That is, the storage device can perform operations corresponding to commands queued in the memory controller based on the flush request.

After this, the host can determine whether a timeout occurred during a flush operation corresponding to the flush request (S1607). Here, timeout may mean a case where an operation corresponding to a request received from the host is not performed even though it should be performed within a certain period of time after receiving the request from the host.

If a timeout occurs, the host may determine a new flush rate (S1609). For example, if a timeout occurs after the host determines the ratio of the host light to the flush light as 1:9, the host may determine the next ratio of 2:8 as the ratio of the host light to the flush light. If a timeout occurs after the host determines the ratio of the host light to the flush light as 4:6, the host can determine the next ratio of 5:5 as the ratio of the host light to the flush light.

When the host determines a new flush write rate, the host may again output a flush request corresponding to the rate to the storage device (S1605). in other words. The host may output a flush request back to the storage device so that a flush operation is performed according to the newly determined flush write rate to prevent a timeout.

FIG. 17 is a diagram for explaining another embodiment of the memory controller of FIG. 1.

The memory controller 1000 is connected to a host and a memory device. In response to a request from a host, the memory controller 1000 is configured to access a memory device. For example, the memory controller 1000 is configured to control write, read, erase, and background operations of a memory device. The memory controller 1000 is configured to provide an interface between a memory device and a host. The memory controller 1000 is configured to drive firmware for controlling a memory device.

Referring to FIG. 17, the memory controller 1000 includes a processor (1010), a memory buffer (1020), an error correction unit (ECC) 1030, a host interface (Host Interface) 1040, and a buffer controller (Buffer). It may include a Control Circuit (1050), a Memory Interface (1060), and a Bus (1070).

The bus 1070 may be configured to provide a channel between components of the memory controller 1000.

The processor 1010 can control overall operations of the memory controller 1000 and perform logical operations. The processor 1010 may communicate with an external host through the host interface 1040 and with a memory device through the memory interface 1060. Additionally, the processor 1010 may communicate with the memory buffer 1020 through the buffer controller 1050. The processor 1010 may control the operation of the storage device by using the memory buffer 1020 as an operation memory, cache memory, or buffer memory.

The processor 1010 may perform the function of a flash translation layer (FTL). The processor 1010 may convert a logical block address (LBA) provided by the host into a physical block address (PBA) through a flash translation layer (FTL). The flash translation layer (FTL) can receive a logical block address (LBA) as input and convert it into a physical block address (PBA) using a mapping table. There are several address mapping methods in the flash conversion layer depending on the mapping unit. Representative address mapping methods include the page mapping method, block mapping method, and hybrid mapping method.

In an embodiment, the processor 1010 may generate telemetry log data based on fail information received from a memory device (100 in FIG. 1). The processor 1010 may output telemetry log data to the host (300 in FIG. 1) in response to a request for telemetry log data from the host (300 in FIG. 1).

The host (300 in FIG. 1) may generate risk information regarding the risk of the device based on telemetry log data. Afterwards, the risk information may be stored in the memory buffer 1020 and/or the memory device (100 in FIG. 1) and output to the host (300 in FIG. 1) at the request of the host (300 in FIG. 1).

In an embodiment, the host (300 in FIG. 1) outputs a flush request based on risk information received from various storage devices connected to the host (300 in FIG. 1), and the processor 1010 generates a flush request corresponding to the flush request. A flush command instructing to perform an operation can be generated and output to the memory device (100 in FIG. 1).

Afterwards, when a timeout occurs due to the flush operation, the processor 1010 generates a flush command corresponding to the flush request retransmitted from the host (300 in FIG. 1) and outputs it to the memory device (100 in FIG. 1). You can. At this time, the newly created flush command may be a command instructing to perform a flush operation at a rate different from the rate of the existing flush light.

The processor 1010 is configured to randomize data received from the host. For example, the processor 1010 will randomize data received from the host using a randomizing seed. The randomized data is provided to a memory device as data to be stored and programmed into the memory cell array.

The processor 1010 can perform randomization and derandomization by running software or firmware.

The memory buffer 1020 may be used as an operation memory, cache memory, or buffer memory of the processor 1010. The memory buffer 1020 may store codes and commands executed by the processor 1010. The memory buffer 1020 may store data processed by the processor 1010. The memory buffer 1020 may include static RAM (SRAM) or dynamic RAM (DRAM).

The error correction unit 1030 may perform error correction. The error correction unit 1030 may perform error correction encoding (ECC encoding) based on data to be written to the memory device through the memory interface 1060. Error correction encoded data may be transmitted to a memory device through the memory interface 1060. The error correction unit 1030 may perform error correction decoding (ECC decoding) on data received from the memory device through the memory interface 1060. By way of example, the error correction unit 1030 may be included in the memory interface 1060 as a component of the memory interface 1060.

The host interface 1040 is configured to communicate with an external host under the control of the processor 1010. The host interface 1040 includes USB (Universal Serial Bus), SATA (Serial AT Attachment), SAS (Serial Attached SCSI), HSIC (High Speed Interchip), SCSI (Small Computer System Interface), PCI (Peripheral Component Interconnection), and PCIe. (PCI express), NVMe (NonVolatile Memory express), UFS (Universal Flash Storage), SD (Secure Digital), MMC (Multi-Media Card), eMMC (embedded MMC), DIMM (Dual In-line Memory Module), RDIMM It may be configured to communicate using at least one of various communication methods such as (Registered DIMM), LRDIMM (Load Reduced DIMM), etc.

The buffer controller 1050 is configured to control the memory buffer 1020 under the control of the processor 1010.

The memory interface 1060 is configured to communicate with a memory device under the control of the processor 1010. The memory interface 1060 can communicate commands, addresses, and data with a memory device through a channel.

By way of example, the memory controller 1000 may not include the memory buffer 1020 and the buffer controller 1050.

By way of example, the processor 1010 may control the operation of the memory controller 1000 using codes. The processor 1010 may load codes from a non-volatile memory device (eg, Read Only Memory) provided inside the memory controller 1000. As another example, the processor 1010 may load codes from a memory device through the memory interface 1060.

By way of example, the bus 1070 of the memory controller 1000 may be divided into a control bus and a data bus. The data bus may be configured to transmit data within the memory controller 1000, and the control bus may be configured to transmit control information such as commands and addresses within the memory controller 1000. The data bus and control bus are separated from each other and may not interfere with or affect each other. The data bus may be connected to a host interface 1040, a buffer controller 1050, an error correction unit 1030, and a memory interface 1060. The control bus may be connected to the host interface 1040, processor 1010, buffer controller 1050, memory buffer 1020, and memory interface 1060.

Figure 18 is a block diagram showing a memory card system to which a storage device according to an embodiment of the present invention is applied.

Referring to FIG. 18, the memory card system 2000 includes a memory controller 2100, a memory device 2200, and a connector 2300.

The memory controller 2100 is connected to the memory device 2200. Memory controller 2100 is configured to access memory device 2200. For example, the memory controller 2100 is configured to control read, write, erase, and background operations of the memory device 2200. The memory controller 2100 is configured to provide an interface between the memory device 2200 and a host. The memory controller 2100 is configured to drive firmware for controlling the memory device 2200. The memory device 2200 may be implemented identically to the memory device 100 of FIG. 2 described with reference to FIG. 2 .

By way of example, the memory controller 2100 may include components such as random access memory (RAM), a processing unit, a host interface, a memory interface, and an error correction unit. You can.

The memory controller 2100 can communicate with an external device through the connector 2300. The memory controller 2100 may communicate with an external device (eg, a host) according to a specific communication standard. By way of example, the memory controller 2100 includes USB (Universal Serial Bus), MMC (Multi-Media Card), eMMC (embedded MMC), PCI (peripheral component interconnection), PCI-E (PCI-express), and ATA (Advanced Technology Attachment), Serial-ATA, Parallel-ATA, SCSI (small computer small interface), ESDI (enhanced small disk interface), IDE (Integrated Drive Electronics), Firewire, UFS (Universal Flash Storage), WIFI, It is configured to communicate with an external device through at least one of various communication standards such as Bluetooth, NVMe, etc. Illustratively, the connector 2300 may be defined by at least one of the various communication standards described above.

By way of example, the memory device 2200 may include Electrically Erasable and Programmable ROM (EEPROM), NAND flash memory, NOR flash memory, Phase-change RAM (PRAM), Resistive RAM (ReRAM), Ferroelectric RAM (FRAM), and STT-MRAM. It can be implemented with various non-volatile memory devices such as (Spin-Torque Magnetic RAM).

In an embodiment, the memory controller 2100 may generate telemetry log data based on fail information received from the memory device 2200. The memory controller 2100 may output telemetry log data to the host (300 in FIG. 1) in response to a request for telemetry log data from the host (300 in FIG. 1).

The host (300 in FIG. 1) may generate risk information regarding the risk of the device based on telemetry log data. Thereafter, the risk information may be stored in the memory controller 2100 and/or the memory device 2200 and output to the host (300 in FIG. 1) upon request from the host (300 in FIG. 1).

In an embodiment, the host (300 in FIG. 1) outputs a flush request based on risk information received from various storage devices connected to the host (300 in FIG. 1), and the memory controller 2100 outputs a flush request corresponding to the flush request. A flush command instructing to perform a flush operation may be generated and output to the memory device 2200.

Afterwards, when a timeout occurs due to the flush operation, the memory controller 2100 may generate a flush command corresponding to the flush request retransmitted from the host (300 in FIG. 1) and output it to the memory device 2200. . At this time, the newly created flush command may be a command instructing to perform a flush operation at a rate different from the rate of the existing flush light.

The memory controller 2100 and the memory device 2200 can be integrated into one semiconductor device to form a memory card. For example, the memory controller 2100 and the memory device 2200 are integrated into a single semiconductor device to support a PC card (PCMCIA, personal computer memory card international association), compact flash card (CF), and smart media card (SM, SMC). ), memory cards such as memory sticks, multimedia cards (MMC, RS-MMC, MMCmicro, eMMC), SD cards (SD, miniSD, microSD, SDHC), and universal flash storage (UFS).

Figure 19 is a block diagram illustrating an SSD (Solid State Drive) system to which a storage device according to an embodiment of the present invention is applied.

Referring to FIG. 19, the SSD system 3000 includes a host 3100 and an SSD 3200. The SSD 3200 exchanges a signal (SIG) with the host 3100 through the signal connector 3001 and receives power (PWR) through the power connector 3002. The SSD 3200 includes an SSD controller 3210, a plurality of flash memories 3221 to 322n, an auxiliary power supply 3230, and a buffer memory 3240.

In an embodiment, the SSD controller 3210 may perform the functions of the memory controller (200 in FIG. 1) described with reference to FIG. 1.

The SSD controller 3210 may control a plurality of flash memories 3221 to 322n in response to a signal SIG received from the host 3100. By way of example, the signal SIG may be signals based on the interface of the host 3100 and the SSD 3200. For example, signals (SIGs) include USB (Universal Serial Bus), MMC (Multi-Media Card), eMMC (embedded MMC), PCI (peripheral component interconnection), PCI-E (PCI-express), and ATA (Advanced Technology). Attachment), Serial-ATA, Parallel-ATA, SCSI (small computer small interface), ESDI (enhanced small disk interface), IDE (Integrated Drive Electronics), Firewire, UFS (Universal Flash Storage), WIFI, Bluetooth It may be a signal defined by at least one of interfaces such as , NVMe, etc.

In an embodiment, the SSD controller 3210 may generate telemetry log data based on fail information received from the plurality of flash memories 3221 to 322n. The SSD controller 3210 may output telemetry log data to the host (300 in FIG. 1) in response to a telemetry log data request from the host (300 in FIG. 1).

The host (300 in FIG. 1) may generate risk information regarding the risk of the device based on telemetry log data. Afterwards, the risk information is stored in the SSD controller 3210 and/or a plurality of flash memories 3221 to 322n, and can be output to the host (300 in FIG. 1) upon request from the host (300 in FIG. 1). there is.

In an embodiment, the host (300 in FIG. 1) outputs a flush request based on risk information received from various storage devices connected to the host (300 in FIG. 1), and the SSD controller 3210 responds to the flush request. A flush command instructing to perform a flush operation may be generated and output to a plurality of flash memories 3221 to 322n.

Afterwards, when a timeout occurs due to the flush operation, the SSD controller 3210 generates a flush command corresponding to the flush request retransmitted from the host (300 in FIG. 1) to flush the plurality of flash memories 3221 to 322n. It can be output as . At this time, the newly created flush command may be a command instructing to perform a flush operation at a rate different from the rate of the existing flush light.

The auxiliary power device 3230 is connected to the host 3100 through the power connector 3002. The auxiliary power device 3230 can receive power (PWR) from the host 3100 and charge it. The auxiliary power device 3230 may provide power to the SSD 3200 when power supply from the host 3100 is not smooth. By way of example, the auxiliary power device 3230 may be located within the SSD 3200 or outside the SSD 3200. For example, the auxiliary power device 3230 is located on the main board and may provide auxiliary power to the SSD 3200.

The buffer memory 3240 operates as a buffer memory of the SSD 3200. For example, the buffer memory 3240 temporarily stores data received from the host 3100 or data received from a plurality of flash memories 3221 to 322n, or metadata of the flash memories 3221 to 322n ( For example, a mapping table) can be temporarily stored. The buffer memory 3240 may include volatile memories such as DRAM, SDRAM, DDR SDRAM, LPDDR SDRAM, and GRAM, or non-volatile memories such as FRAM, ReRAM, STT-MRAM, and PRAM.

Figure 20 is a block diagram showing a user system to which a storage device according to an embodiment of the present invention is applied.

Referring to FIG. 20 , the user system 4000 includes an application processor 4100, a memory module 4200, a network module 4300, a storage module 4400, and a user interface 4500.

The application processor 4100 may drive components included in the user system 4000, an operating system (OS), or a user program. By way of example, the application processor 4100 may include controllers, interfaces, graphics engines, etc. that control components included in the user system 4000. The application processor 4100 may be provided as a system-on-chip (SoC).

In an embodiment, the application processor 4100 may generate telemetry log data based on fail information received from the storage module 4400. The application processor 4100 may output telemetry log data to the host (300 in FIG. 1) in response to a request for telemetry log data from the host (300 in FIG. 1).

The host (300 in FIG. 1) may generate risk information regarding the risk of the device based on telemetry log data. Afterwards, the risk information may be stored in the storage module 4400 and output to the host (300 in FIG. 1) upon request from the host (300 in FIG. 1).

In an embodiment, the host (300 in FIG. 1) outputs a flush request based on risk information received from various storage devices connected to the host (300 in FIG. 1), and the application processor 4100 outputs a flush request corresponding to the flush request. A flush command instructing to perform a flush operation may be generated and output to the storage module 4400.

Afterwards, when a timeout occurs due to the flush operation, the application processor 4100 may generate a flush command corresponding to the flush request retransmitted from the host (300 in FIG. 1) and output it to the storage module 4400. . At this time, the newly created flush command may be a command instructing to perform a flush operation at a rate different from the rate of the existing flush light.

The memory module 4200 may operate as the main memory, operating memory, buffer memory, or cache memory of the user system 4000. The memory module 4200 includes volatile random access memory such as DRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, LPDDR SDARM, LPDDR2 SDRAM, LPDDR3 SDRAM, etc., or non-volatile random access memory such as PRAM, ReRAM, MRAM, FRAM, etc. can do. For example, the application processor 4100 and the memory module 4200 may be packaged based on POP (Package on Package) and provided as one semiconductor package.

The network module 4300 can communicate with external devices. By way of example, the network module 4300 may include Code Division Multiple Access (CDMA), Global System for Mobile communication (GSM), wideband CDMA (WCDMA), CDMA-2000, TIME Division Multiple Access (TDMA), and Long Term Evolution (LTE). ), can support wireless communications such as Wimax, WLAN, UWB, Bluetooth, Wi-Fi, etc. By way of example, the network module 4300 may be included in the application processor 4100.

The storage module 4400 can store data. For example, the storage module 4400 may store data received from the application processor 4100. Alternatively, the storage module 4400 may transmit data stored in the storage module 4400 to the application processor 4100. By way of example, the storage module 4400 is a non-volatile semiconductor memory device such as PRAM (Phase-change RAM), MRAM (Magnetic RAM), RRAM (Resistive RAM), NAND flash, NOR flash, and three-dimensional NAND flash. It can be implemented. Illustratively, the storage module 4400 may be provided as a removable storage medium (removable drive) such as a memory card or external drive of the user system 4000.

By way of example, the storage module 4400 may include a plurality of non-volatile memory devices, and the plurality of non-volatile memory devices may operate in the same manner as the memory device described with reference to FIGS. 11 and 12 . The storage module 4400 may operate in the same manner as the storage device 50 described with reference to FIG. 1 .

The user interface 4500 may include interfaces for inputting data or commands into the application processor 4100 or outputting data to an external device. By way of example, the user interface 4500 may include user input interfaces such as a keyboard, keypad, button, touch panel, touch screen, touch pad, touch ball, camera, microphone, gyroscope sensor, vibration sensor, piezoelectric element, etc. there is. The user interface 4500 may include user output interfaces such as a Liquid Crystal Display (LCD), Organic Light Emitting Diode (OLED) display, Active Matrix OLED (AMOLED) display, LED, speaker, monitor, etc.

50: storage device
100: memory device
200: memory controller
210: fail control unit
220: Telemetry log data control unit
230: Device risk determination unit
300: Host

Claims (20)

In a memory controller that controls a memory device, the memory controller:
a fail control unit that generates a retry command for re-performing a failed operation based on fail information received from the memory device and retry information indicating the number of retry operations performed by the memory device; and
A memory controller comprising: a telemetry log data control unit that generates telemetry log data indicating a state of a storage device including the memory device based on the retry information. According to clause 1,
The telemetry log data includes a number of a bus connecting a host and the storage device, a number of the storage device, a function of the storage device, and a telemetry bit generated based on the retry information. The method of claim 2, wherein the telemetry log data is:
When the number of retry operations exceeds a first reference value, a telemetry bit indicating that operations of all devices connected to the host must be urgently completed,
If the number of retry operations is within a second reference value, a telemetry bit indicating that all devices connected to the host are in a normal state,
If the number of retry operations exceeds the second reference value but is less than the first reference value, a memory controller comprising a telemetry bit indicating that all devices connected to the host internally require a flush operation. . The memory controller of claim 1, wherein:
A memory controller further comprising a device risk determination unit that generates risk information indicating whether a flush operation is necessary for the storage device based on the telemetry log data. The method of claim 1, wherein the telemetry log data control unit:
A memory controller that outputs the telemetry log data to the host according to the host's request. According to clause 5,
The memory controller receives and stores risk information generated based on the telemetry log data from the host, and the risk information indicates whether a flush operation is required for the storage device. The memory controller of claim 6, wherein:
A memory controller that receives a flush request output from the host based on the risk information and outputs a flush command corresponding to the flush request to the memory device. The memory controller of claim 7, wherein:
A memory controller characterized in that, upon receiving a new flush request setting a different flush write rate from the host, outputting a flush command corresponding to the new flush request back to the memory device. In a method of operating a memory controller that controls a memory device,
Receiving fail information from the memory device indicating that an operation performed by the memory device has failed;
generating a retry command for re-performing a failed operation performed by the memory device and retry information regarding the number of retry operations performed by the memory device based on the fail information; and
Generating telemetry log data indicating a state of a storage device including the memory device based on the retry information. According to clause 9,
The telemetry log data includes the number of the bus connecting the host and the storage device, the number of the storage device, the function of the storage device, and the telemetry bit generated based on the retry information of the memory controller. How it works. According to clause 9,
A method of operating a memory controller, further comprising generating risk information regarding whether a flush operation is required for the storage device based on the telemetry log data. According to clause 9,
A method of operating a memory controller, further comprising outputting the telemetry log data to the host according to a request from the host. According to clause 12,
receiving and storing risk information generated by the host determining a risk level of the storage device based on the telemetry log data; and
A method of operating a memory controller comprising: outputting the stored risk information to the host according to a request from the host. According to clause 13,
Receiving a flush request output by the host based on the risk information; and
A method of operating a memory controller comprising: outputting a flush command corresponding to the flush request to the memory device. The method of claim 14, wherein in outputting the flush command,
A method of operating a memory controller, wherein upon receiving a new flush request setting a different flush write rate from the host, outputting a flush command corresponding to the new flush request to the memory device. In a host controlling a plurality of storage devices, the host:
When an operation performed by the plurality of storage devices fails, a telemetry log data request requesting telemetry log data generated based on the number of retry operations performed by the plurality of storage devices is sent to the plurality of storage devices. Output to storage devices,
Generate risk information indicating the need for a flush operation in the plurality of storage devices based on telemetry log data received in response to the telemetry log data request, and store the risk information in one of the plurality of storage devices. A host that outputs to at least one. The method of claim 16, wherein the host:
A host, characterized in that outputting a risk information request to obtain the risk information to any one of the plurality of storage devices in which the risk information is stored. The method of claim 17, wherein the host:
A host that determines the status of the plurality of storage devices based on the risk information and outputs a flush request requesting to perform a flush operation on the plurality of storage devices. The method of claim 18, wherein the host:
A host that outputs the flush request by adjusting the ratio of host light and flush light according to the risk information. According to clause 19,
When a timeout occurs during a flush operation corresponding to the flush request, a host outputs a flush request requesting to perform the flush operation at a new rate.

Images