Patent Description:
Recently, as semiconductor technology continues to develop, the performance of computer processors has significantly improved. And, as multi-core processor technology develops, the quantity of operations that may be performed simultaneously in one computer server has significantly increased.

Accordingly, Internet data centers have provided various and reliable services (e.g., a web server, a mail server, a file server, a video server, and cloud server) to different service users by installing hundreds or thousands of computer servers at one place.

However, as the number of tenants (e.g., virtual machines (VMs)) requesting a connection to the data center rapidly increases, the processing conditions for each of the tenants and/or the data of the tenants has diversified. Accordingly, the necessity for a storage device and/or a storage system capable of satisfying the processing conditions for each of the tenants or each of the data of the tenants has emerged.

From <CIT> there are known methods for relating virtual machine security, and more specifically, for providing means of preventing session keys from being compromised even if the private key of a server is compromised.

From <CIT> it is known a system for secure backup and restoration in which data at a primary storage system is encrypted and remote copied to a secondary storage system. A Remote Copy Configuration Information (RCCI) is created that identifies the encryption mechanism, keys, data source volume, and target volume for the remote copy. The RCCI is backed up on a trusted computer system. Upon detection of a failure in the primary storage system, the encrypted data and RCCI are transferred to a tertiary server, which is created upon detection of the failure, and operations of the failed primary server are resumed by the tertiary server. Document <CIT> teaches a storage system where the write data pipeline includes an error-correcting code generator as well as an encryption module. The encryption module receives packets and encrypts them using an encryption key unique to the solid-state storage device, prior to sending the packets to the error correcting codes generator. The error correction codes generator uses an error correcting algorithm to generate check bits which are stored with the data packets.

Aspects of the present invention provide a storage system in which satisfaction for processing conditions for each of a plurality of tenants or each of data of the tenants is improved.

A storage system according to the invention is defined by the independent claims. Advantageous features and further developments are specified in the dependent claims.

<FIG> is a block diagram illustrating a storage system in accordance with some exemplary embodiments. A storage system <NUM> includes a host <NUM>, and a storage device <NUM>, which includes a storage controller <NUM> and a memory device <NUM>. In addition, according to an exemplary embodiment of the present disclosure, the host <NUM> may include a host controller <NUM>, a host memory <NUM>, and a plurality of tenants (e.g., virtual machines (VMs), including VM <NUM> through VM n). The host includes a first virtual machine, VM1.

Single root I/O virtualization (SR-IOV) allows a plurality of virtual machines VM <NUM> to VM n in the host <NUM> to access the storage device through one assignable device interface (ADI). The single root I/O virtualization was published by the peripheral component interconnect special interest group (PCI-SIG).

The plurality of virtual machines (VM <NUM> to VM n) may maintain areas independent from each other, respectively, and may separately access the storage device <NUM>, thus, the necessity for a storage device <NUM> that may satisfy processing conditions for each of the plurality of virtual machines VM <NUM> to VM n or each of data of the plurality of virtual machines VM <NUM> to VM n may emerge. An operation method of improving processing satisfaction for each of the plurality of virtual machines VM <NUM> to VM n or each of the data of the plurality of virtual machines VM <NUM> to VM n through the storage controller <NUM> in which the storage device <NUM> communicates with the host <NUM> will be described in detail below.

The host memory <NUM> may function as a buffer memory for temporarily storing data to be transmitted from each of the plurality of virtual machines VM <NUM> to VM n to the storage device <NUM> or data transmitted from the storage device <NUM>. For example, a plurality of data for a command CMD generated by a first virtual machine VM <NUM> may be stored in the host memory <NUM>. In addition, the plurality of data for the command CMD generated by the first virtual machine VM <NUM>, which is stored in the host memory <NUM>, may be transmitted to the storage device <NUM>. In addition, data transmitted from the storage device <NUM> may be temporarily stored in the host memory <NUM>. In addition, the data temporarily stored in the host memory <NUM> may be read and used by the first virtual machine VM <NUM>, in some embodiments.

The storage device <NUM> may include storage media for storing data according to a request from the host <NUM>. As an example, the storage device <NUM> may include at least one of a solid state drive (SSD), an embedded memory, and a removable external memory. When the storage device <NUM> is the SSD, the storage device <NUM> may be a device conforming to a non-volatile memory express (NVMe) standard. When the storage device <NUM> is an embedded memory or an external memory, the storage device <NUM> may be a device conforming to a universal flash storage (UFS) or embedded multi-media card (eMMC) standard. Each of the host <NUM> and the storage device <NUM> may generate and transmit a packet according to an adopted standard protocol.

When the memory device <NUM> of the storage device <NUM> includes a flash memory, the flash memory may include a 2D NAND memory array or a 3D (or vertical) NAND (VNAND) memory array. As another example, the storage device <NUM> may include various other types of non-volatile memories. For example, the storage device <NUM> may include a magnetic random access memory (MRAM), a spin-transfer torque MRAM, a conductive bridging RAM (CBRAM), a ferroelectric RAM (FeRAM), a phase RAM (PRAM), a resistive RAM, and various other types of memories.

According to an exemplary embodiment, the host controller <NUM> and the host memory <NUM> may be implemented as separate semiconductor chips. Alternatively, in some exemplary embodiments, the host controller <NUM> and the host memory <NUM> may be integrated on the same semiconductor chip. As an example, the host controller <NUM> may be any one of a plurality of modules included in an application processor, and the application processor may be implemented as a system on chip (SoC). In addition, the host memory <NUM> may be an embedded memory provided in the application processor or be a non-volatile memory or a memory module disposed outside the application processor.

The host controller <NUM> may manage an operation of storing data, such as write data of a buffer area of the host memory <NUM>, in the memory device <NUM>, or storing data, such as read data of the memory device <NUM>, in the buffer area. For example, the host controller <NUM> may store the plurality of data for the command generated by the first virtual machine VM <NUM>, stored in the buffer area, in the memory device <NUM>. Alternatively, the host controller <NUM> may read the plurality of data for the command generated by the first virtual machine VM <NUM>, stored in the memory device <NUM>, and store the read data in the buffer area.

The storage controller <NUM> may include a host interface <NUM>, a memory interface <NUM>, and a central processing unit (CPU) <NUM>. In addition, the storage controller <NUM> may further include a flash translation layer (FTL) <NUM>, a packet manager <NUM>, a buffer memory <NUM>. The storage controller includes either an error correction code (ECC) engine <NUM>, or an encryption/decryption engine <NUM>. The storage controller <NUM> may further include a working memory (not illustrated) to which the flash translation layer (FTL) <NUM> is loaded; and data write and read operations for the memory device <NUM> may be controlled by the CPU <NUM> executing the flash translation layer FTL.

The host interface <NUM> may transmit and receive packets to and from the host <NUM>. The packet transmitted from the host <NUM> to the host interface <NUM> may include a command CMD, data to be written to the memory device <NUM>, or the like, and the packet transmitted from the host interface <NUM> to the host <NUM> may include a response to the command, data read from the memory device <NUM>, or the like.

For example, the host interface <NUM> may receive the command transmitted from the first virtual machine VM <NUM> from the host <NUM>. In addition, the host interface <NUM> may receive the plurality of data for the command transmitted from the first virtual machine VM <NUM> from the host <NUM>. In addition, the plurality of data for the command generated by the first virtual machine VM <NUM>, read from the memory device <NUM> may be transmitted from the host interface <NUM> to the host <NUM>.

The memory interface <NUM> may transmit data to be written to the memory device <NUM> to the memory device <NUM>, or may receive data read from the memory device <NUM>. Such a memory interface <NUM> may be implemented to comply with a standard protocol such as a toggle or an Open NAND Flash Interface (ONFI).

The flash translation layer <NUM> may perform several functions such as: (i) address mapping, (ii) wear-leveling, and (iii) garbage collection. As will be understood by those skilled in the art, an address mapping operation is an operation of converting a logical address received from the host <NUM> into a physical address used to actually store data in the memory device <NUM>. And, wear-leveling is a technology for preventing excessive deterioration of a specific block by allowing blocks in the memory device <NUM> to be uniformly used, and may be implemented through, for example, a firmware technology of balancing erase counts of physical blocks. The garbage collection is a technology for securing a usable capacity in the memory device <NUM> in a manner of copying valid data of a block to a new block and then erasing an existing block.

The packet manager <NUM> may generate a packet according to a protocol of an interface negotiated with the host <NUM> or parse various information from a packet received from the host <NUM>. The packet manager <NUM> of the storage controller <NUM> according to some exemplary embodiments may receive a plurality of packets from each of the plurality of virtual machines VM <NUM> to VM n of the host <NUM>, and parse various information from the received packets. A detailed description of the plurality of packets received by the packet manager <NUM> from each of the plurality of virtual machines VM <NUM> to VM n of the host <NUM> will be provided later.

The buffer memory <NUM> may temporarily store data to be written to the memory device <NUM> or data to be read from the memory device <NUM>. The buffer memory <NUM> may be provided in the storage controller <NUM>, but may also be disposed outside the storage controller <NUM>.

The ECC engine <NUM> may perform an error detection and correction function for read data read from the memory device <NUM>. More specifically, the ECC engine <NUM> may generate parity bits for write data to be written into the memory device <NUM>, and the parity bits generated as described above may be stored in the memory device <NUM> together with the write data. At the time of reading data from the memory device <NUM>, the ECC engine <NUM> may correct an error of read data using the parity bits read from the memory device <NUM> together with the read data, and output the read data of which the error is corrected.

The ECC engine <NUM> of the storage controller <NUM> determines an operation method of the ECC engine <NUM> based on reliability request type information related to each data for commands generated by each of the plurality of virtual machines VM <NUM> to VM n of the host <NUM>. For example, the ECC engine <NUM> may differently/uniquely perform one ECC operation for data of the first virtual machine VM <NUM> and another ECC operation for data of the second virtual machine VM <NUM>.

The ECC engine <NUM> of the storage controller <NUM> determines an operation method of the ECC engine <NUM> based on reliability request type information for each of a plurality of data for commands generated by, for example, the first virtual machine VM <NUM> of the plurality of virtual machines VM <NUM> to VM n of the host <NUM>. For example, the ECC engine <NUM> may differently perform ECC operations for different first and second data of the plurality of data of the first virtual machine VM <NUM>.

A detailed operation of the ECC engine <NUM> of the storage controller <NUM> according to some exemplary embodiments described above will be described later. The encryption/decryption engine <NUM> performs at least one of an encryption operation and a decryption operation for data input to the storage controller <NUM>.

For example, the encryption/decryption engine <NUM> may perform an encryption operation and/or a decryption operation using a symmetric-key algorithm. In this case, the encryption/decryption engine <NUM> may perform encryption and/or decryption operations using, for example, an advanced encryption standard (AES) algorithm or a data encryption standard (DES) algorithm.

In addition, for example, the encryption/decryption engine <NUM> may perform an encryption operation and/or a decryption operation using a public key cryptography algorithm. In this case, for example, the encryption/decryption engine <NUM> may perform encryption using a public key at the time of the encryption operation, and may perform decryption using a private key at the time of the decryption operation. For example, the encryption/decryption engine <NUM> may selectively use a Rivest-Shamir-Adleman (RSA) algorithm, elliptic curve cryptography (ECC), or Diffie-Hellman (DH) cryptography algorithm, as described more fully hereinbelow.

The present disclosure is not limited thereto, and the encryption/decryption engine <NUM> may perform an encryption operation and/or a decryption operation using a quantum cryptography technology such as homomorphic encryption (HE), post-quantum cryptography (PQC), or functional encryption (FE).

Advantageously, the encryption/decryption engine <NUM> of the storage controller <NUM> determines a cryptography algorithm to be applied to data based on encryption strength information related to each data for the commands generated by each of the plurality of virtual machines VM <NUM> to VM n of the host <NUM>. For example, the encryption/decryption engine <NUM> may differently apply one cryptography algorithm for the data of the first virtual machine VM <NUM> and another distinct cryptography algorithm for the data of the second virtual machine VM <NUM>.

The encryption/decryption engine <NUM> of the storage controller <NUM> determines a cryptography algorithm to be applied to data based on encryption strength information for each of the plurality of data for the commands generated by, for example, the first virtual machine VM <NUM> of the plurality of virtual machines VM <NUM> to VM n of the host <NUM>. For example, the encryption/decryption engine <NUM> may even differently apply cryptography algorithms for different first and second data of the plurality of data of the first virtual machine VM <NUM>. A detailed operation of the encryption/decryption engine <NUM> of the storage controller <NUM> according to some exemplary embodiments described above will be described hereinbelow.

<FIG> is a block diagram illustrating reconfiguration of a storage controller and a memory device of a storage device of <FIG>. Referring to <FIG>, the storage device <NUM> may include a memory device <NUM> and a storage controller <NUM>. The storage device <NUM> may support a plurality of channels CH1 to CHm, and the memory device <NUM> and the storage controller <NUM> may be connected to each other through the plurality of channels CH1 to CHm. For example, the storage device <NUM> may be implemented as a storage device such as a solid state drive (SSD).

The memory device <NUM> may include a plurality of non-volatile memory devices NVM11 to NVMmn. Each of the non-volatile memory devices NVM11 to NVMmn may be connected to one of the plurality of channels CH1 to CHm through a corresponding way (e.g., I/O port). For example, the non-volatile memory devices NVM11 to NVM1n may be connected to a first channel CH1 through ways W11 to W1n, and the non-volatile memory devices NVM21 to NVM2n may be connected to a second channel CH2 through ways W21 to W2n.

In an exemplary embodiment, each of the non-volatile memory devices NVM11 to NVMmn may be implemented in an arbitrary memory unit capable of operating according to an individual command from the storage controller <NUM>. For example, each of the non-volatile memory devices NVM11 to NVMmn may be implemented as a chip or die, but the present disclosure is not limited thereto.

The storage controller <NUM> may transmit and receive signals to and from the memory device <NUM> through the plurality of channels CH1 to CHm. For example, the storage controller <NUM> may transmit commands CMDa to CMDm, addresses ADDRa to ADDRm, and data DATAa to DATAm to the memory device <NUM> or receive data DATAa to DATAm from the memory device <NUM>, through the channels CH1 to CHm.

The storage controller <NUM> may select one of the non-volatile memory devices NVM11 to NVMmn connected to a corresponding channel through each channel, and transmit and receive signals to and from the selected non-volatile memory device. For example, the storage controller <NUM> may select the non-volatile memory device NVM11 of the non-volatile memory devices NVM11 to NVM1n connected to the first channel CH1. The storage controller <NUM> may transmit a command CMDa, an address ADDRa, and data DATAa to the selected non-volatile memory device NVM11 or receive data DATAa from the selected non-volatile memory device NVM11, through the first channel CH1.

The storage controller <NUM> may transmit and receive signals to and from the memory device <NUM> in parallel through different channels. For example, the storage controller <NUM> may transmit a command CMDb to the memory device <NUM> through the second channel CH2 while transmitting the command CMDa to the memory device <NUM> through the first channel CH1. For example, the storage controller <NUM> may receive data DATAb from the memory device <NUM> through the second channel CH2 while receiving the data DATAa from the memory device <NUM> through the first channel CH1.

The storage controller <NUM> may control a general operation of the memory device <NUM>. The storage controller <NUM> may control each of the non-volatile memory devices NVM11 to NVMmn connected to the channels CH1 to CHm by transmitting signals to the channels CH1 to CHm. For example, the storage controller <NUM> may control one non-volatile memory device selected among the non-volatile memory devices NVM11 to NVM1n by transmitting the command CMDa and the address ADDRa to the first channel CH1.

Each of the non-volatile memory devices NVM11 to NVMmn may operate under the control of the storage controller <NUM>. For example, the non-volatile memory device NVM11 may program the data DATAa according to the command CMDa and the address ADDRa provided to the first channel CH1. For example, the non-volatile memory device NVM21 may read the data DATAb according to the command CMDb and the address ADDRb provided to the second channel CH2, and transmit the read data DATAb to the storage controller <NUM>.

It has been illustrated in <FIG> that the memory device <NUM> communicates with the storage controller <NUM> through m channels and the memory device <NUM> includes n non-volatile memory devices corresponding to each channel, but the number of channels and the number of non-volatile memory devices connected to one channel may be variously modified.

Next, referring to <FIG> together with <FIG>, the storage controller <NUM> may transfer or receive data to and from the non-volatile memory through a separate channel or a separate way for each of the plurality of virtual machines VM <NUM> to VM n of the host <NUM> or each of the data of the plurality of virtual machines VM <NUM> to VM n. For example, the command CMDa generated by the first virtual machine VM <NUM> may be transmitted from the host <NUM> to the storage controller <NUM>. In this case, the command CMDa, the address ADDRa for the command CMDa, and the data DATAa may be transmitted from the host <NUM> to the storage controller <NUM>. The address ADDRa may include position information on a position at which the first virtual machine VM <NUM> intends to store the data DATAa in the memory device <NUM>.

In addition, the command CMDb generated by the second virtual machine VM <NUM> is transmitted from the host <NUM> to the storage controller <NUM>. In this case, the command CMDb, the address ADDRb for the command CMDb, and the data DATAb may be transmitted from the host <NUM> to the storage controller <NUM>. The address ADDRb may include position information on a position at which the second virtual machine VM <NUM> intends to store the data DATAb in the memory device <NUM>.

When an address of the non-volatile memory device NVM11 is stored so that the address ADDRa stores the data DATAa in the non-volatile memory device NVM11, the data DATAa may be stored in the non-volatile memory device NVM11 along the way W11. That is, all data related to the command CMDa generated by the first virtual machine VM <NUM> may be stored in the non-volatile memory device NVM11.

When the number of data DATAa related to the command CMDa generated by the first virtual machine VM <NUM> is plural (e.g., DATAa1 to DATAan), the address ADDRa may include position information of a non-volatile memory device in which each of the plurality of data (e.g., DATAa1 to DATAan) is to be stored.

For example, the data DATAa1 may be stored in the non-volatile memory device NVM11 along the way W11, the data DATAa2 may be stored in the non-volatile memory device NVM12 along the way W12, and the data DATAan may be stored in the non-volatile memory device NVM1n along the way W1n.

The storage controller <NUM> according to some exemplary embodiments may store or read data in or from a required non-volatile memory device according to a required condition, for the data of each of the plurality of virtual machines VM <NUM> to VM n, according to the command generated by each of the plurality of virtual machines VM <NUM> to VM n in the host <NUM>. Accordingly, satisfaction for requirements for the data of each of the plurality of virtual machines VM <NUM> to VM n may be improved. Hereinafter, for convenience of explanation, only the first virtual machine VM <NUM> will be described by way of example, and a description of the first virtual machine VM <NUM> may also be applied to the second virtual machine VM <NUM> to an n-th virtual machine VM n.

The command CMDa generated by the first virtual machine VM <NUM> according to some exemplary embodiments may include information for commanding whether to retain or erase the data of the first virtual machine VM <NUM> in or from the memory device <NUM> in preparation for a case where access of the first virtual machine VM <NUM> to the storage controller <NUM> is interrupted or stopped (e.g., log-off of the first virtual machine VM <NUM> for the storage device <NUM> or sudden power off (SPO) of the storage device <NUM> or the storage system <NUM>).

As an example, in a case where access of the first virtual machine VM <NUM> to the storage controller <NUM> is interrupted or stopped, when the first virtual machine VM <NUM> desires that the data of the first virtual machine VM <NUM> will be retained in the memory device <NUM>, the first virtual machine VM <NUM> may include a retain command in the command CMDa generated by the first virtual machine VM <NUM>. In this case, the command CMDa may be an administration (i.e., admin) command. In more detail, the command CMDa may be a set feature command. Alternatively, the command CMDa is not limited thereto, and may also be an NVM command (including a write or read command).

The storage controller <NUM> detects a request type of the data of the first virtual machine VM <NUM>. In this case, the storage controller <NUM> determines that the data DATAa of the first virtual machine VM <NUM> is to be treated as retain data when it detects that the retain command is included in the command CMDa generated by the first virtual machine VM <NUM>. In this case, the storage controller <NUM> stores the data DATAa of the first virtual machine VM <NUM> in the memory device <NUM>. Alternatively, when the data DATAa of the first virtual machine VM <NUM> is stored in the buffer memory <NUM>, the storage controller <NUM> transmits the data DATAa to the memory device <NUM> and stores the data DATAa in the memory device <NUM>. The above-described operation may also be performed on each of a plurality of data DATAa (e.g., DATAa1 to DATAan) of the first virtual machine VM <NUM> when it is assumed that the number of data DATAa of the first virtual machine VM <NUM> is plural (e.g., DATAa1 to DATAan).

As another example, in a case where access of the first virtual machine VM <NUM> to the storage controller <NUM> is stopped, when the first virtual machine VM <NUM> desires that the data of the first virtual machine VM <NUM> will be erased from the memory device <NUM>, the first virtual machine VM <NUM> may include an erase command in the command CMDa generated by the first virtual machine VM <NUM>. In this case, the command CMDa may be an admin command. In more detail, the command CMDa may be a set feature command. Alternatively, the command CMDa is limited thereto, and may also be an NVM command (including a write or read command).

The storage controller <NUM> detects a request type of the data of the first virtual machine VM <NUM>. In this case, the storage controller <NUM> determines the data DATAa of the first virtual machine VM <NUM> as erase data when it detects that the erase command is included in the command CMDa generated by the first virtual machine VM <NUM>. In this case, the storage controller <NUM> stores the data DATAa of the first virtual machine VM <NUM> in the buffer memory <NUM>. Alternatively, when the data DATAa of the first virtual machine VM <NUM> is stored in the memory device <NUM>, the storage controller <NUM> performs an erase operation to erase the data DATAa of the first virtual machine VM <NUM>. The above-described operation may also be performed on each of a plurality of data DATAa (e.g., DATAa1 to DATAan) of the first virtual machine VM <NUM> when it is assumed that the number of data DATAa of the first virtual machine VM <NUM> is plural (e.g., DATAa1 to DATAan).

<FIG> is a block diagram illustrating reconfiguration of a storage controller, a memory interface, and a memory device of the storage device of <FIG>. Referring to <FIG>, the storage device <NUM> may include a non-volatile memory device <NUM> and a storage controller <NUM>. The non-volatile memory device <NUM> may correspond to one of the non-volatile memory devices NVM11 to NVMmn communicating with the storage controller <NUM> based on one of the plurality of channels CH1 to CHm of <FIG>.

The non-volatile memory device <NUM> may include first to eighth pins P11 to P18, a memory interface circuit 212b, a control logic circuit <NUM>, and a memory cell array <NUM>. The memory interface <NUM> of <FIG> may include the memory interface circuit 212b of <FIG>.

The memory interface circuit 212b may receive a chip enable signal nCE from the storage controller <NUM> through the first pin P11. The memory interface circuit 212b may transmit and receive signals to and from the storage controller <NUM> through the second to eighth pins P12 to P18 according to the chip enable signal nCE. For example, when the chip enable signal nCE is in an enable state (e.g., at a low level), the memory interface circuit 212b may transmit and receive signals to and from the storage controller <NUM> through the second to eighth pins P12 to P18.

The memory interface circuit 212b may receive a command latch enable signal CLE, an address latch enable signal ALE, and a write enable signal nWE from the storage controller <NUM> through the second to fourth pins P12 to P14. The memory interface circuit 212b may receive a data signal DQ from the storage controller <NUM> or transmit a data signal DQ to the storage controller <NUM>, through the seventh pin P17. A command CMD, an address ADDR, and data may be transferred through the data signal DQ.

For example, the data signal DQ may be transferred through a plurality of data signal lines. In this case, the seventh pin P17 may include a plurality of pins corresponding to a plurality of data signals DQ. In this case, the command CMD, the address ADDR, and the data transmitted and received through the data signal DQ may be a command, an address, and data for each of the plurality of virtual machines VM <NUM> to VM n described with reference to <FIG>.

The memory interface circuit 212b may obtain the command CMD from the data signal DQ received in an enable section (e.g., a high level state) of the command latch enable signal CLE based on toggle timings of the write enable signal nWE. The memory interface circuit 212b may obtain the address ADDR from the data signal DQ received in an enable section (e.g., a high level state) of the address latch enable signal ALE based on the toggle timings of the write enable signal nWE.

In an exemplary embodiment, the write enable signal nWE may be maintained in a static state (e.g., a high level or a low level), and then toggle between the high level and the low level. For example, the write enable signal nWE may toggle in a section in which the command CMD or the address ADDR is transmitted. Accordingly, the memory interface circuit 212b may obtain the command CMD or the address ADDR based on the toggle timings of the write enable signal nWE.

The memory interface circuit 212b may receive a read enable signal nRE from the storage controller <NUM> through the fifth pin P15. The memory interface circuit 212b may receive a data strobe signal DQS from the storage controller <NUM> or transmit a data strobe signal DQS to the storage controller <NUM>, through the sixth pin P16.

In a data output operation of the non-volatile memory device <NUM>, the memory interface circuit 212b may receive a toggling read enable signal nRE through the fifth pin P15 before outputting the data. The memory interface circuit 212b may generate a toggling data strobe signal DQS based on the toggling of the read enable signal nRE. For example, the memory interface circuit 212b may generate the data strobe signal DQS starting to toggle after a delay (e.g., tDQSRE) predefined on the basis of a toggling start time of the read enable signal nRE. The memory interface circuit 212b may transmit the data signal DQ including the data based on a toggle timing of the data strobe signal DQS. Accordingly, the data may be aligned with the toggle timing of the data strobe signal DQS and transmitted to the storage controller <NUM>.

In a data input operation of the non-volatile memory device <NUM>, when the data signal DQ including the data is received from the storage controller <NUM>, the memory interface circuit 212b may receive a toggling data strobe signal DQS together with the data from the storage controller <NUM>. The memory interface circuit 212b may obtain the data from the data signal DQ based on a toggle timing of the data strobe signal DQS. For example, the memory interface circuit 212b may obtain the data by sampling the data signal DQ at a rising edge and a falling edge of the data strobe signal DQS.

The memory interface circuit 212b may transmit a ready/busy output signal nR/B to the storage controller <NUM> through the eighth pin P18. The memory interface circuit 212b may transmit state information of the non-volatile memory device <NUM> to the storage controller <NUM> through the ready/busy output signal nR/B. When the non-volatile memory device <NUM> is in a busy state (i.e., when internal operations of the non-volatile memory device <NUM> are being performed), the memory interface circuit 212b may transmit the ready/busy output signal nR/B indicating the busy state to the storage controller <NUM>. When the non-volatile memory device <NUM> is in a ready state (i.e., when the internal operations of the non-volatile memory device <NUM> are not performed or have been completed), the memory interface circuit 212b may transmit the ready/busy output signal nR/B indicating the ready state to the storage controller <NUM>. For example, while the non-volatile memory device <NUM> reads the data from the memory cell array <NUM> in response to a page read command, the memory interface circuit 212b may transmit the ready/busy output signal nR/B indicating the busy state (e.g., a low level) to the storage controller <NUM>. For example, while the non-volatile memory device <NUM> programs the data in the memory cell array <NUM> in response to a program command, the memory interface circuit 212b may transmit the ready/busy output signal nR/B indicating the busy state to the storage controller <NUM>.

The control logic circuit <NUM> may generally control various operations of the non-volatile memory device <NUM>. The control logic circuit <NUM> may receive the obtained command/address CMD/ADDR from the memory interface circuit 212b. The control logic circuit <NUM> may generate control signals for controlling other components of the non-volatile memory device <NUM> according to the received command/address CMD/ADDR. For example, the control logic circuit <NUM> may generate various control signals for programming the data in the memory cell array <NUM> or reading the data from the memory cell array <NUM>.

The memory cell array <NUM> may store the data obtained from the memory interface circuit 212b under the control of the control logic circuit <NUM>. The memory cell array <NUM> may output the stored data to the memory interface circuit 212b under the control of the control logic circuit <NUM>.

The memory cell array <NUM> may include a plurality of memory cells. For example, the plurality of memory cells may be flash memory cells. However, the present disclosure is not limited thereto, and the memory cells may be resistive random access memory (RRAM) cells, ferroelectric random access memory (FRAM) cells, phase change random access memory (PRAM) cells, thyristor random access memory (TRAM) cells, or magnetic random access memory (MRAM) cells. Hereinafter, exemplary embodiments of the present disclosure will be described with a focus on an exemplary embodiment in which the memory cells are NAND flash memory cells.

The storage controller <NUM> may include first to eighth pins P21 to P28 and a controller interface circuit 212a. The first to eighth pins P21 to P28 may correspond to the first to eighth pins P11 to P18 of the non-volatile memory device <NUM>, respectively. And, the memory interface <NUM> of <FIG> may include the controller interface circuit 212a of <FIG>.

The controller interface circuit 212a may transmit the chip enable signal nCE to the non-volatile memory device <NUM> through the first pin P21. The controller interface circuit 212a may transmit and receive signals to and from the non-volatile memory device <NUM> selected through the chip enable signal nCE through the second to eighth pins P22 to P28.

The controller interface circuit 212a may transmit the command latch enable signal CLE, the address latch enable signal ALE, and the write enable signal nWE to the non-volatile memory device <NUM> through the second to fourth pins P22 to P24. The controller interface circuit 212a may transmit the data signal DQ to the non-volatile memory device <NUM> or receive the data signal DQ from the non-volatile memory device <NUM>, through the seventh pin P27.

The controller interface circuit 212a may transmit the data signal DQ including the command CMD or the address ADDR together with the toggling write enable signal nWE to the non-volatile memory device <NUM>. The controller interface circuit 212a may transmit the data signal DQ including the command CMD to the non-volatile memory device <NUM> as it transmits the command latch enable signal CLE having an enable state, and may transmit the data signal DQ including the address ADDR to the non-volatile memory device <NUM> as it transmits the address latch enable signal ALE having an enable state.

The controller interface circuit 212a may transmit the read enable signal nRE to the non-volatile memory device <NUM> through the fifth pin P25. The controller interface circuit 212a may receive the data strobe signal DQS from the non-volatile memory device <NUM> or transmit the data strobe signal DQS to the non-volatile memory device <NUM>, through the sixth pin P26.

In the data output operation of the non-volatile memory device <NUM>, the controller interface circuit 212a may generate the toggling read enable signal nRE and transmit the read enable signal nRE to the non-volatile memory device <NUM>. For example, the controller interface circuit 212a may generate the read enable signal nRE changed from a static state (e.g., a high level or a low level) to a toggle state before the data is output. Accordingly, the toggling data strobe signal DQS may be generated based on the read enable signal nRE in the non-volatile memory device <NUM>. The controller interface circuit 212a may receive the data signal DQ including the data together with the toggling data strobe signal DQS from the non-volatile memory device <NUM>. The controller interface circuit 212a may obtain the data from the data signal DQ based on the toggle timing of the data strobe signal DQS.

In the data input operation of the non-volatile memory device <NUM>, the controller interface circuit 212a may generate the toggling data strobe signal DQS. For example, the controller interface circuit 212a may generate the data strobe signal DQS changed from a static state (e.g., a high level or a low level) to a toggle state before transmitting the data. The controller interface circuit 212a may transmit the data signal DQ including the data to the non-volatile memory device <NUM> based on the toggle timings of the data strobe signal DQS.

The controller interface circuit 212a may receive the ready/busy output signal nR/B from the non-volatile memory device <NUM> through the eighth pin P28. The controller interface circuit 212a may decide the state information of the non-volatile memory device <NUM> based on the ready/busy output signal nR/B.

<FIG> is an illustrative block diagram illustrating a non-volatile memory device of <FIG>. Referring to <FIG>, the non-volatile memory device <NUM> may include a control logic circuit <NUM>, a memory cell array <NUM>, a page buffer <NUM>, a voltage generator <NUM>, and a row decoder <NUM>. Although not illustrated in <FIG>, the non-volatile memory device <NUM> may further include the memory interface circuit 212b illustrated in <FIG>, and may further include column logic, a pre-decoder, a temperature sensor, a command decoder, an address decoder, and the like.

The control logic circuit <NUM> may generally control various operations within the non-volatile memory device <NUM>. The control logic circuit <NUM> may output various control signals in response to a command CMD and/or an address ADDR from the memory interface circuit <NUM>. For example, the control logic circuit <NUM> may output a voltage control signal CTRL_vol, a row address X-ADDR, and a column address Y-ADDR.

In this case, the command CMD and/or the address ADDR may be a command and/or an address for each of the plurality of virtual machines VM <NUM> to VM n described with reference to <FIG>.

The memory cell array <NUM> may include a plurality of memory blocks BLK1 to BLKz (z is a positive integer), each of which may include a plurality of memory cells. The memory cell array <NUM> may be connected to the page buffer <NUM> through bit lines BL, and may be connected to the row decoder <NUM> through word lines WL, string selection lines SSL, and ground selection lines GSL.

In an exemplary embodiment, the memory cell array <NUM> may include a three-dimensional (3D) memory cell array, and the 3D memory cell array may include a plurality of NAND strings. Each NAND string may include memory cells connected to word lines and vertically stacked on a substrate, as described in: <CIT>, <CIT>, <CIT>, <CIT>, and <CIT>. In an exemplary embodiment, the memory cell array <NUM> may include a two-dimensional (2D) memory cell array, and the 2D memory cell array may include a plurality of NAND strings arranged along row and column directions.

The page buffer <NUM> may include a plurality of page buffers PB1 to PBn (n is an integer of <NUM> or more), and the plurality of page buffers PB1 to PBn may be connected, respectively, to the memory cells through a plurality of bit lines BL. The page buffer <NUM> may select at least one of the bit lines BL in response to the column address Y-ADDR. The page buffer <NUM> may operate as a write driver or a sense amplifier according to an operation mode. For example, at the time of a program operation, the page buffer <NUM> may apply a bit line voltage corresponding to data to be programmed to the selected bit line. At the time of a read operation, the page buffer <NUM> may detect a current or a voltage of the selected bit line to detect data stored in the memory cell.

The voltage generator <NUM> may generate various types of voltages for performing program, read, and erase operations based on the voltage control signal CTRL_vol. For example, the voltage generator <NUM> may generate a program voltage, a read voltage, a program verification voltage, an erase voltage, and the like, as word line voltages VWL.

The row decoder <NUM> may select one of a plurality of word lines WL and may select one of a plurality of string selection lines SSL, in response to the row address X-ADDR. For example, the row decoder <NUM> may apply the program voltage and the program verification voltage to the selected word line at the time of the program operation, and may apply the read voltage to the selected word line at the time of the read operation.

<FIG> is a diagram for describing a 3D V-NAND structure that may be applied to a non-volatile memory device according to some exemplary embodiments. For example, in a case where the storage device of <FIG> according to some exemplary embodiments is applied as a storage module of a UFS device, when the storage module of the UFS device is implemented as a 3D V-NAND-type flash memory, each of a plurality of memory blocks constituting the storage module may be represented by an equivalent circuit as illustrated in <FIG>.

Referring to <FIG>, a memory block BLKi of a non-volatile memory device <NUM> is a three-dimensional memory block formed in a three-dimensional structure on a substrate. For example, a plurality of memory NAND strings included in the memory block BLKi may be formed in a direction perpendicular to the substrate.

The memory block BLKi may include a plurality of memory NAND strings NS11 to NS33 connected between bit lines BL1, BL2, and BL3 and a common source line CSL. Each of the plurality of memory NAND strings NS11 to NS33 may include a string selection transistor SST, a plurality of memory cells MC1, MC2,. , MC8, and a ground selection transistor GST. It has been illustrated in <FIG> that each of the plurality of memory NAND strings NS11 to NS33 includes eight memory cells MC1, MC2,. , MC8, but the present disclosure is not necessarily limited thereto.

The string selection transistors SST may be connected to corresponding string selection lines SSL1, SSL2, and SSL3. The plurality of memory cells MC1, MC2,. , MC8 may be connected to corresponding gate lines GTL1, GTL2,. , GTL8, respectively. The gate lines GTL1, GTL2,. , GTL8 may correspond to word lines, and some of the gate lines GTL1, GTL2,. , GTL8 may correspond to dummy word lines. The ground selection transistors GST may be connected to corresponding ground selection lines GSL1, GSL2, and GSL3. The string selection transistors SST may be connected to corresponding bit lines BL1, BL2, and BL3, and the ground selection transistors GST may be connected to the common source line CSL.

Word lines (for example, WL1) having the same height may be connected in common, and the ground selection lines GSL1, GSL2, and GSL3 and the string selection lines SSL1, SSL2, and SSL3 may be separated from each other, respectively. It has been illustrated in <FIG> that the memory block BLKi is connected to eight gate lines GTL1, GTL2,. , GTL8 and three bit lines BL1, BL2, and BL3, but the present disclosure is not necessarily limited thereto.

<FIG> is a flowchart illustrating an operating method of a storage device according to some exemplary embodiments. Hereinafter, a description of portions overlapping those described above with reference to <FIG> will be omitted or simplified.

Referring to <FIG>, <FIG>, and <FIG>, the command CMD generated by the first virtual machine VM <NUM> is transmitted from the host <NUM> to the storage controller <NUM> (S100). In this case, the command CMD generated by the first virtual machine VM <NUM> may include information for commanding whether to retain or erase the data of the first virtual machine VM <NUM> in or from the memory device <NUM> in preparation for a case where access of the first virtual machine VM <NUM> to the storage controller <NUM> is interrupted or stopped (e.g., log-off of the first virtual machine VM <NUM> for the storage device <NUM> or sudden power off (SPO) of the storage device <NUM> or the storage system <NUM>).

The storage controller <NUM> detects a request type of the data of the first virtual machine VM <NUM> through the received command CMD (S110). In addition, the storage controller <NUM> determines whether the data of the first virtual machine VM <NUM> is retain data or erase data, through information included in the command CMD (S120). For example, when the command CMD generated by the first virtual machine VM <NUM> is an admin CMD, information may be included in a set feature. Alternatively, for example, when the command CMD generated by the first virtual machine VM <NUM> is an NVM command set including read and/or write commands for the memory device <NUM>, setting information on whether the data of the first virtual machine VM <NUM> is the retain data or the erase data may be set using a flag.

When it is determined that the data of the first virtual machine VM <NUM> corresponds to the erase data, in a case where the access of the first virtual machine VM <NUM> to the storage controller <NUM> is stopped (e.g., the log-off of the first virtual machine VM <NUM> for the storage device <NUM> or the sudden power off (SPO) of the storage device <NUM> or the storage system <NUM>), the storage controller <NUM> may allocate an erase policy to the data so that the data of the first virtual machine VM1 is erased from the storage device <NUM> (S130).

For example, when data of the first virtual machine VM <NUM> to which the erase policy is allocated is stored in the memory device <NUM>, in the case where the access of the first virtual machine VM <NUM> to the storage controller <NUM> is stopped (e.g., the log-off of the first virtual machine VM <NUM> for the storage device <NUM> or the sudden power off (SPO) of the storage device <NUM> or the storage system <NUM>), the data may be erased. The data is not limited to being stored in the memory device <NUM>, and may also be stored in another component (e.g., the buffer <NUM>). Otherwise, when it is determined that the data of the first virtual machine VM <NUM> corresponds to the retain data, in the case where the access of the first virtual machine VM <NUM> to the storage controller <NUM> is interrupted or stopped (e.g., the log-off of the first virtual machine VM <NUM> for the storage device <NUM> or the sudden power off (SPO) of the storage device <NUM> or the storage system <NUM>), the storage controller <NUM> may allocate a retain policy to the data so that the data of the first virtual machine VM1 is retained from the storage device <NUM> (S140).

For example, when data of the first virtual machine VM <NUM> to which the retain policy is allocated is stored in the memory device <NUM>, in the case where the access of the first virtual machine VM <NUM> to the storage controller <NUM> is stopped (e.g., the log-off of the first virtual machine VM <NUM> for the storage device <NUM> or the sudden power off (SPO) of the storage device <NUM> or the storage system <NUM>), the data may be retained. The data is not limited to being stored in the memory device <NUM>, and may also be stored in another component (e.g., the buffer <NUM>). In the case where the access of the first virtual machine VM <NUM> to the storage controller <NUM> is stopped (e.g., the log-off of the first virtual machine VM <NUM> for the storage device <NUM> or the sudden power off (SPO) of the storage device <NUM> or the storage system <NUM>) in a state in which the data is stored in the buffer <NUM>, the data of the buffer <NUM> may be stored and retained in the non-volatile memory device <NUM>.

<FIG> is a ladder diagram illustrating an operating method of a storage system according to some exemplary embodiments. <FIG> and <FIG> illustrate an example of a protocol through transmission/reception of packets between the first virtual machine VM <NUM> of the host <NUM> and the storage controller <NUM>. In more detail, packets between the first virtual machine VM <NUM> of the host <NUM> and the storage controller <NUM> may be managed through the packet manager <NUM>.

The first virtual machine VM <NUM> requests cryptography algorithm information supportable by the storage device <NUM> from the storage controller <NUM> (S20). In more detail, the encryption/decryption engine <NUM> of the storage device <NUM> may request supportable cryptography algorithm information from the storage controller <NUM>. In response to such a request, the storage controller <NUM> transmits the cryptography algorithm information supportable by the storage device <NUM> to the first virtual machine VM <NUM> (S22). For example, the storage controller <NUM> may transmit a response indicating that the encryption/decryption engine <NUM> of the storage device <NUM> may support Rivest-Shamir-Adleman (RSA) algorithm, elliptic curve cryptography (ECC), and post quantum cryptography (PQC) cryptography algorithms to the first virtual machine VM <NUM>. Cryptography algorithms that the encryption/decryption engine <NUM> may support, indicated by the response are not limited thereto.

The first virtual machine VM <NUM> determines an encryption strength according to a cryptography algorithm required for the data of the first virtual machine VM <NUM> based on the response received from the storage controller <NUM>, includes encryption strength information on the determined encryption strength in the command CMD, and transmits the command CMD with the encryption strength information to the storage controller <NUM> (S24).

<FIG> is a flowchart illustrating another operating method of a storage device according to some exemplary embodiments. Referring to <FIG> and <FIG>, the command CMD generated by the first virtual machine VM <NUM> is transmitted from the host <NUM> to the storage controller <NUM> (S200). In this case, the command CMD generated by the first virtual machine VM includes encryption strength information on the data of the first virtual machine VM <NUM>.

The storage controller <NUM> detects a type of encryption strength of the data indicating which encryption strength the first virtual machine VM <NUM> requests for the data of the first virtual machine VM <NUM>, through the received command CMD (S210). Next, the storage controller <NUM> determines whether the first virtual machine VM <NUM> desires a weak encryption strength (W: Weak), desires a medium encryption strength (M: Medium), or desires a strong encryption strength (S: Strong), for the data of the first virtual machine VM <NUM>, based on the encryption strength information included in the command CMD (S220). In this case, the number of types of the encryption strength divided by the first virtual machine VM <NUM> is not limited thereto. For example, the encryption strength may also be divided into five types such as a weak strength, a slightly weak strength, a medium strength, a slightly strong strength, and a strong strength. The encryption strength may be divided through types of the cryptography algorithms that may be provided by the encryption/decryption engine <NUM>, and thus, is not limited to those in <FIG> and a description of <FIG>.

In a case where the encryption strength information included in the command CMD received from the first virtual machine VM <NUM> indicates the Weak (W) level, the storage controller <NUM> performs encryption and decryption operations on the data of the first virtual machine VM <NUM> using a first cryptography algorithm (S232). The first cryptography algorithm may be, for example, the Rivest Shamir Adleman (RSA) algorithm. In contrast, in the event the encryption strength information included in the command CMD received from the first virtual machine VM <NUM> indicates the Medium (M) level, the storage controller <NUM> may perform encryption and decryption operations on the data of the first virtual machine VM <NUM> using a second cryptography algorithm (S234). The second cryptography algorithm may be, for example, the elliptic curve cryptography (ECC) algorithm.

In a case where the encryption strength information included in the command CMD received from the first virtual machine VM <NUM> indicates the Strong (S) level, the storage controller <NUM> performs encryption and decryption operations on the data of the first virtual machine VM <NUM> using a third cryptography algorithm (S236). The third cryptography algorithm may be, for example, the post quantum cryptography (PQC) algorithm.

It has been described above by way of example that different cryptography algorithms are applied in different cases to all data of the first virtual machine VM <NUM>, but different encryption strength information may be written into each of the plurality of data of the first virtual machine VM <NUM>, such that different cryptography algorithms may be applied to each of the plurality of data of the first virtual machine VM <NUM>.

<FIG> is a block diagram for describing an ECC engine <NUM> of <FIG> in detail. <FIG> is a block diagram for describing an ECC encoding circuit <NUM> of <FIG>. Referring to <FIG> and <FIG>, the ECC engine <NUM> may include an ECC encoding circuit <NUM> and an ECC decoding circuit <NUM>. The ECC encoding circuit <NUM> may generate parity bits ECCP[<NUM>:<NUM>] for write data WData[<NUM>:<NUM>] to be written into memory cells of a memory cell array <NUM> in response to an ECC control signal ECC_CON. The parity bits ECCP[<NUM>:<NUM>] may be stored in an ECC cell array <NUM>. According to exemplary embodiments, the ECC encoding circuit <NUM> may generate parity bits ECCP[<NUM>:<NUM>] for write data WData[<NUM>:<NUM>] to be written into memory cells including defective cells of the memory cell array <NUM> in response to the ECC control signal ECC_CON.

The ECC decoding circuit <NUM> may correct error bit data using read data RData[<NUM>:<NUM>] read from the memory cells of the memory cell array <NUM> and the parity bits ECCP[<NUM>:<NUM>] read from the ECC cell array <NUM> in response to the ECC control signal ECC_CON, and output data Data[<NUM>:<NUM>] of which an error is corrected. According to exemplary embodiments, the ECC decoding circuit <NUM> may correct error bit data using read data RData[<NUM>:<NUM>] read from the memory cells including the defective cells of the memory cell array <NUM> and the parity bits ECCP[<NUM>:<NUM>] read from the ECC cell array <NUM> in response to the ECC control signal ECC_CON, and output data Data[<NUM>:<NUM>] of which an error is corrected.

The ECC encoding circuit <NUM> may include a parity generator <NUM> receiving <NUM>-bit write data WData[<NUM>:<NUM>] and basis bits B[<NUM>:<NUM>]) in response to the ECC control signal ECC_CON and generating the parity bits ECCP[<NUM>:<NUM>] using an XOR array operation. The basis bits B[<NUM>:<NUM>] are bits for generating the parity bits ECCP[<NUM>:<NUM>] for the <NUM>-bit write data WData[<NUM>:<NUM>], and may be, for example, b'<NUM> bits. The basis bits (B[<NUM>:<NUM>]) may be other specific bits instead of the b'<NUM> bits.

Referring to <FIG>, <FIG>, and <FIG>, the first virtual machine VM <NUM> transmits a command CMD including reliability request type information including information on a reliability level requested for the data of the first virtual machine VM <NUM> to the storage controller <NUM>. In addition, the ECC engine <NUM> may determine an operation method of the ECC engine <NUM> for the data according to the reliability request type information requested by the first virtual machine VM <NUM>, based on the received command CMD.

<FIG> are illustrative views for describing an operation method of the ECC engine <NUM> of <FIG>. Referring to <FIG>, for example, the ECC engine <NUM> may adjust the number of parity bits generated through the parity generator <NUM> according to the reliability request type information.

As an example, in <FIG>, assuming that a code-word size exchanged between the first virtual machine VM <NUM> and the storage controller <NUM> is fixed, a ratio between the number of parity bits and the number of data within the fixed code-word size may be adjusted.

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Weak (W) level, the storage controller <NUM> may perform performs an ECC operation on the data of the first virtual machine VM <NUM> using a first ECC code rate. The first ECC code rate may be, for example, that the parity generator <NUM> of the ECC engine <NUM> generates parity bits ECCP[<NUM>:<NUM>]. In this case, the data may occupy an area other than the parity bits ECCP[<NUM>:<NUM>] in the fixed code-word size.

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Medium (M) level, the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a second ECC code rate. The second ECC code rate may be, for example, that the parity generator <NUM> of the ECC engine <NUM> generates parity bits (ECCP[<NUM>:<NUM>]). In this case, the data may occupy an area other than the parity bits ECCP[<NUM>:<NUM>] in the fixed code-word size.

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Strong (S) level reliability, the storage controller <NUM> performs an ECC operation on the data of the first virtual machine VM <NUM> using a third ECC code rate. The third ECC code rate may be, for example, that the parity generator <NUM> of the ECC engine <NUM> generates parity bits (ECCP[<NUM>:<NUM>]). In this case, the data may occupy an area other than the parity bits ECCP[<NUM>:<NUM>] in the fixed code-word size.

As another example, in <FIG>, assuming that a data size exchanged between the first virtual machine VM <NUM> and the storage controller <NUM> is fixed, only the number of linked parity bits may be adjusted for the fixed data size. In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Weak (W) level, the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a first ECC code rate. The first ECC code rate may be, for example, that the parity generator <NUM> of the ECC engine <NUM> generates parity bits ECCP[<NUM>:<NUM>]. In this case, the data has a fixed size, and the parity bits ECCP[<NUM>:<NUM>] may be linked with the data.

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Medium (M) level reliability, the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a second ECC code rate. The second ECC code rate may be, for example, that the parity generator <NUM> of the ECC engine <NUM> generates parity bits ECCP[<NUM>:<NUM>]. In this case, the data has a fixed size, and the parity bits ECCP[<NUM>:<NUM>] may be linked with the data.

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Strong (S) level reliability, the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a third ECC code rate. The third ECC code rate may be, for example, that the parity generator <NUM> of the ECC engine <NUM> generates parity bits ECCP[<NUM>:<NUM>]. In this case, the data has a fixed size, and the parity bits ECCP[<NUM>:<NUM>] may be linked with the data.

<FIG> is a ladder diagram illustrating an operating method of a storage system according to some exemplary embodiments. <FIG>, <FIG>, <FIG>, and <FIG> illustrate an example of a protocol through transmission/reception of packets between the first virtual machine VM <NUM> of the host <NUM> and the storage controller <NUM>. In more detail, packets between the first virtual machine VM <NUM> of the host <NUM> and the storage controller <NUM> may be managed through the packet manager <NUM>.

The first virtual machine VM <NUM> may request ECC cord rate information supportable by the storage device <NUM> from the storage controller <NUM> (S30). In more detail, the first virtual machine VM <NUM> may request information on the number of parity bits that the ECC engine <NUM> of the storage device <NUM> may generate through the parity generator <NUM>.

In response to such a request, the storage controller <NUM> transmits the ECC cord rate information supportable by the storage device <NUM> to the first virtual machine VM <NUM> (S32). In more detail, the storage controller <NUM> may transmit the information on the number of parity bits that the ECC engine <NUM> of the storage device <NUM> may generate through the parity generator <NUM>, as a response. For example, the storage controller <NUM> may transmit information indicating that the parity generator <NUM> of the ECC engine <NUM> may generate the parity bits ECCP[<NUM>:<NUM>], the parity bits ECCP[<NUM>:<NUM>], or the parity bits ECCP[<NUM>:<NUM>], as the response. This is an example, and the number of parity bits that the parity generator <NUM> of the ECC engine <NUM> may generate may be various.

The first virtual machine VM <NUM> determines a reliability request type according to a reliability request type required for the data of the first virtual machine VM <NUM> based on the response received from the storage controller <NUM>, includes the determined reliability request type in the command CMD, and transmits the command CMD with the reliability request type to the storage controller <NUM> (S34).

<FIG> is a flowchart illustrating another operating method of a storage device according to some exemplary embodiments. Referring to <FIG>, <FIG>, <FIG>, and <FIG> the command CMD generated by the first virtual machine VM <NUM> is transmitted from the host <NUM> to the storage controller <NUM> (S300). In this case, the command CMD generated by the first virtual machine VM <NUM> includes reliability request type information required for the data of the first virtual machine VM <NUM>.

The storage controller <NUM> detects reliability request type information of the data indicating which level of reliability the first virtual machine VM <NUM> requests for the data of the first virtual machine VM <NUM>, through the received command CMD (S310). Then, the storage controller <NUM> determines whether the first virtual machine VM <NUM> desires weak reliability (W: Weak), desires medium reliability (M: Medium), or desires strong reliability (S: Strong), for the data of the first virtual machine VM <NUM>, based on the reliability request type information included in the command CMD (S320). In this case, the number of reliability request types divided by the first virtual machine VM <NUM> is not limited thereto. For example, the reliability may also be divided into five types such as weak reliability, slightly weak reliability, medium reliability, slightly strong reliability, and strong reliability. The reliability may be divided through the number of parity bits that may be generated by the parity generator <NUM> of the ECC engine <NUM>, and thus, is not limited to those in <FIG> and a description of <FIG>.

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Weak (W) level, the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a first ECC code rate (S332). The first ECC code rate may be, for example, that the parity generator <NUM> of the ECC engine <NUM> generates parity bits ECCP[<NUM>:<NUM>].

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Medium (M), the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a second ECC code rate (S334). The second ECC code rate may be, for example, that the parity generator <NUM> of the ECC engine <NUM> generates parity bits ECCP[<NUM>:<NUM>].

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Strong (S) level reliability, the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a third ECC code rate (S336). The third ECC code rate may be, for example, that the parity generator <NUM> of the ECC engine <NUM> generates parity bits ECCP[<NUM>:<NUM>].

It has been described above by way of example that different ECC code rates are applied in different cases to all data of the first virtual machine VM <NUM>, but different reliability request type information may be written into each of the plurality of data of the first virtual machine VM <NUM>, such that different ECC code rates may be applied to each of the plurality of data of the first virtual machine VM <NUM>.

<FIG> is a block diagram for describing an ECC decoding circuit <NUM> of <FIG>. Referring to <FIG>, the ECC decoding circuit <NUM> includes a syndrome generator <NUM>, a coefficient calculator <NUM>, a <NUM>-bit error position detector <NUM>, and an error corrector <NUM>. The syndrome generator <NUM> may receive <NUM>-bit read data and <NUM>-bit parity bits ECCP[<NUM>:<NUM>] in response to the ECC control signal ECC_CON, and generate syndrome data S[<NUM>: <NUM>] using an XOR array operation. The coefficient calculator <NUM> may calculate a coefficient of an error position equation using the syndrome data S[<NUM>:<NUM>]. The error position equation is an equation having the reciprocal of an error bit as a solution. The <NUM>-bit error position detector <NUM> may calculate a position of a <NUM>-bit error using the error position equation of which the coefficient is calculated. The error corrector <NUM> may determine a <NUM>-bit error position based on a detection result of the <NUM>-bit error position detector <NUM>. The error corrector <NUM> may invert a logic value of a bit in which an error has occurred among the <NUM>-bit read data RData[<NUM>:<NUM>] according to determined <NUM>-bit error position information to correct the error, and output the <NUM>-bit data Data[<NUM>:<NUM>] of which the error is corrected.

The syndrome generator <NUM> may generate a syndrome using, for example, a low density parity check code (LDPC). The present disclosure is not limited thereto, and the syndrome generator <NUM> may generate a syndrome using, for example, at least one of Bose-Chaudhuri-Hocquenghen (BCH), Reed-Solomon (RS), and cyclic redundancy check (CRC) codes.

<FIG> is a ladder diagram illustrating an operating method of a storage system according to some exemplary embodiments. <FIG>, <FIG>, <FIG>, <FIG>, and <FIG> illustrate an example of a protocol through transmission/reception of packets between the first virtual machine VM <NUM> of the host <NUM> and the storage controller <NUM>. In more detail, packets between the first virtual machine VM <NUM> of the host <NUM> and the storage controller <NUM> may be managed through the packet manager <NUM>.

The first virtual machine VM <NUM> may request ECC operation information supportable by the storage device <NUM> from the storage controller <NUM> (S40). For example, the first virtual machine VM <NUM> may request information on a method in which the ECC engine <NUM> of the storage device <NUM> may generate a syndrome through the syndrome generator <NUM>.

In response to such a request, the storage controller <NUM> transmits the ECC operation information supportable by the storage device <NUM> to the first virtual machine VM <NUM> (S42). For example, the storage controller <NUM> may transmit the information on the method in which the ECC engine <NUM> of the storage device <NUM> may generate the syndrome through the syndrome generator <NUM>, as a response. For example, the storage controller <NUM> may transmit information indicating that the syndrome generator <NUM> of the ECC engine <NUM> may generate the syndrome using at least one of a low density parity check code (LDPC) and Bose-Chaudhuri-Hocquenghen (BCH), Reed-Solomon (RS), and cyclic redundancy check (CRC) codes, as the response. This is an example, and any information related to an operation of the ECC engine <NUM> may be transmitted as a response to information desired by the first virtual machine VM <NUM>.

The first virtual machine VM <NUM> determines a reliability request type according to a reliability request type required for the data of the first virtual machine VM <NUM> based on the response received from the storage controller <NUM>, includes the determined reliability request type in the command CMD, and transmits the command CMD with the reliability request type to the storage controller <NUM> (S44).

<FIG> is a flowchart illustrating another operating method of a storage device according to some exemplary embodiments. Referring to <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>, the command CMD generated by the first virtual machine VM <NUM> is transmitted from the host <NUM> to the storage controller <NUM> (S400). In this case, the command CMD generated by the first virtual machine VM <NUM> includes reliability request type information required for the data of the first virtual machine VM <NUM>.

The storage controller <NUM> detects reliability request type information of the data indicating which level of reliability the first virtual machine VM <NUM> requests for the data of the first virtual machine VM <NUM>, through the received command CMD (S410). Then, the storage controller <NUM> determines whether the first virtual machine VM <NUM> desires weak reliability (W: Weak), desires medium reliability (M: Medium), or desires strong reliability (S: Strong), for the data of the first virtual machine VM <NUM>, based on the reliability request type information included in the command CMD (S420). In this case, the number of reliability request types divided by the first virtual machine VM <NUM> is not limited thereto. For example, the reliability may also be divided into five types such as weak reliability, slightly weak reliability, medium reliability, slightly strong reliability, and strong reliability. The reliability may be divided according to various methods in which the ECC engine <NUM> may operate, and thus, is not limited to those in <FIG> and a description of <FIG>.

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Weak (W) level reliability, the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a first ECC operation type (S432). As an example, the first ECC operation type may be an operation of setting the number of times of iterative decoding of the LDPC to a minimum by the syndrome generator <NUM> of the ECC engine <NUM>. As another example, the first ECC operation type may be an operation of setting a flow of a defense code to a minimum.

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Medium (M) level reliability, the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a second ECC operation type (S434). As an example, the second ECC operation type may be an operation of setting the number of times of iterative decoding of the LDPC to a medium by the syndrome generator <NUM> of the ECC engine <NUM>. As another example, the second ECC operation type may be an operation of setting a flow of a defense code to a medium.

In a case where the reliability request type information included in the command CMD received from the first virtual machine VM <NUM> indicates Strong (S) level reliability, the storage controller <NUM> may perform an ECC operation on the data of the first virtual machine VM <NUM> using a third ECC operation type (S436). As an example, the third ECC operation type may be an operation of setting the number of times of iterative decoding of the LDPC to a maximum by the syndrome generator <NUM> of the ECC engine <NUM>. As another example, the third ECC operation type may be an operation of setting a flow of a defense code to a maximum.

It has been described above by way of example that different ECC operation types are applied in different cases to all data of the first virtual machine VM <NUM>, but different reliability request type information may be written into each of the plurality of data of the first virtual machine VM <NUM>, such that different ECC operation types may be applied to each of the plurality of data of the first virtual machine VM <NUM>.

<FIG> and <FIG> are block diagrams illustrating a storage system to which a storage device according to some exemplary embodiments is applied. A system <NUM> of <FIG> may be basically a mobile system such as a mobile phone, a smartphone, a tablet personal computer (PC), a wearable device, a healthcare device, or an Internet of things (IOT) device. However, the system <NUM> of <FIG> is not necessarily limited to the mobile system, and may be a personal computer, a laptop computer, a server, a media player, an automotive device such as a navigation device, or the like.

Referring to <FIG>, the system <NUM> may include a main processor <NUM>, memories 1200a and 1200b, and storage devices 1300a and 1300b, and may further include one or more of an image capturing device <NUM>, a user input device <NUM>, a sensor <NUM>, a communication device <NUM>, a display <NUM>, a speaker <NUM>, a power supplying device <NUM>, and a connecting interface <NUM>.

The main processor <NUM> may control a general operation of the system <NUM>, more specifically, operations of the other components constituting the system <NUM>. The main processor <NUM> may be implemented as a general-purpose processor, a dedicated processor, an application processor, or the like.

The main processor <NUM> may include one or more CPU cores <NUM>, and may further include a controller <NUM> for controlling the memories 1200a and 1200b and/or the storage devices 1300a and 1300b. According to exemplary embodiments, the main processor <NUM> may further include an accelerator <NUM>, which is a dedicated circuit for high-speed data operation such as artificial intelligence (AI) data operation. Such an accelerator <NUM> may include a graphics processing unit (GPU), a neural processing unit (NPU), a data processing unit (DPU), or the like, and may also be implemented as a separate chip physically independent from the other components of the main processor <NUM>.

The memories 1200a and 1200b may be used as main memory units of the system <NUM>, and may include volatile memories such as a static random access memory (SRAM) and/or a dynamic random access memory (DRAM), but may also include non-volatile memories such as a flash memory, a phase change random access memory (PRAM), and/or a resistive random access memory (RRAM). The memories 1200a and 1200b may also be implemented in the same package as the main processor <NUM>.

The storage devices 1300a and 1300b may function as non-volatile storage devices that store data regardless of whether or not power is supplied thereto, and may have a relatively greater storage capacity than the memories 1200a and 1200b. The storage devices 1300a and 1300b may include storage controllers 1310a and 1310b and non-volatile memories (NVMs) 1320a and 1320b that store data under the control of the storage controllers 1310a and 1310b, respectively. The non-volatile memories 1320a and 1320b may include flash memories having a <NUM>-dimensional (2D) structure or a <NUM>-dimensional (3D) vertical negative AND (V-NAND) structure, but may also include other types of non-volatile memories such as a PRAM and/or an RRAM.

The storage devices 1300a and 1300b may be included in the system <NUM> in a state in which they are physically separated from the main processor <NUM> or may be implemented in the same package as the main processor <NUM>. In addition, the storage devices 1300a and 1300b may have a form such as a solid state device (SSD) or a memory card to be detachably coupled to the other components of the system <NUM> through an interface such as a connecting interface <NUM> to be described later. Such storage devices 1300a and 1300b may be devices to which a standard protocol such as universal flash storage (UFS), embedded multi-media card (eMMC), or non-volatile memory express (NVMe) is applied, but are necessarily limited thereto.

The storage devices 1300a and 1300b may include the storage device described above with reference to <FIG>.

The image capturing device <NUM> may capture a still image or a moving image, and may be a camera, a camcorder, a webcam, or the like.

The user input device <NUM> may receive various types of data input from a user of the system <NUM>, and may be a touch pad, a keypad, a keyboard, a mouse, a microphone, or the like.

The sensor <NUM> may sense various types of physical quantities that may be obtained from the outside of the system <NUM> and convert the sensed physical quantities into electrical signals. Such a sensor <NUM> may be a temperature sensor, a pressure sensor, an illuminance sensor, a position sensor, an acceleration sensor, a biosensor, a gyroscope sensor, or the like.

The communication device <NUM> may transmit and receive signals to and from other devices outside the system <NUM> according to various communication protocols. Such a communication device <NUM> may be implemented to include an antenna, a transceiver, a modem, and the like.

The display <NUM> and the speaker <NUM> may function as output devices that output visual information and auditory information to the user of the system <NUM>, respectively.

The power supplying device <NUM> may appropriately convert power supplied from a battery (not illustrated) embedded in the system <NUM> and/or an external power source and supply the converted power to respective components of the system <NUM>.

The connecting interface <NUM> may provide a connection between the system <NUM> and an external device connected to the system <NUM> to be capable of transmitting and receiving data to and from the system <NUM>. The connecting interface <NUM> may be implemented in various interface manners such as an advanced technology attachment (ATA), a serial ATA (SATA), an external SATA (e-SATA), a small computer small interface (SCSI), a serial attached SCSI (SAS), a peripheral component interconnection (PCI), a PCI express (PCIe), an NVM express (NVMe) , an institute of electrical and electronic engineers (IEEE) <NUM>, a universal serial bus (USB), a secure digital (SD) card, a multi-media card (MMC), an embedded multi-media card (eMMC), a universal flash storage (UFS), an embedded UFS (eUFS), and a compact flash (CF) card interface.

Referring to <FIG>, a data center <NUM> is a facility collecting various data and providing services, and may also be referred to as a data storage center. The data center <NUM> may be a system for operating a search engine and a database, and may be a computing system used in a business such as a bank or a government institution. The data center <NUM> may include application servers 3100_1 to 3100_n and storage servers 3200_1 to 3200_m. The number of application servers 3100_1 to 3100_n and the number of storage servers 3200_1 to 3200_m may be variously selected according to exemplary embodiments, and the number of application servers 3100_1 to 3100_n and the number of storage servers 3200_1 to 3200_m may be different from each other.

The application server <NUM> or the storage server <NUM> may include at least one of a processor <NUM> or <NUM> and a memory <NUM> or <NUM>. Describing the storage server <NUM> by way of example, the processor <NUM> may control a general operation of the storage server <NUM>, and may access the memory <NUM> to execute an instruction and/or data loaded to the memory <NUM>. The memory <NUM> may be a double data rate synchronous DRAM (DDR SDRAM), a high bandwidth memory (HBM), a hybrid memory cube (HMC), a dual in-line memory module (DIMM), an Optane DIMM, and/or a non-volatile DIMM (NVMDIMM). According to exemplary embodiments, the number of processors <NUM> and the number of memories <NUM> included in the storage server <NUM> may be variously selected. In an exemplary embodiment, the processor <NUM> and the memory <NUM> may provide a processor-memory pair. In an exemplary embodiment, the number of processors <NUM> and the number of memories <NUM> may be different from each other. The processor <NUM> may include a single-core processor or a multi-core processor. The above description of the storage server <NUM> may be similarly applied to the application server <NUM>. According to exemplary embodiments, the application server <NUM> may not include a storage device <NUM>. The storage server <NUM> may include one or more storage devices <NUM>. The number of storage devices <NUM> included in the storage server <NUM> may be variously selected according to exemplary embodiments.

The storage device <NUM> may include the storage device described above with reference to <FIG>.

Claim 1:
A storage system, comprising:
a host (<NUM>);
a storage controller (<NUM>) configured to receive a first command (CMDa) from the host (<NUM>); and
a non-volatile memory device (<NUM>) configured to store first data (DATAa) for the first command (CMDa), and
wherein the storage controller (<NUM>) comprises an encryption/decryption engine (<NUM>) configured to perform encryption and decryption operations and to support at least a first cryptography algorithm and a second cryptography algorithm,
wherein the first command (CMDa) includes first encryption strength information for the first data (DATAa),
wherein the encryption/decryption engine (<NUM>) is configured to perform the encryption and decryption operations on the first data (DATAa) using
the first cryptography algorithm when the first encryption strength information indicates a weak (W) encryption strength, and
the second cryptography algorithm when the first encryption strength information indicates a strong (S) encryption strength, and
characterized in that
the host (<NUM>) includes a first virtual machine (VM <NUM>),
the first virtual machine (VM <NUM>) is configured to request supportable cryptography algorithm information from the storage controller (<NUM>), supportable cryptography algorithm information being information indicating cryptography algorithms supported by the encryption/decryption engine (<NUM>),
the storage controller (<NUM>) is further configured to transmit the supportable cryptography algorithm information to the first virtual machine (VM1) in response to the request, and
the first virtual machine (VM1) is further configured to:
determine the encryption strength for the first data (DATAa) based on the supportable cryptography algorithm information received from the storage controller (<NUM>),
generate the first command (CMDa),
include the determined encryption strength as the first encryption strength information in the first command (CMDa), and
transmit the first command (CMDa) including the first encryption strength information to the storage controller (<NUM>).