Computational Storage Drives

Abstract

To provide a computational storage drive for executing arithmetic processing in conjunction with internal events.SOLUTION: According to an embodiment, a computational storage drive comprises: a first memory for storing a program; a second memory accessible when the program is executed; a storage medium for storing data transmitted from a host; a processor for executing a program to perform data processing on the data stored in the second memory or the storage medium; a controller for, in response to a request from the host, writing data to or reading data from the storage medium, managing the storage medium, controlling the data processing, or controlling the execution of an asynchronous event that is independent processing of requests from the host. The controller transmits an asynchronous event occurrence notification to the host when the asynchronous event set by the host occurs.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] SUMMARY OF THE INVENTION An embodiment of the present invention relates to a storage drive with computing functionality. [Background technology]

[0002] Computational storage drives (hereafter referred to as CSDs) are known, which are storage drives that have built-in computing capabilities, allowing them to perform computational processing within the drive. When a host is connected to a storage drive that does not have computing capabilities, CSDs can perform computational processing within the storage drive, which would otherwise have to be performed by the host's CPU. This reduces the overhead of data transmission between the host and storage drive and the load on the host's CPU.

[0003] Conventional CSDs were unable to execute calculations in conjunction with internal events that were executed within them. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-175292 [Patent Document 2] Special Publication No. 2016-526716 [Patent Document 3] Patent Publication No. 2021-28762 [Patent Document 4] U.S. Patent No. 10,338,832 Summary of the Invention [Problem to be solved by the invention]

[0005] An object of the present invention is to provide a computational storage drive that executes computational processing in conjunction with internal events. [Means for solving the problem]

[0006] According to an embodiment, a computational storage drive includes a first memory that stores a plurality of programs, a second memory that is accessible when any of the plurality of programs is executed, a storage medium that stores data sent from a host, a processor that executes any of the plurality of programs and processes the data stored in the second memory, and a controller that writes data to the storage medium and reads data from the storage medium upon request from the host, manages the storage medium upon request from the host, and controls the execution of asynchronous events that are processes independent of requests from the host. When an asynchronous event occurs, the controller reads data from the storage medium, and the processor executes a program from the plurality of programs associated with the asynchronous event and processes the data read from the storage medium using the second memory, and the controller writes the processed data to the storage medium. The programs associated with the asynchronous event include at least one program specified by the host. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram illustrating an example of an information processing system including a CSD and a host according to an embodiment. [Figure 2] FIG. 2 is a diagram for explaining details of a CSD according to the embodiment. [Figure 3] FIG. 10 is a diagram for explaining an example in which the host according to the embodiment receives an asynchronous notification from a CSD and acquires information. [Figure 4] FIG. 2 is a diagram for explaining the state of a unit in a CSD according to the embodiment. [Figure 5] FIG. 10 is a diagram for explaining an example of host write in a CSD according to the embodiment. [Figure 6] 10A and 10B are diagrams for explaining an example in which an invalid data retention unit is generated by a host write in a CSD according to an embodiment. [Figure 7] FIG. 10 is a diagram for explaining an example of the start of garbage collection in the CSD according to the embodiment. [Figure 8] FIG. 10 is a diagram for explaining an example of data movement of valid data holding units in garbage collection in a CSD according to an embodiment. [Figure 9] FIG. 10 is a diagram for explaining an example of updating a lookup table in garbage collection in a CSD according to an embodiment. [Figure 10] FIG. 10 is a diagram for explaining an example of freeing a zone in garbage collection in a CSD according to an embodiment. [Figure 11] FIG. 10 is a block diagram for explaining an example of asynchronous notification settings in a CSD according to an embodiment. [Figure 12] FIG. 10 is a block diagram for explaining an example of a function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 13] FIG. 10 is a timing chart for explaining an example of a function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 14] FIG. 10 is a timing chart for explaining another example of the function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 15] FIG. 10 is a timing chart for explaining yet another example of the function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 16] FIG. 10 is a timing chart for explaining yet another example of the function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 17] FIG. 10 is a diagram for explaining an example of a host command for realizing an example of a function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 18] FIG. 10 is a diagram for explaining an example of a host command for realizing another example of the function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 19]FIG. 10 is a diagram for explaining an example of a host command for realizing yet another example of the function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 20] FIG. 10 is a diagram for explaining an example of a host command for realizing yet another example of the function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 21] FIG. 10 is a diagram for explaining an example of a host command for realizing yet another example of the function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 22] FIG. 10 is a diagram for explaining an example of a host command for realizing yet another example of the function of starting a program in conjunction with an internal event in the CSD according to the embodiment. [Figure 23] FIG. 10 is a diagram for explaining an example of a host command for realizing an example of a function of starting a program in conjunction with garbage collection in the CSD according to the embodiment. [Figure 24] FIG. 10 is a diagram for explaining an example of a host command for realizing an example of a function of starting a program in conjunction with garbage collection in the CSD according to the embodiment. [Figure 25] FIG. 10 is a diagram for explaining an example of a function for starting a program in conjunction with garbage collection according to the embodiment. [Figure 26] FIG. 10 is a diagram for explaining an example of the state of a CSD according to an embodiment when data is modified. [Figure 27] FIG. 10 is a diagram for explaining an example of the state of a CSD according to an embodiment when data is not modified. [Figure 28] FIG. 10 is a diagram for explaining another example of the state of the CSD according to the embodiment when data is modified. [Figure 29] FIG. 10 is a diagram for explaining another example of the state of the CSD according to the embodiment when data is not modified. [Figure 30] FIG. 10 is a diagram for explaining another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 31]FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 32] FIG. 10 is a diagram for explaining an example of a host command for realizing a function of starting a program in conjunction with garbage collection by a CSD according to an embodiment. [Figure 33] FIG. 10 is a flow diagram illustrating an example of a process for starting a program in conjunction with garbage collection by a CSD according to an embodiment. [Figure 34] FIG. 10 is a diagram for explaining another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 35] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 36] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 37] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 38] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 39] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 40] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 41] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 42] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 43]FIG. 10 is a diagram for explaining processing in yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 44] FIG. 10 is a diagram for explaining another process in yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 45] FIG. 10 is a diagram for explaining still another process in yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 46] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 47] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 48] FIG. 10 is a diagram for explaining yet another example of the function of starting a program in conjunction with garbage collection by the CSD according to the embodiment. [Figure 49] FIG. 2 is a diagram for explaining an example of data conversion by a CSD according to the embodiment. [Figure 50] FIG. 10 is a diagram for explaining another example of data conversion by CSD according to the embodiment. [Figure 51] FIG. 10 is a diagram for explaining an example of log compaction by a CSD according to the embodiment. [Figure 52] FIG. 10 is a diagram for explaining an example of changing the order of physical addresses by a CSD according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0008] Hereinafter, embodiments will be described with reference to the drawings. The following description exemplifies devices and methods for embodying the technical concepts of the embodiments. The technical concepts of the embodiments are not limited to the structures, shapes, arrangements, materials, etc. of the components described below. Modifications that can be easily conceived by those skilled in the art are naturally included within the scope of the disclosure. For clarity of explanation, the drawings may schematically depict elements with different sizes, thicknesses, planar dimensions, shapes, etc., compared to the actual embodiment. Elements with different dimensional relationships or ratios may be included in multiple drawings. Corresponding elements may be designated by the same reference numerals in multiple drawings, and redundant description may be omitted. Some elements may be designated by multiple names, but these designations are merely examples and do not necessarily mean that these elements may be designated by other names. Furthermore, elements that do not have multiple names may also be designated by other names. In the following description, "connection" may include not only direct connection but also connection via other elements.

[0009] Hereinafter, the present embodiment will be described in detail with reference to the drawings.

[0010] In this embodiment, the startup of a computational program (CPRG) that executes a computing function in a computational storage drive (CSD) is linked to various internal events executed within the CSD. This provides CSD users with greater flexibility in designing the startup timing of the CPRG. Furthermore, by delaying the execution of a non-time-sensitive CPRG until an internal event occurs in the storage drive, power consumption by the storage drive can be reduced.

[0011] In addition, the embodiment links CPRG activation to garbage collection (hereinafter referred to as GC) in a CSD that has a flash translation layer (hereinafter referred to as FTL) internally, among other internal events.

[0012] With conventional technology, when an application needs to read, process, and write back large amounts of data stored in the CSD, the data read and write back processing by the GC can overlap. By linking the GC with the initiation of the CPRG, this overlap can be eliminated, improving the performance and extending the life of the CSD.

[0013] FIG. 1 is a block diagram illustrating an example of an information processing system including a CSD2 and a host 4 according to an embodiment. The background technologies relating to the CSD2 and CPRG, and the FTL and GC will be described below with reference to FIG. 1. It should be noted that there are no commonly accepted, unified terms for expressing the elements that make up these technologies, and the same names are often used with different meanings by different users. For this reason, the following explanation will also serve as a definition of terms for this document. In other words, "called" here means "shall be called."

[0014] The host 4 includes a CPU 6 and a host memory (hereinafter referred to as HM) as functional modules.

[0015] The CSD 2 includes a plurality of functional modules, examples of which include a storage medium 10, a front-end controller (hereinafter referred to as FE) 12, a back-end controller (hereinafter referred to as BE) 14, slots 16, a computational storage engine (hereinafter referred to as CSE) 18, a computational program memory (hereinafter referred to as CPM) 20, and a storage controller memory (hereinafter referred to as SCM) 22.

[0016] The storage medium 10 is a physical medium that stores data written from the host 4. An example of the storage medium 10 is a non-volatile memory (hereinafter referred to as NVM). Examples of non-volatile memory include NAND-type flash memory and a magnetic disk.

[0017] The FE12 is a module that controls communication with the host 4. The FE12 analyzes commands received from the host 4 and distributes them to the subsequent BE14 and CSE18. The FE12 also manages the entire CSD, which is not performed by the BE14 or CSE. The FE12 includes a processor that operates based on a program for executing these processes. The FE12 may also be equipped with hardware that executes some of these processes.

[0018] The BE14 is a module that controls the storage medium 10. The BE14 controls the storage of data passed from the host 4 in the storage medium 10 in response to a write request from the host 4, and the reading of data from the storage medium 10 in response to a read request from the host 4. The BE14 controls the FTL. The BE14 includes a processor that operates based on a program for executing these processes. The BE14 may also include hardware that executes some of these processes.

[0019] Slot 16 is an area for storing CPRGs 24. One or more slots 16 may be provided within CSD 2. Each slot 16 can store the corresponding number of CPRGs 24. CPRGs 24 are distinguished by their slot numbers. Slot 16 may be configured, for example, with DRAM.

[0020] The CSE 18 performs computational storage control (hereinafter referred to as CS control) in response to computational storage control commands (hereinafter referred to as CS commands) from the host 4 and CS control requests from the BE 14 and FE 12. One or more CSEs 18 are provided within the CSD 2. The CSE 18 is hardware that executes the CPRG 24. In one example, the CSE 18 is a processor. When the CPRG 24 is executed, a group of information, such as a stack, required for program execution is expanded in memory. This expanded memory image is called a CPRG instance. Multiple CPRG instances may be started simultaneously using the same CPRG 24. When multiple CSEs 18 are provided, as many CPRG instances as there are CSEs 18 can be executed simultaneously. The same CPRG may be executed simultaneously as multiple CPRG instances.

[0021] CPRG24 is a program stored in slot 16 and executed on CSE 18. CPRG24 includes fixed CPRGs that are pre-installed in CSD2 by CSD2 vendors, and downloadable CPRGs that CSD2 users download to CSD2 for use. How CPRG24 handles arguments and return values, as well as the startup method, will be described later.

[0022] The CPM 20 is a RAM area accessible from the CPRG 24. Using the CPM 20, data transfer between the HM 8 and the storage medium 10 is possible. The CPM 20 is configured by, for example, DRAM.

[0023] The SCM 22 is a RAM area required for processing the FE 12 and the BE 14. The SCM 22 is configured by, for example, an SRAM.

[0024] The BE 14, FE 12, SCM 22, and CSE 18 may be referred to as a CSDC (CSD Controller) 28 without distinction. The CSDC 28 may be configured as a single package device. The CSDC 28 may be configured as an SoC, for example.

[0025] 2 is a diagram illustrating the relationship between the CPRG 24 and the CSDC 28 according to an embodiment. When the CSDC 28 starts executing the CPRG 24, this is called "launching." This "launch" may include an argument. When the CPRG 24 finishes executing, it may return a return value to the CSDC 28.

[0026] The control interface that allows CPRG24 to set and query CSDC28 while it is running is called a CPRG helper function.

[0027] [CPRG24 arguments and return values] The CPRG 24 can use arguments. These arguments are called CPRG parameters. The CPRG parameters can include either host parameters passed from the host 4 or CSD parameters passed from the CSDC 28, or both.

[0028] An example of the structure of a CPRG parameter is shown below. { host_param, csd_param } host_param is a host parameter passed from the host 4 to the CSD 2, and may be a pointer to a parameter set allocated in the CPM 20. The CSD user can freely decide what to pass as the host parameter when designing the CPRG 24.

[0029] csd_param is a CSD parameter passed from CSD2 to host 4, and may be a pointer to a parameter set placed in CPM20. In this specification, host parameters are used in the following functions detailed hereinafter:

[0030] [Host parameter setting function and internal event-driven CPRG startup function] [GC-driven CPRG startup function (basic)] H_SET_GC_DRIVEN_CPRG_HOST_PARAM() [SRC single unit, GC driven CPRG startup function] Combining these functions with the host parameter setting function enables more flexible conditional determination of which LUA range to process when a request is made between the host 4 and CSD 2. LUA is a type of logical address, and details will be described later.

[0031] This function can be used, for example, to pass LUA range information for which CPRG 24 performs data conversion processing to the host parameter.

[0032] CPRG24 may return a return value upon completion.

[0033] Here, we define a CPRG of a traditional CSD as returning the following values: A traditional CSD is a CSD that does not have a mechanism for activating a CPRG in response to an internal event. { host_ret csd_ret } host_ret is a return value passed from the CSD 2 to the host 4, and may be a pointer to a parameter set allocated in the CPM 20.

[0034] csd_ret is a return value passed from the host 4 to the CSD 2, and may be a pointer to a parameter set allocated in the CPM 20.

[0035] Here, the CPRG startup method refers to the method by which the CSD2 executes the CPRG24. Examples of CPRG startup methods in conventional CSDs are as follows:

[0036] (1) CPRG execution command-driven startup method The CPRG execution command driven activation method is a method in which execution is performed by a CPRG execution command, which is a command issued by the host 4 to the CSD 2.

[0037] (2) IO command driven startup method The IO command driven activation method is a method in which the CPRG 24 is executed in conjunction with a write or read IO command for accessing the storage medium 10. The IO command is a command issued by the host 4 to the CSD 2.

[0038] [Host Command] Host commands are commands issued by the host 4 to the CSD 2. For the sake of convenience in the following explanation, a conventional CSD is defined as having the following command group. Note that the definitions given here are provided solely for the convenience of use in the explanation of this specification. In reality, functions that can achieve equivalent functionality without using the command interface (IF) described here are considered conventional functions.

[0039] [Common matters] The response from CSD2 to the host 4 in response to a host command is RET (status) unless a special explanation is provided for the command. This response returns a status of success or error. Success indicates that the processing for the host command was successful, and error indicates that the processing for the host command failed.

[0040] [Admin Commands] This is a group of commands for the host 4 to manage the CSD 2. There are commands for inquiring about the storage drive capabilities, inquiring about the status, managing the status, etc. Here, the following three commands related to obtaining information for asynchronous notifications are defined.

[0041] (1) Asynchronous notification setting command: H_CONF_ASYNC(event_flag) This command is used to set that when an asynchronous event of CSD2 specified by event_flag occurs, a response is returned to the asynchronous notification request command set by the host 4. An asynchronous event is a process that is independent of requests from the host.

[0042] (2) Asynchronous notification request command: H_REQ_ASYNC() This command requests asynchronous notification.

[0043] In response to this command, a response: RET(status, event, log_id) is defined that returns a status of success or error, the asynchronous event type, and a log ID that stores detailed information.

[0044] (3) Log acquisition command: H_GET_LOG(log_id,hm_addr) This command is used to acquire the information of the log ID specified by log_id into the HM8 area indicated by the address hm_addr.

[0045] FIG. 3 is a diagram illustrating an example in which the host 4 according to the embodiment receives an asynchronous notification from the CSD 2 and acquires information.

[0046] An asynchronous event A occurs in CSD2 (#1). At this point, CSD2 does not make any particular response.

[0047] The host 4 issues a command H_CONF_ASYNC() to set that there is a notification response for asynchronous events A and C, and that there is no notification response for asynchronous event B (#2). The CSD2 returns a response RET() to this command.

[0048] Host 4 sends the command H_REQ_ASYNC() (#3).

[0049] Host 4 sends the command H_REQ_ASYNC() (#4).

[0050] An asynchronous event C occurs in the CSD 2 (#5). As the asynchronous event A is set to have a notification response, the CSD 2 returns to the host 4 a response RET(C, log_c) to the command H_REQ_ASYNC() in #3.

[0051] The host 4 confirms the response RET(C, log_c) and issues a command H_GET_LOG() to obtain detailed information (#6). The CSD 2 returns a response RET() to this command.

[0052] Asynchronous event B occurs in CSD2 (#7). Since no notification response is set for asynchronous event B, CSD2 does not take any particular action.

[0053] An asynchronous event A occurs in the CSD 2 (#8). Since the presence of a notification response is set for the asynchronous event A, the CSD 2 returns to the host 4 the response RET(A, log_a) of the command H_REQ_ASYNC() in #4.

[0054] The host 4 confirms the response RET(A, log_a) and issues the command H_GET_LOG( ) to obtain detailed information (#9). The CSD 2 returns the response RET( ) to this command.

[0055] [IO Command] This is a group of commands for accessing the storage medium 10. The access unit from the host 4 is a logical block (hereinafter also referred to as LB), and the access location is specified by a logical block address (hereinafter also referred to as LBA).

[0056] Define the following two commands:

[0057] (1) Write command: H_WRITE(lba,hm_addr,lbn) This command is used to write data at address hm_addr in HM8 to lbn consecutive LB areas starting from logical block address lba.

[0058] (2) Read command: H_READ(hm_addr,lba,lbn) This command is used to read data from lbn consecutive LB areas starting from logical block address lba to address hm_addr within HM8.

[0059] [CS Command] This is a group of commands for controlling the CS. The following commands are defined.

[0060] (1) CPM TX command: H_TX (cpm_addr, hm_addr, size) This command is used to transfer data of size from address hm_addr in the HM8 to address cpm_addr in the CPM20.

[0061] (2) CPM RX command: H_RX (hm_addr,cpm_addr,size) This command is used to transfer data of size from address cpm_addr in the CPM 20 to address hm_addr in the HM 8.

[0062] (3) CPRG load command: H_LOAD (slot, hm_addr) This command is used to download CPRG24 from address hm_addr in HM8 to slot number slot.

[0063] (4) CPRG execution command: H_EXEC(slot,cpm_addr) This command is used to execute the CPRG 24 stored in slot number slot. When starting the CPRG 24, the H_EXEC() command specifies cpm_addr, an address within the CPM 20 specified by the command, as the argument host_param of the CPRG 24.

[0064] For this command, a command: RET(status, host_ret) is defined that returns a status of success or error and the return value of CPRG24, host_ret.

[0065] [CPM IO commands] This is a command for specifying the CPM 20 as the source and destination buffers of an IO command that accesses the storage medium 10 .

[0066] (1) CPM write command: H_WRITE_WC(lba,cpm_addr,lbn) This command is used to write data at address cpm_addr in the CPM 20 to lbn consecutive LB areas starting from logical block address lba.

[0067] (2) CPM read command: H_READ_WC(cpm_addr,lba,lbn) This command is used to read data from lbn consecutive LB areas starting from logical block address lba to address cpm_addr in the CPM 20.

[0068] The CPRG startup method according to the embodiment is an event-linked method, unlike the (1) CPRG execution command-driven startup method and (2) IO command-driven startup method of conventional CSDs. Before explaining the CPRG startup method according to the embodiment, we will first provide an overview of FTL and GC.

[0069] [FTL·LUT·Zone·LUA·PUA] The CSD 2 must respond to random write and random read requests in logical block units from the host 4. The CSD 2 also incorporates a storage medium 10, and if the characteristics of this storage medium 10 impose restrictions on the write order and erase unit, such as in the case of NAND-type flash memory, the CSD 2 must manage the correspondence between the logical addresses specified by the host 4 and the physical addresses within the storage medium 10. This mapping management between logical addresses and physical addresses is called FTL.

[0070] Here, a description will be given of a storage medium 10 having the following media characteristics, including definitions of terms related to FTL and GC.

[0071] ·The writing unit is a unit The erasure unit is a zone A zone consists of multiple units. - Writing to units must be done sequentially from the first unit of the zone after erasing the zone. Data reading can be performed randomly on a unit basis The FTL manages the mapping between logical addresses and physical addresses on a unit basis in accordance with these media characteristics.

[0072] The logical address for each unit is called LUA (Logical Unit Address).

[0073] The physical address of each unit is called a PUA (Physical Unit Address). A PUA consists of a combination of a zone number and a unit number within the zone.

[0074] The conversion table from LUA to PUA is called LUT (Look Up Table).

[0075] Note that the unit size here does not necessarily have to match the write size (so-called page) of a single program command to a so-called NAND flash memory. Furthermore, the unit size does not necessarily have to match the size of a logical block specified by the host 4. The explanation of the unit is intended to mean that it can be logically handled in units of units in terms of address translation management by the FTL.

[0076] If the size of a page or logical block differs from the unit size, the adjustment is intended to be made outside the FTL address translation mechanism. For example, consider the following processing.

[0077] (1) N consecutive logical blocks are treated as one unit, and conversion from logical block address to LUA is obtained by dividing one unit by N. Write requests from host 4 of a size less than one unit are converted and processed as read-modify-write in units. Read requests of a size less than one unit are read in units, and the required portion is extracted and returned to host 4.

[0078] (2) Multiple consecutive units are treated as one page, and when writing to flash memory, write requests for units equal to the page size are grouped together as one program command.

[0079] Next, FTL and GC will be explained as requests from the host 4 and accesses to the storage media 10 on the address space in units of units.

[0080] [Zone Unit Status] The zone state can be one in which all units are unwritten, one in which one unit is being written, or one in which all units have been written. These states are called free, dst, and used.

[0081] When distinguishing between the zone to be written to by a host write and the zone to be written to by a GC, the state of the zone to be written to by a host write is called host_dst, and the state of the zone to be written to by a GC is called gc_dst. Zones to be written to include zones that have been selected as the zone to be written to by a host write and are about to be written to, and zones that have been selected as the zone to be written to, have already been partially written to, and are about to be written to. The state of the zone to be read from by a GC is called gc_src.

[0082] The unit state includes an unwritten state, a state holding valid data, and a state holding invalid data. FIG. 4 is a diagram for explaining the state of the unit in the drawing of this embodiment. Valid data means the value of the unit pointed to by the LUT. Invalid data is data other than valid data. Invalid data is also called non-valid data. An example of invalid data may be FTL management information. In the following explanation of the figures, as shown in FIG. 4, an unwritten unit in which neither valid data nor invalid data is stored, a valid data holding unit in which valid data is stored (held), and an invalid data holding unit in which invalid data is stored (held) are displayed in a distinguishable manner.

[0083] [FTL GC behavior] The operation will be explained using an FTL with 0x80 units per zone and 0x30 zones as an example. When a number is preceded by "0x", it indicates that the number is in hexadecimal notation. When a number is written in XX in the notation zone=XX, XX is a hexadecimal value and indicates that it is the XXth zone. When a number is written in YY and ZZ in the notation PUA=YY_ZZ, YY and ZZ are both hexadecimal values ​​and indicate that it is the ZZth unit in the YYth zone.

[0084] [Step 1: LUT management by host writer] 5 is a diagram illustrating an example in which the FTL according to the embodiment manages the state of zones using the LUT in step 1. When all zones are free and data A, B, and C are written from the host 4 to LUA=a, b, and c in that order, the FTL selects one of the free zones (zone=00 in this case) as dst and writes the data sequentially.

[0085] In this way, the state of the write destination zone of a write request (host write) from the host 4 is called host_dst.

[0086] [Step 2: Generation of invalid data units] 6 is a diagram illustrating an example in which the FTL according to the embodiment manages the state of a zone using the LUT in step 2. After step 1, when data B' is written to LUA=b, the FTL writes the value of data B' to PUA=00_03 and sets address b of the LUT to 00_03. As a result, there is no longer any reference to the unit with PUA=00_01, and the state of the unit transitions to an invalid data holding unit.

[0087] [Step 3: GC] If writing continues, there will be multiple used zones containing invalid data units within the zone. If the number of free zones falls below a certain number, it will no longer be possible to allocate a zone to be used as host_dst when a write request is made from host 4.

[0088] For this reason, FTL collects only the data of valid data units from the used zone and rewrites it to another zone, and erases the old zone after the migration as necessary and returns it to free. This is GC.

[0089] Below, we will explain how GC proceeds using an example in which zone=20 is assigned to the zone in the gc_dst state, and zone=10 in the used state is selected as gc_src.

[0090] [Step 3-1: GC Start] 7 is a diagram illustrating an example in which an FTL according to an embodiment manages the state of zones using an LUT when GC starts. Fig. 7 illustrates a state (#a1) in which zone 20 is being written to as gc_dst and zone 10 has been selected as gc_src from a used state. "inv" indicates invalid data.

[0091] In zone 10, there are units with valid data scattered around, with PUA=10_00, 10_02, 10_1f, ... The LUA=d, e, f addresses in the LUT each point to the PUA of the corresponding unit in zone 10. In zone 20, PUA=20_00, ...20_10 are units with valid data.

[0092] [Step 3-2: Data transfer for valid data holding units] FIG. 8 is a diagram for explaining an example in which the FTL according to the embodiment manages the state of a zone using the LUT when data of a valid data holding unit is moved.

[0093] The FTL reads the data (value of data D with PUA=00_00) of the valid data holding unit (0x00th unit) from gc_src (zone=10) to the SCM 22 (#a2), and writes it to the unit (PUA=20_11) of gc_dst (zone=20) (#a3).

[0094] At this time, the PUA at address LUA=d in the LUT points to 10_00, so PUA=20_11 is still invalid data.

[0095] [Step 3-3: Update the LUT] FIG. 9 is a diagram for explaining an example in which the FTL according to the embodiment manages the state of a zone using the LUT when updating the LUT.

[0096] The FTL checks whether the data in the source unit remains valid (whether the PUA of LUA=d remains 10_00). If the data in the source unit is valid, the FTL rewrites the pointer of LUA=d to the destination address (PUA=20_11) (#a4).

[0097] As a result, the unit with PUA=10_00 becomes an invalid data holding unit, and the unit with PUA=20_11 becomes a valid data holding unit.

[0098] If the data in the copy source unit is not still valid, the FTL assumes that a host write occurred at the address LUA=d during the execution of step 3-2, and does not update the LUT. This allows for exclusive processing of writes from host 4 and writes by the GC.

[0099] [Step 3-4: Free gc_src] FIG. 10 is a diagram for explaining an example in which the FTL according to the embodiment manages the state of the zone using the LUT when gc_src is set to free.

[0100] By repeating the same unit data movement and LUT update as in [Steps 3-2, 3-3], all units in gc_src will become invalid. When this state is reached, the data in the gc_src zone is erased and the gc_src zone becomes a free zone (#a5).

[0101] [GC Purpose and Characteristics] GC is performed for the following purposes:

[0102] (1) GC purpose, i.e., to acquire writable area by releasing invalid area.

[0103] (2) Refresh purpose: In accordance with the data retention characteristics of the storage medium 10, that is, the characteristic that the reliability of data written to a certain zone deteriorates over time, data in a zone that has been written for some time is moved to another zone.

[0104] (3) For the purpose of wear leveling, the number of erasures of all zones of the storage medium 10 is equalized to match the characteristics of deterioration in lifespan due to the number of erasures of each zone of the storage medium 10, thereby extending the product lifespan.

[0105] (1) In GC for GC purposes, gc_src is selected from zones that contain many invalid data units. This means that zones that contain many hot data are selected as gc_src in a relatively short period of time.

[0106] On the other hand, for (2) refresh purposes and (3) wear leveling purposes, gc_src is selected from zones that have been written a long time ago. This means that data written by host 4 will be moved by GC at a certain frequency, even if it is cold data.

[0107] The timing of starting GC can be said to be indirectly related to writing from the host 4, but is directly determined within the CSD 2 asynchronously with host control.

[0108] [Use of zones according to data attributes] There is a technology that is expected to improve FTL performance by using different zones to write data depending on the attributes of the data being written. Examples are given below.

[0109] By grouping high and low write frequencies into the same zone, it becomes possible to separate zones where a lot of invalid data occurs from zones where almost no invalid data occurs, which increases GC efficiency and leads to an improvement in the write amplification factor (WAF). The write amplification factor is an index that indicates how many times the amount of data supplied from the host 4 is written to the storage media 10.

[0110] By utilizing technologies such as the use of SLC / TLC / QLC, it is possible to distinguish between "zones with high capacity costs but high-speed access" and "zones with low capacity costs but only slow access." By allocating data with high read frequency to the former and data with low read frequency to the latter, it is possible to optimize the system as a whole, providing "fast read response for data with high read frequency and large-capacity storage for data with low read frequency."

[0111] SLC / TLC / QLC are write modes that relate to how many bits of data are written to a memory cell of the storage medium 10. The storage medium 10 can perform write operations using multiple write modes that differ depending on how many bits of data are written per memory cell. A write mode in which one bit of data is written per memory cell is called SLC (Single Level Cell) mode. A write mode in which three bits of data are written per memory cell is called TLC (Triple Level Cell) mode. A write mode in which four bits of data are written per memory cell is called QLC (Quad Level Cell) mode. There may also be a write mode in which two bits of data are written per memory cell.

[0112] [Application and GC overlap] Among the applications that use storage drives, there are those that perform the following processes, for example.

[0113] There are cases where you want to read data stored on a storage drive, modify the data according to specific rules, and then write it back to the storage drive. Although the write back does not need to be done urgently, there are cases where a large amount of data is written back.

[0114] In order to achieve this in the prior art, one of the following methods is used.

[0115] (1) For non-CSD storage drives Step 1: The host reads data from the storage drive to host memory.

[0116] Step 2: The host CPU processes the data in the host memory.

[0117] Step 3: The host writes the data from host memory back to the storage drive.

[0118] (2) Conventional CSDs Step 1: CSDC reads data from the storage media to CPM20.

[0119] Step 2: CPRG processes the data on CPM20.

[0120] Step 3: The CSDC writes the data on the CPM20 back to the storage media.

[0121] On the other hand, storage drives that have FTL built in perform large amounts of "data reading" and "data writing back" asynchronously with host processing during GC processing.

[0122] For the reasons explained in [Purpose and Characteristics of GC], GC is performed at a certain frequency even if the written data is cold data.

[0123] In other words, both non-CSD storage drives and traditional CSDs experience overlapping large amounts of data read and write operations by GC (i.e., controlled by the storage drive) and applications (i.e., controlled by the host). This results in the following:

[0124] (1) It consumes the IO bandwidth of the storage media on the storage drive, which leads to a decrease in the performance of the application processing that you want to perform. (2) Storage media has a limit to the number of times a zone can be erased. As a result, increasing the number of erases increases the error rate, increases the time it takes to read and write data from the storage media, and reduces the available storage media capacity. Multiple write overlaps shorten the lifespan of the storage drive.

[0125] Examples of overlapping large-volume data reads and large-volume data writes include the following.

[0126] (Example 1) Data conversion (single unit, same LUA) There are cases where a single unit of data stored in a certain LUA on a storage medium is read, the data is modified according to specific rules, and then written back to the same LUA. The data conversion does not need to be done quickly, but it must be done in large quantities.

[0127] (Example 2) Data conversion (multiple units, same LUA) There are cases where data of multiple units size stored in a certain LUA group on storage media is read, the data is modified according to specific rules, and then written back to the same LUA group. The data conversion does not need to be done quickly, but it must be done in large quantities.

[0128] (Example 3) Compaction When data stored on storage media is deemed unnecessary, host applications may perform compaction to reduce storage media usage and improve performance. Compaction is similar to GC, but the difference is that GC is performed by the FTL in the drive, while compaction is performed by the host. When compaction is performed, the LUA allocated to the unnecessary data is released. Compaction does not need to be performed urgently.

[0129] (Example 4) Changing the PUA address order A series of data that should be contiguous in LUA may be discontiguous in PUA. This can happen if the host writes data in a random order, or if the host writes data sequentially to LUA but writes other data at the same time.

[0130] Considering storage performance, you may want to change the PUA address order so that they are contiguous even on a PUA basis.

[0131] (Example 5) Sorting data attributes There are cases where you want to check the contents of the data stored on storage media and sort the data storage location according to its attributes so that the relevant data can be placed in a location on the storage media that is appropriate for the data's attributes. By placing data in a location that is appropriate for its attributes, such as Hot / Cold, the performance of the storage media can be improved.

[0132] (Example 6) Data movement There are times when you want to move data stored on a storage medium and in one LUA to another LUA.

[0133] (Example 7) Data conversion (multiple units, non-identical LUA) There are cases where it is necessary to read data of a size of multiple units stored in a certain LUA group on a storage medium, convert the data in accordance with specific rules, and write it back to a LUA group different from the LUA group from which it was read.

[0134] [No mechanism for linking CPRG to internal events in the storage drive] In addition to GC, storage drives also manage various internal events, such as timer events, events detecting an excess of a temperature threshold, error occurrence events, and periodic data scan read processing events to maintain the reliability of data stored on the storage media.

[0135] Conventional CSDs do not have a mechanism for activating CPRGs in response to such internal events, which posed the following challenges:

[0136] (1) The freedom in timing of CPRG activation was limited.

[0137] The CPRG could only be started when a CPRG start command was executed from the host, or when an IO command such as read or write was executed, which meant that users of conventional CSDs had little freedom in designing the CPRG.

[0138] (2) There was a large overhead involved in performing processing linked to internal events.

[0139] Because CPRG cannot process events, the host application must handle them. To do this, the conventional CSD must notify the host of an event occurrence, and the host must then carry out the desired processing.

[0140] This results in the overhead of notifying the host each time an event occurs, and the consumption of host resources due to the processing being performed on the host. Furthermore, if the processing linked to the event includes a status query of the conventional CSD, further communication overhead occurs between the host and CSD.

[0141] (3) Waste of power consumption was occurring.

[0142] A conventional CSD may be set to a sleep mode to reduce power consumption during periods when there are no requests from the host and when the storage drive does not need to process internal events.

[0143] To start the CPRG in conjunction with an internal event, the host sends a host command to start the CPRG to the conventional CSD. If the conventional CSD was in sleep mode at the time of this command, it had to switch from sleep mode to normal mode in order to execute the CPRG. Even if the contents of the CPRG were not time-sensitive, the conventional CSD still had to power up its own related circuits to execute the CPRG, resulting in wasted power consumption.

[0144] The following describes the functions required for the mechanism in which the CSD according to the embodiment links the activation of the CPRG to an internal event.

[0145] [1. Asynchronous notification setting function] [1.1. Asynchronous notification setting function from CPRG24 to host 4] The CPRG 24 sends an asynchronous notification to the host 4 at a timing that is asynchronous with the processing of the host 4 .

[0146] FIG. 11 is a block diagram for explaining an example of an asynchronous notification setting function in the CSD 2 according to the embodiment.

[0147] The CSDC 28 has the functions of asynchronous notification and information acquisition for the host 4. The CSDC 28 has, as an asynchronous notification function module, an asynchronous event controller (hereinafter referred to as AEC) 42, which is a function module that responds to the host commands H_CONF_ASYNC() and H_REQ_ASYNC(). The CSDC 28 has, as an information acquisition function module, a log controller (hereinafter referred to as LOGC), which is a function module that responds to the host command H_GET_LOG().

[0148] Events that the host 4 can specify with the host command A_CONF_ASYNC() include "CPRG asynchronous notification."

[0149] The log_id that the host 4 can specify with the host command H_GET_LOG() includes "CPRG log."

[0150] AEC42 includes a CPRG helper function: c_set_async_notice() for setting a "CPRG asynchronous notification" from CPRG24.

[0151] LOGC44 includes a CPRG helper function: c_set_log() to set the "CPRG log" from CPRG24.

[0152] The CPRG helper function: c_set_log() allows you to specify cpm_addr and size as arguments so that the log 46 created by the CPRG 24 on the CPM 20 can be imported into the LOGC 44.

[0153] As a simple example, the example shown here includes one type of event, "CPRG asynchronous notification," that can be specified with the host command A_CONF_ASYNC(), and one type of log_id, "CPRG log," that can be specified with the host command H_GET_LOG().

[0154] As an advanced version of this, multiple types of event and log_id may be specified, such as using different event and log_id depending on the CPRG activation cause.

[0155] Even in a conventional CSD, the host commands A_CONF_ASYNC(), H_REQ_ASYNC(), and H_GET_LOG() may be defined. In this case, the host command interface may use the same commands as these conventional host commands for the host commands A_CONF_ASYNC(), H_REQ_ASYNC(), and H_GET_LOG() according to the embodiments, distinguishing them by arguments, or may define them as separate commands.

[0156] According to [1. Asynchronous Notification Setting Function], the CPRG 24 can send asynchronous notifications to the host 4.

[0157] [2. Internal event-driven CPRG startup function (basic form)] This explains the function by which CSD2 activates CPRG24 in response to an internal event.

[0158] An internal event may be any event that occurs asynchronously with control from the host 4, such as a notification from a timer in the CSD2, a notification from a temperature sensor in the CSD2, or a notification that the usage of the storage media 10 in the CSD2 has reached a threshold. Here, we will explain the basic configuration in which there is one type of event and one target slot (CPRG).

[0159] [2.1. Internal event-driven CPRG launch function] FIG. 12 is a block diagram for explaining an example of an internal event-driven CPRG activation function in the CSD 2 according to the embodiment.

[0160] The CSDC 28 includes an Event Driven CPRG Controller (hereinafter referred to as EDCC) 52 that activates the CPRG 24 in response to an internal event 54 .

[0161] The EDCC52 has the following features:

[0162] (1) A function that responds to a setting command from the host 4 to enable or disable internal event-driven CPRG startup.

[0163] The host 4 has, as a host command, an internal event-driven function enable command: H_ENABLE_EVENT_DRIVEN_CPRG() that enables the function of starting the CPRG 24 in conjunction with an internal event.

[0164] The host 4 has, as a host command, an internal event-driven function disable command: H_DISABLE_EVENT_DRIVEN_CPRG() that disables the function of starting the CPRG 24 in conjunction with an internal event. (2) When the internal event-driven function is enabled, this function starts CPRG24 when an event occurrence notification is received from the CSD2's internal event generator.

[0165] Figure 13 is a timing diagram for explaining an example of control between the host 4, CSDC28, and CPRG24 when [1. Internal event-driven CPRG activation function (basic form)] and [1.1. Asynchronous notification setting function unit from CPRG24 to host 4] are combined in accordance with an embodiment.

[0166] An internal event occurs within CSDC 28 (#b1). At this point, the internal event-driven function is disabled, and no special processing is performed.

[0167] Although this is asynchronous with the processing of #b1, the host 4 issues a command H_CONF_ASYNC() to the CSDC 28 to set "CPRG asynchronous notification" (#b2).

[0168] The host 4 issues a command H_REQ_ASYNC() to the CSDC 28 (#b3, #b4).

[0169] The host 4 issues a command H_ENABLE_EVENT_DRIVEN_CPRG() to the CSDC 28 to enable the internal event-driven function (#b5).

[0170] Although it is asynchronous with the processing of #b5, an internal event occurs within CSDC 28 (#b6). At this point, the internal event-driven function is enabled, so the processing of #b7 is immediately performed.

[0171] The CSDC 28 starts the CPRG 24 (#b7). The CPRG 24 performs calculation processing and has something to notify the host 4. At that time, #b8 and #b9 are executed.

[0172] CPRG24 sets the log to be transmitted to host 4 to CSDC28 using the command c_set_log() (#b8).

[0173] The CPRG 24 sets the asynchronous notification requirement to the CSDC 28 using the command c_set_async_notice(), which conveys the "CPRG asynchronous notification" to the host 4 (#b9).

[0174] With the setting of #b9, the CSDC 28 returns a response (asynchronous notification) to the command H_REQ_ASYNC() of #b3 to the host 4 (#b3'). The CPRG 24 ends (#b7').

[0175] Host 4 receives the asynchronous notification from CPRG 24 and issues host GET_LOG() to obtain a detailed log as needed (#b10).

[0176] Although it is asynchronous with the processing of #b10, an internal event occurs within CSDC 28 (#b11). At this point, the internal event-driven function is enabled, so the processing of #b12 is immediately performed.

[0177] The CSDC 28 starts the CPRG 24 (#b12). The CPRG 24 performs calculation processing and assumes that there is nothing to notify the host 4 of. #b13 is executed. The CPRG 24 then terminates (#b12').

[0178] Although it is asynchronous with the processing of #b12, the host 4 issues a command H_DISABLE_EVENT_DRIVEN_CPRG() to the CSDC 28 to disable the internal event-driven function (#b13).

[0179] Although it is asynchronous with the processing of #b13, an internal event occurs within CSDC28 (#b14). At this point, the internal event-driven function is disabled, so no special processing is performed.

[0180] FIG. 14 is a timing diagram for explaining another example of control between the host 4, the CSDC 28, and the CPRG 24 according to the embodiment.

[0181] In the control example of FIG. 13, when an internal event-driven function disable command H_DISABLE_EVENT_DRIVEN_CPRG() is issued while CPRG 24 is being executed, a response may be returned after waiting for the execution of CPRG 24 to finish, as shown in FIG.

[0182] While CPRG24 is running, host 4 issues the command H_DISABLE_EVENT_DRIVEN_CPRG() (#c1).

[0183] The CSDC 28 waits for the execution of the CPRG 24 to finish. When the execution of the CPRG 24 finishes (#c2), the CSDC 28 returns a response to the command H_DISABLE_EVENT_DRIVEN_CPRG() to the host 4 (#c3).

[0184] This allows the host 4 to recognize that the execution of the CPRG 24 has completely finished.

[0185] [2.2. Multi-instance support and internal event-driven CPRG launch function] The EDCC 52 included in the CSDC 28 may have an internal event-driven CPRG startup function that supports multiple instances. The multi-instance internal event-driven CPRG startup function is a function that, when a CPRG 24 is started in response to an internal event and the next internal event occurs while the CPRG 24 is being executed, starts execution of the next CPRG 24 if there are free resources in the CSE 18.

[0186] 15 is a timing diagram illustrating an example of a multi-instance, internal event-driven CPRG activation function in a CSD 2 according to an embodiment. FIG. 15 illustrates multi-instance, internal event-driven CPRG activation when the number of CSEs 18 is two.

[0187] An internal event occurs within CSDC28 (#d1). At this point, the number of instances of CPRG24 is 0. Because there is an available CSE18, CSDC28 starts CPRG24 and creates CPRG instance 1. The number of instances becomes 1.

[0188] An internal event occurs within CSDC28 (#d2). At this point, the number of instances of CPRG24 is 1. Because there is an available CSE18, CSDC28 starts CPRG24 and creates CPRG instance 2. The number of instances becomes 2.

[0189] An internal event occurs in CSDC28 (#d3). At this point, the number of CPRG24 instances is 2. Since there is no available CSE18, CSDC28 does not start CPRG24.

[0190] The processing of CPRG instance 1 started in process #1 ends (#d1´). At this point, the number of instances of CSDC28 becomes 1.

[0191] An internal event occurs within CSDC28 (#d4). At this point, the number of instances of CPRG24 is 1. Because there is an available CSE18, CSDC28 starts CPRG24 and creates CPRG instance 1.

[0192] FIG. 15 illustrates, as a simple example, a method in which if there are no resources available when an event occurs, the event is simply ignored.

[0193] Alternatively, the EDCC 52 may remember the occurrence of an event and delay the start of the CPRG 24 until the CSE 18 has free resources.

[0194] It is assumed that the CPRG 24 will use resources such as the CPM 20 when executing arithmetic processing.

[0195] When multiple CPRG instances are running simultaneously, EDCC52 may pass a CSD instance number (a number that uniquely identifies a CSD instance) to the csd_param argument of CPRG24 so that each CPRG instance knows which resources to use.

[0196] Furthermore, there may be cases where the host 4 wants fewer instances to be simultaneously started than the number of CSEs 18 due to resource allocation reasons of the CPM 20. To address this, a function may be provided to set an upper limit on the number of instances that can be simultaneously started by the internal event-driven CPRG 24.

[0197] According to [2.2. Multi-instance support and internal event-driven CPRG startup function], when an internal event is issued while a CPRG instance is running, if there is spare resource in CSE18, the next CPRG24 will be started.

[0198] In addition, when the next internal event is issued while the maximum number of CPRG instances are running, the occurrence of the internal event may be stored and CPRG24 may be started after waiting for the currently running CPRG instance to finish.

[0199] When CPRG 24 is started, CPRG 24 may pass a CSD parameter csd_param containing a CSD instance number to host 4 .

[0200] The host 4 may issue an internal event-driven CPRG concurrent execution upper limit setting command: H_SET_MAX_EVENT_DRIVEN_CPRG(num) that sets the upper limit on the number of internal event-driven CPRG instances that can be executed simultaneously.

[0201] [2.3. Host parameter setting function and internal event-driven CPRG startup function] The EDCC 52 included in the CSDC 28 has a function of allowing the host 4 to set host parameters to be passed to the CPRG 24 when the CPRG 24 is started.

[0202] In a conventional CSD, a CPRG is started in synchronization with a CPRG execution command or IO command issued by the host. In this case, the host can set host parameters as arguments to the CPRG start command.

[0203] In the case of the CSD according to the embodiment, a CPRG instance is generated asynchronously with the host command, so it is necessary to separately pass host parameters to the CSD 2. Several methods for passing host parameters are shown below.

[0204] (1) Host parameter fixed method This is the simplest method for setting host parameters. In this method, host_param is added to the internal event-driven function enable command. The same value is set for the host parameter of all instances started while the function is enabled.

[0205] Internal event-driven function enable command (host_param extension): H_ENABLE_EVENT_DRIVEN_CPRG(host_param) enables the internal event-driven function, and passes host_param as an argument to CSD2 when CPRG24 is started.

[0206] (2) Host parameter setting command method This method provides a host parameter setting command, which allows the value of the host parameter of a CPRG instance to be dynamically changed while the internal event-driven function is enabled.

[0207] The internal event-driven function host parameter setting command: H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM (host_param) sets the host parameters of the CPRG instance that is started by an internal event.

[0208] (3) Host parameter setting command method for each instance number This method provides commands that can set host parameters for each CPRG instance number. With this method, host parameter values ​​can be dynamically changed for each CPRG instance while the internal event-driven function is enabled.

[0209] Internal event-driven function host parameter setting command (extended for each instance number): H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM (instance_no, host_param) sets the host parameters of the CPRG instance that is started by the internal event specified by the instance number instance_no.

[0210] FIG. 16 is a timing diagram for explaining an example of host parameter setting by the host parameter setting command method in the CSD 2 according to the embodiment.

[0211] The host 4 issues the command H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(A) to the CSDC 28 to set "A" as the host parameter of the CPRG 24 that is activated by the internal event (#e1). The host parameter "A" can be a numeric value, a character string, or data with an even more complex data structure.

[0212] The host 4 issues a command H_SET_ENABLE_EVENT_DRIVEN_CPRG() to the CSDC 28 to enable the internal event-driven function (#e2).

[0213] Although it is asynchronous with the processing of #e2, an internal event occurs within CSDC28 (#e3). CSDC28 starts CPRG24. At this time, CSDC28 specifies "A" as the argument host_param of the started CPRG24 instance.

[0214] Although it is asynchronous with the processing of #e3, an internal event occurs within CSDC28 (#e4). CSDC28 starts CPRG24. At this time, CSDC28 specifies "A" as the argument host_param of the started CPRG24 instance.

[0215] An internal event occurs within CSDC28 (#e5). CSDC28 starts CPRG24. At this time, CSDC28 specifies "A" as the argument host_param of the started CPRG24 instance.

[0216] Although it is asynchronous with the processing of #e5, the host 4 issues a command H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(B) to the CSDC 28, and sets B as the host parameter of the CPRG that is activated by the internal event (#e6).

[0217] Although it is asynchronous with the processing of #e6, an internal event occurs within CSDC28 (#e7). CSDC28 starts CPRG24. At this time, CSDC28 specifies "B" as the argument host_param of the started CPRG24 instance.

[0218] While the CPRG instance created in step #e7 is running, host 4 issues the command H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(C) to CSDC 28, setting the host parameter of the CPRG started by the internal event to "C" (#e8). Before returning a response to host 4 (#e8´), CSDC 28 waits for the termination of the running CPRG instance with host_param=B before switching.

[0219] While waiting for the CPRG instance to finish, an internal event occurs in CSDC28 (#e9). CSDC28 starts CPRG24. At this time, CSDC28 specifies "C" for the argument host_param.

[0220] The CPRG instance running with argument host_param=B is terminated (#e7´).

[0221] After processing #e7', the CSDC 28 returns a response to the command H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM() in #e8 to the host 4 (#e8').

[0222] Note that if there is a CPRG instance running with the previous parameters when the command H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM() is issued, waiting for the termination of that CPRG instance may be omitted.

[0223] [2.4. Configuration function and internal event-driven CPRG startup function] The EDCC 52 included in the CSDC 28 has a function for setting the configuration of the internal event-driven function from the host 4.

[0224] The EDCC 52 has an interface for setting the activation conditions as configuration, such as "activate the CPRG only when the temperature exceeds a threshold value" for an event such as "temperature change detection," or "activate the CPRG when an interval time has elapsed since the event was detected" for a timer event. Several configuration setting methods are shown below.

[0225] (1) Fixed configuration method This is the simplest configuration setting method. In this method, a configuration value "configuration" is added to the internal event-driven function enable command. The same configuration value is applied while the function is enabled.

[0226] Internal event-driven function enable command (configuration extension): H_ENABLE_EVENT_DRIVEN_CPRG(configuration) specifies the configuration and enables the internal event-driven function.

[0227] (2) Configuration setting command method This method provides a configuration setting command, which allows configuration values ​​to be changed dynamically while the internal event-driven function is enabled.

[0228] The internal event-driven function configuration setting command: H_SET_EVENT_DRIVEN_CPRG_CONFIG (configuration) sets the configuration of the internal event-driven function.

[0229] The timing for setting the configuration in this method is the same as that explained in (2) Host Parameter Setting Command Method (Figure 16) in [2.3. Host Parameter Setting Function and Internal Event-Driven CPRG Startup Function], so the explanation will be omitted.

[0230] [2. Internal Event Driven CPRG Startup Function] allows CSD2 users to have more freedom in designing the startup timing of the CPRG24. Processing linked to internal events can now be performed by the CPRG24 rather than the host 4, reducing the amount of communication between the CSD2 and the host 4. Power consumption can be reduced by delaying the startup of the non-time-sensitive CPRG24 until the CSD2 wakes up due to internal event processing. Multiple CPRG instances can be started simultaneously in response to internal events. Parameter settings from the host 4 to the CPRG24 linked to internal events can be set at the timing desired by the host 4. Configuration settings for CPRG startup linked to internal events can be set at the timing desired by the host 4.

[0231] [3. Internal event-driven CPRG launch function (multi-event, multi-slot)] The example explained above in [2. Internal Event-Driven CPRG Launch Function (Basic)] has one type of event and one target slot. Below we will show examples where there are multiple slots and event types.

[0232] [3.1. Single-event, multi-slot, single-connection, internal event-driven CPRG startup function] This function is an internal event-driven CPRG launch function that has one type of internal event that triggers the CPRG, multiple slots that can be launched, and only one slot that can be connected per event.

[0233] This function is realized by extending the host command shown in [2. Internal event-driven CPRG activation function (basic form)].

[0234] FIG. 17 is a diagram for explaining an example of a host command for CSD2 to realize the single event, multi-slot, single connection, internal event driven CPRG activation function.

[0235] The host command H_ENABLE_EVENT_DRIVEN_CPRG() has a slot added to its parameters.

[0236] The host commands H_DISABLE_EVENT_DRIVEN_CPRG(), H_SET_MAX_EVENT_DRIVEN_CPRG(), H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(), and H_SET_EVENT_DRIVEN_CPRG_CONFIG() remain unchanged.

[0237] [3.2. Single-event, multi-slot, multi-connection, internal event-driven CPRG startup function] This function is an internal event-driven CPRG launch function that has one type of internal event that triggers the CPRG, multiple slots that can be launched, and multiple slots that can be connected per event.

[0238] There are two main methods for achieving this function.

[0239] (1) A method in which multiple different CPRG instances are started for each specified slot for a single event (independent instance type). (2) A method in which one CPRG instance is launched for one event and CPRG24 in the specified slot is executed sequentially (same instance type).

[0240] As mentioned above, an instance refers to the memory area and its contents that are expanded in memory when a program is executed and that hold the program's arguments, intermediate states during program execution, etc. When program A is executed, one instance exists until program A terminates. If program A is executed again while program A is running, two instances exist while the two executions are running in parallel.

[0241] Therefore, the independent instance type is a method in which one instance is generated for one CPRG stored in each slot. For example, suppose CPRG_A is stored in slot α, CPRG_B is stored in slot β, and one event has two connections. If slot α is specified for one connection and slot β is specified for the other connection, when the event occurs, CSDC28 will launch instance 1, which runs CPRG_A, and instance 2, which runs CPRG_B, in parallel. In other words, CPRG_A and CPRG_B will run in parallel.

[0242] The same-instance type is a method in which multiple CPRGs stored in specified slots are executed sequentially within a single instance. For example, suppose CPRG_A is stored in slot α, CPRG_B is stored in slot β, and one event has one connection. A list consisting of slot α and slot β is passed as an argument for one connection to connect to the event. When an event occurs, CSDC28 creates instance 1, executes CPRG_A on that instance, and executes CPRG_B when execution of CPRG_A is completed.

[0243] [3.2.1. Single event, multi-slot, multi-connection (independent instance type), internal event-driven CPRG startup function] This function is realized by extending the host command shown in [2. Internal event-driven CPRG activation function (basic form)].

[0244] FIG. 18 is a diagram for explaining an example of a host command for CSD2 to realize the single event, multi-slot, multi-connection (independent instance type), internal event-driven CPRG activation function.

[0245] A new host command, H_CONNECT_EVENT_DRIVEN_CPRG(), is defined. The argument to this command is the slot number. This command sets CSD2 to connect to slot 16 specified by the slot number, i.e., to start CPRG24, when an internal event occurs. CSD2 returns the connection number to the host 4 in the response RET() to this command. If a slot number different from the already connected slot number is specified in the argument, CSD2 returns the new connection number to the host 4 in the response RET(). The connection number is a number assigned to uniquely identify the connection between the internal event and the slot. In the case of a single event, the connection number can be omitted, but it is returned to the host 4 to align the command system with that of multiple events.

[0246] A new host command, H_UNCONNECT_EVENT_DRIVEN_CPRG(), is defined. The argument to this command is a connection number. This command sets CSD2 to terminate the connection with slot 16 specified by the connection number when an internal event occurs.

[0247] The host commands H_ENABLE_EVENT_DRIVEN_CPRG(), H_DISABLE_EVENT_DRIVEN_CPRG(), H_SET_MAX_EVENT_DRIVEN_CPRG(), H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(), and H_SET_EVENT_DRIVEN_CPRG_CONFIG() have a connection number added to their parameters.

[0248] [3.2.2. Single event, multi-slot, multi-connection (same instance type), internal event-driven CPRG activation function] This function is realized by extending the host command shown in [2. Internal event-driven CPRG activation function (basic form)].

[0249] FIG. 19 is a diagram for explaining an example of a host command for CSD2 to realize the single event, multi-slot, multi-connection (same instance type), internal event-driven CPRG activation function.

[0250] A new host command, H_CONNECT_EVENT_DRIVEN_CPRG(), is defined. A list of slot numbers is specified as an argument to this command. This command sets CSD2 to connect to multiple slots 16 specified in the list of slot numbers when an internal event occurs. CSD2 returns the connection number to the host 4 in the response RET() to this command. For example, if three CRRGs, slot=1, slot=3, and slot=8, are connected to one event, one connection number is returned to the host 4. If that connection number is specified and the host command H_UNCONNECT_EVENT_DRIVEN_CPRG() is issued, the connections to all three CPRGs are simultaneously released. If the connections are reset before being released, CSD2 returns a new list of connection numbers to the host 4 in the response RET().

[0251] An example of a connection number will be described.

[0252] For example, suppose you call H_CONNECT_EVENT_DRIVEN_CPRG three times as follows:

[0253] H_CONNECT_EVENT_DRIVEN_CPRG(event=event_a,slot=1) H_CONNECT_EVENT_DRIVEN_CPRG(event=event_b,slot=2) H_CONNECT_EVENT_DRIVEN_CPRG(event=event_c,slot=1) The connection number is a number used to distinguish between connections made by each host command; 1 is returned as the first connection number, 2 as the second connection number, and 3 as the third connection number.

[0254] In this example, slot=1 is specified for event_a and slot=1 is also specified for event_c, and the same slot=1 CPRG is connected to multiple events. Therefore, if you want to cancel the first connection, you cannot specify the connection to be canceled using the slot number, but must specify the connection to be canceled using the connection number.

[0255] A new host command, H_UNCONNECT_EVENT_DRIVEN_CPRG(), is defined. The argument to this command is a connection number. This command sets CSD2 to terminate the connection with slot 16 specified by the connection number when an internal event occurs.

[0256] The host commands H_ENABLE_EVENT_DRIVEN_CPRG(), H_DISABLE_EVENT_DRIVEN_CPRG(), H_SET_MAX_EVENT_DRIVEN_CPRG(), H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(), and H_SET_EVENT_DRIVEN_CPRG_CONFIG() have a connection number added to their parameters.

[0257] [3.3. Multi-event, multi-slot, single-connection, internal event-driven CPRG startup function] This function is an internal event-driven CPRG activation function that has multiple types of internal events that can be used to activate a CPRG, multiple slots that can be activated, and a single slot that can be connected per event.

[0258] This function is realized by extending the host command shown in [2. Internal event-driven CPRG activation function (basic form)].

[0259] FIG. 20 is a diagram for explaining an example of a host command for CSD2 to realize the multi-event, multi-slot, single-connection, internal event-driven CPRG activation function.

[0260] The host commands H_ENABLE_EVENT_DRIVEN_CPRG(), H_DISABLE_EVENT_DRIVEN_CPRG(), H_SET_MAX_EVENT_DRIVEN_CPRG(), H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(), and H_SET_EVENT_DRIVEN_CPRG_CONFIG() are extended to the host commands H_ENABLE_EVENT_X_DRIVEN_CPRG(), H_DISABLE_EVENT_X_DRIVEN_CPRG(), H_SET_MAX_EVENT_X_DRIVEN_CPRG(), H_SET_EVENT_X_DRIVEN_CPRG_HOST_PARAM(), and H_SET_EVENT_X_DRIVEN_CPRG_CONFIG(), respectively.

[0261] The host command H_ENABLE_EVENT_X_DRIVEN_CPRG() divides the command and provides a command for each event. For example, EVENT_X is set to EVENT_X, EVENT_Y is set to EVENT_Y, and slot is added to the parameters.

[0262] Similarly, the host commands H_DISABLE_EVENT_X_DRIVEN_CPRG(), H_SET_MAX_EVENT_X_DRIVEN_CPRG(), H_SET_EVENT_X_DRIVEN_CPRG_HOST_PARAM(), and H_SET_EVENT_X_DRIVEN_CPRG_CONFIG() are divided into commands, with a command provided for each event.

[0263] FIG. 21 is a diagram for explaining another example of a host command for CSD2 to realize the multi-event, multi-slot, single-connection, internal event-driven CPRG activation function.

[0264] The host command H_ENABLE_EVENT_DRIVEN_CPRG() is extended to add the event type and slot to its parameters.

[0265] The host commands H_DISABLE_EVENT_DRIVEN_CPRG(), H_SET_MAX_EVENT_DRIVEN_CPRG(), H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(), and H_SET_EVENT_DRIVEN_CPRG_CONFIG() are extended to add event types to their parameters.

[0266] [3.4. Multi-event, multi-slot, multi-connection, internal event-driven CPRG startup function] This function can be realized by combining [3.2. Single-event, multi-slot, multi-connection, internal event-driven CPRG activation function] and [3.3. Multi-event, multi-slot, single-connection, internal event-driven CPRG activation function].

[0267] Below, we will explain [3.4. Multi-event, multi-slot, multi-connection, internal event-driven CPRG startup function] when [3.2.1. Single event, multi-slot, multi-connection (independent instance type), internal event-driven CPRG startup function] is adopted as [3.2. Single event, multi-slot, multi-connection, internal event-driven CPRG startup function].

[0268] FIG. 22 is a diagram for explaining an example of a host command for CSD2 to realize the multi-event, multi-slot, multi-connection, internal event-driven CPRG activation function.

[0269] The host commands H_CONNECT_EVENT_X_DRIVEN_CPRG() and H_UNCONNECT_EVENT_X_DRIVEN_CPRG() are newly defined.

[0270] A slot number is specified as an argument to the host command H_CONNECT_EVENT_X_DRIVEN_CPRG(). This command sets CSD2 to connect to slot 16 specified by the slot number when an internal event occurs. CSD2 returns the connected connection number to the host 4 in the response RET() to this command.

[0271] A connection number is specified as an argument to the host command H_UNCONNECT_EVENT_X_DRIVEN_CPRG(). This command sets CSD2 to release the connection with the slot 16 specified by the connection number when an internal event occurs.

[0272] The host command H_ENABLE_EVENT_X_DRIVEN_CPRG() divides the command and provides a command for each event. The parameter connect is added to this command.

[0273] The host command H_DISABLE_EVENT_X_DRIVEN_CPRG() divides the command and provides a command for each event.

[0274] The host commands H_SET_MAX_EVENT_DRIVEN_CPRG(), H_SET_EVENT_X_DRIVEN_CPRG_HOST_PARAM(), and H_SET_EVENT_X_DRIVEN_CPRG_CONFIG() are divided into commands, with a command provided for each event. Connect is added to the parameters of these commands.

[0275] [3. Internal Event Driven CPRG Launch Function (Multi-Event / Multi-Slot)] allows one or more of the following effects to be achieved simultaneously as a CSD2 linked to an internal event. In the case of multi-slot, it is possible to register multiple types of programs from the host 4 to be launched in conjunction with internal events. In the case of multi-connection, it is possible to specify multiple types of programs to be linked to one event. In the case of independent instance, it is possible to launch an independent instance for each program linked to one event. In the case of same instance, it is possible to launch multiple programs linked to one event in sequence on one instance. In the case of multi-event, it is possible to specify multiple types of internal events to link the launch of CPRG24.

[0276] [4.GC-driven CPRG launch function] Of the internal event-driven CPRG activation functions mentioned above, the function of activating the CPRG 24 in conjunction with GC will be described in particular.

[0277] The GC-driven CPRG startup function adds new functions to the GC itself in addition to the CPRG24 startup function in response to internal events, allowing for new effects not available with a simple internal event-driven CPRG startup function.

[0278] The GC-driven CPRG activation function may be combined with any of the internal event-driven CPRG activation functions listed above, but for simplicity's sake, we will use an example of combining it with [2. Internal event-driven CPRG activation function (basic form)].

[0279] [4.1.GC-driven CPRG startup function (basic)] FIG. 23 is a diagram for explaining an example of a host command for realizing a combined function of [2. Internal event-driven CPRG activation function (basic form)] and the GC-driven CPRG activation function.

[0280] The host command H_ENABLE_GC_DRIVEN_CPRG() enables the GC driven function.

[0281] The host command H_DISABLE_GC_DRIVEN_CPRG() disables the GC driven function.

[0282] In addition to the basic internal event-driven CPRG startup function [2. Internal Event-Driven CPRG Startup Function (Basic)], GC-driven CPRG startup can also be implemented using its expanded functions [2.2. Multi-Instance Compatible Internal Event-Driven CPRG Startup Function] or [3.4. Multi-Event, Multi-Slot, Multi-Connection Internal Event-Driven CPRG Startup Function], or by combining multiple of these expanded functions. In this case, the EVENT or EVENT_X host command listed above is replaced with GC.

[0283] Figure 24 is a diagram for explaining an example of a host command for realizing a combined function of [2.2. Multi-instance compatible, internal event-driven CPRG startup function] to [3.4. Multi-event, multi-slot, multi-connection, internal event-driven CPRG startup function] and the GC-driven CPRG startup function.

[0284] Like the host command H_CONNECT_EVENT_DRIVEN_CPRG(), the host command H_CONNECT_GC_DRIVEN_CPRG() specifies a slot number as an argument. The host command H_CONNECT_GC_DRIVEN_CPRG() sets CSD2 to connect to the slot 16 specified by the slot number during GC, i.e., to start up the CPRG 24. CSD2 returns the connection number to the host 4 in the response RET() to this command. If a slot number different from the already connected slot number is specified in the argument, CSD2 returns the new connection number to the host 4 in the response RET().

[0285] Like the host command H_UNCONNECT_EVNET_DRIVEN_CPRG(), the host command H_UNCONNECT_GC_DRIVEN_CPRG() specifies a connection number as an argument. The host command H_UNCONNECT_GC_DRIVEN_CPRG() sets CSD2 to terminate the connection with the slot 16 specified by the connection number during GC.

[0286] The host command H_ENABLE_GC_DRIVEN_CPRG() enables the GC driven function, similar to the host command H_ENABLE_EVENT_DRIVEN_CPRG().

[0287] The host command H_DISABLE_GC_DRIVE_CPRG() disables the GC driven function, similar to the host command H_DISABLE_EVENT_DRIVE_CPRG().

[0288] The host command H_SET_MAX_GC_DRIVEN_CPRT() sets the upper limit on the number of GC-driven CPRG instances that can be executed simultaneously, similar to the host command H_SET_MAX_EVENT_DRIVEN_CPRT().

[0289] The host command H_SET_GC_DRIVEN_CPRG_HOST_PARAM() sets the host parameters of the GC-driven CPRG 24 in the same way as the host command H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM().

[0290] The host command H_SET_GC_DRIVEN_CPRG_CONFIG() sets the configuration of the GC driven function, similar to the host command H_SET_EVENT_DRIVEN_CPRG_CONFIG().

[0291] The commands defined in [2. Internal event-driven CPRG activation function] are H_ENABLE_EVENT_DRIVEN_CPRG() and H_DISABLE_EVENT_DRIVEN_CPRG().

[0292] The command defined in [2.2. Multi-instance support and internal event-driven CPRG startup function] is H_SET_MAX_EVENT_DRIVEN_CPRT(num).

[0293] The commands defined in [2.3. Internal Event-Driven CPRG Startup Function with Host Parameter Setting Function] are (1) H_ENABLE_EVENT_DRIVEN_CPRG(host_param), (2) H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(host_param), and (3) H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(instance_no,host_param).

[0294] The commands defined in [2.4. Internal Event-Driven CPRG Startup Function with Configuration Function] are (1) H_ENABLE_EVENT_DRIVEN_CPRG(configuration) and (2) H_SET_EVENT_DRIVEN_CPRG_CONFIG(configuration).

[0295] The commands defined in [3.1. Single Event, Multi-Slot, Single Connection, Internal Event Driven CPRG Startup Function] are H_ENABLE_EVENT_DRIVEN_CPRG(*,slot), H_DISABLE_EVENT_DRIVEN_CPRG(*), H_SET_MAX_EVENT_DRIVEN_CPRG(*), H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(*), and H_SET_EVENT_DRIVEN_CPRG_CONFIG(*).

[0296] The commands defined in [3.2.1. Single event, multi-slot, multi-connection (independent instance type), internal event-driven CPRG startup function] are H_CONNECT_EVENT_DRIVEN_CPRG(), H_UNCONNECT_EVENT_DRIVEN_CPRG(), H_ENABLE_EVENT_DRIVEN_CPRG(*,connect), H_DISABLE_EVENT_DRIVEN_CPRG(*,connect), H_SET_MAX_EVENT_DRIVEN_CPRG(*,connect), H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(*,connect), and H_SET_EVENT_DRIVEN_CPRG_CONFIG(*,connect).

[0297] The commands defined in [3.2.2. Single event, multi-slot, multi-connection (same instance type), internal event-driven CPRG startup function] are H_CONNECT_EVENT_DRIVEN_CPRG(), H_UNCONNECT_EVENT_DRIVEN_CPRG(), H_ENABLE_EVENT_DRIVEN_CPRG(*,connect), H_DISABLE_EVENT_DRIVEN_CPRG(*,connect), H_SET_MAX_EVENT_DRIVEN_CPRG(*,connect), H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(*,connect), and H_SET_EVENT_DRIVEN_CPRG_CONFIG(*,connect).

[0298] The commands defined in [3.3. Multi-event, multi-slot, single connection, internal event-driven CPRG startup function] are: (1) H_ENABLE_EVENT_X_DRIVEN_CPRG(), H_DISABLE_EVENT_X_DRIVEN_CPRG(), H_SET_MAX_EVENT_X_DRIVEN_CPRG(), H_SET_EVENT_DRIVEN_X_CPRG_HOST_PARAM(), H_SET_EVENT_DRIVEN_X _CPRG_CONFIG(), (2)H_ENABLE_EVENT_DRIVEN_CPRG(*,event,slot), H_DISABLE_EVENT_DRIVEN_CPRG(*,event), H_SET_MAX_EVEN T_DRIVEN_CPRG(*,event), H_SET_EVENT_DRIVEN_CPRG_HOST_PARAM(*,event), H_SET_EVENT_DRIVEN_CPRG_CONFIG(*,event).

[0299] The commands defined in [3.4. Multi-event, multi-slot, multi-connection, and internal event-driven CPRG startup functions] are H_CONNECT_EVENT_X_DRIVEN_CPRG(), H_UNCONNECT_EVENT_X_DRIVEN_CPRG(*,connect), H_ENABLE_EVENT_X_DRIVEN_CPRG(*,connect), H_DISABLE_EVENT_X_DRIVEN_CPRG(*,connect), H_SET_MAX_EVENT_X_DRIVEN_CPRG(*,connect), H_SET_EVENT_X _DRIVEN _CPRG_HOST_PARAM(*,connect), and H_SET_EVENT_X _DRIVEN _CPRG_CONFIG(*,connect).

[0300] The GC performed by FTL was explained in "Step 3: GC" in the above [FTL GC Operation]. In this embodiment, the process of "Step 3-2: Data movement of valid data holding units" in Step 3 is changed as follows when the GC-driven function is enabled.

[0301] FIG. 25 is a diagram for explaining [4. GC-driven CPRG activation function].

[0302] The CSDC 28 stores the valid data "D" read from gc_src in the CPM 20 (#f1).

[0303] CSDC28 starts CPRG24, which is linked to the GC-driven function (#f2).

[0304] The CPRG 24 receives the data "D" on the CPM 20 read from gc_src as input, performs arithmetic processing, and outputs the processing result "D'" to the CPM 20 (#f3).

[0305] It is also acceptable for the processing result of CPRG24 to be no change. In this case, instead of outputting the same data as the input data, it is acceptable to return information indicating "no change."

[0306] The CSDC 28 stores the output result "D'" of the CPRG 24 in the gc_dst zone (#f4).

[0307] If the processing result of CPRG24 is unchanged, the same data as that read from gc_src is stored in the gc_dst zone.

[0308] The subsequent processing, which corresponds to [Step 3-3: Update LUT], is the same as that explained in [Step 3: GC] of the above [FTL·GC Operation].

[0309] The CSD 2 according to this embodiment makes it possible to change data as desired by an application at the timing when valid data is moved to a different zone by GC.

[0310] The input and output data are stored in the CPM 20, but the CSDC 28 knows when these data storage areas start and end use. Therefore, the CSDC 28 manages the acquisition and release of buffer areas. The CPRG 24 places output data in the buffer areas that the CSDC 28 has permitted use of.

[0311] There are no particular limitations on the buffer management method used by CSDC 28. A fixed buffer area may be assigned based on the CPRG instance number, or a buffer area may be dynamically assigned each time a CPRG instance is started. A CPRG instance can find out the location of its assigned buffer area using csd_param, etc.

[0312] For simplicity's sake, we will assume that the address in the CPM 20 where each piece of input data from the CSDC28 to the CPRG24, passed using csd_param, and output data from the CPRG24 to the CSDC28, passed using csd_param or csd_ret, is located can be distinguished by the cpm buffer number. However, a method of distinguishing between these data using the cpm address (cpm_address) instead of the cpm buffer number can also be used. A cpm address is expressed as an integer with many digits, such as 0x123456789abc0000, but a cpm buffer number can be expressed as an integer with fewer digits, such as 1 to 10.

[0313] The CSDC 28 passes the cpm buffer number in which the input data is stored to the CPRG 24 via csd_param. The CPRG 24 returns to the CSDC 28 via csd_param and csd_ret whether the data has been modified by the CPRG 24's calculation processing, and if so, the cpm buffer number in which the output data is stored.

[0314] The following describes the configuration of csd_param and the state of the cpm buffer when data is modified by the CPRG 24 in the CSD 2 according to the embodiment and when it is not modified.

[0315] FIG. 26 is a diagram for explaining the configuration of csd_param and the state of the cpm buffer when data is modified.

[0316] FIG. 27 is a diagram for explaining the configuration of csd_param and the state of the cpm buffer when data is not modified.

[0317] The csd_param of the input data (INPUT) to the CPRG24 includes the cpm buffer number src_cpm_buff_id of the CPM20. The csd_param of the output data (OUTPUT) of the CPRG24 includes the status (status) and the cpm buffer number dst_cpm_buff_id of the CPM20. If there are modifications, the status (status) of the csd_param from the CPRG24 is set to modified. If there are no modifications, the status (status) of the csd_param from the CPRG24 is set to none. If there are modifications, the cpm buffer number dst_cpm_buff_id of the csd_param from the CPRG24 is set to (out1), which indicates the storage location in the CPM20 of the output data. If no modification is made, the cpm buffer number dst_cpm_buff_id of csd_param from the CPRG 24 is set to (in1), which indicates the storage location in the CPM 20 of the input data.

[0318] Here, the storage locations of the input and output data within CPM20 are specified by the cpm buffer number, but if the buffer numbers available to the CPRG instance are uniquely determined by another method, these parameters can be omitted.If there are multiple buffer numbers available to the CPRG instance and it is necessary to specify which of them was used, the buffer location used must be passed using csd_param, etc., as shown in Figures 26 and 27.

[0319] Furthermore, the information on whether or not modification has occurred and the information on whether the dst cpm buffer number matches the src cpm buffer number are the same value for CSDC 28. For this reason, it is possible to eliminate the parameter on whether or not modification has occurred, or to omit the specification of the value of dst cpm_buff_id when specifying no modification.

[0320] Below, we will explain [4.2.1. SRC single unit·GC driven CPRG startup] to [4.3.5. DST address addition function·GC driven CPRG startup], which are advanced functions of [4.1. GC driven CPRG startup function (basic form)].

[0321] [4.2. SRC unit related functions] [4.2.1. SRC single unit · GC driven CPRG startup function] This function is one of the advanced functions of [4.1. GC-driven CPRG startup function (basic form)].

[0322] Here, we consider the case where, for one GC-driven CPRG invocation, one SRC unit is selected as the GC read target, and one DST unit is selected as the GC write target. We consider the case where the LUA of the SRC unit and the DST unit does not change.

[0323] In [4.1. GC-Driven CPRG Startup Function (Basic Form)], the size of the data passed to CPRG24 was undefined. In this function, the size of the data passed to CPRG24 is aligned to the unit. Therefore, the size of the input data is uniform. Furthermore, in this function, LUA is added to the input data parameters.

[0324] FIG. 28 is a diagram for explaining the configuration of csd_param and the state of the cpm buffer when data is modified by CPRG24.

[0325] FIG. 29 is a diagram for explaining the configuration of csd_param and the state of the cpm buffer when no data modification is performed by CPRG24.

[0326] The csd_param of the input data to the CPRG24 includes the cpm buffer number src_cpm_buff_id of the CPM20 and the LUA. The csd_param of the output data from the CPRG24 includes the status and the cpm buffer number dst_cpm_buff_id of the CPM20. If there are modifications, the status of the csd_param from the CPRG24 is set to modified. If there are no modifications, the status of the csd_param from the CPRG24 is set to none.

[0327] This function makes it easy to ensure exclusive processing of LUT updates. Because the data update unit matches the address translation unit by the LUT, the CSDC28 can perform processing equivalent to LUT updates in conventional GCs when updating the LUT, thereby ensuring exclusive control of host writes and GC writes.

[0328] In addition, the exclusive processing during LUT update in conventional GC is achieved by checking whether the target pointed to by the corresponding LUA in the LUT is still pointing to the PUA in gc_src immediately before the update.

[0329] Furthermore, this function allows the CPRG 24 to know the LUAs of gc_src and gc_dst that are the targets of GC. This allows the CPRG 24 to change data processing depending on the LUAs that are the targets of GC, improving processing flexibility.

[0330] Furthermore, when this function is combined with [2.3. Internal event-driven CPRG startup with host parameter setting function], user applications that span Host 4 and CPRG 24 can more flexibly specify conditions such as when processing should be performed in which LUA range between Host 4 and CPRG 24.

[0331] The effect obtained by combining this function with [2.3. Internal Event Driven CPRG Startup Function with Host Parameter Setting Function] can also be obtained by combining this function with the following [4.2.2. SRC Multiple Unit GC Driven CPRG Startup Function] to [4.3.5. DST Address Addition Function with GC Driven CPRG Startup Function].

[0332] [4.2.2. SRC Multiple Unit GC Driven CPRG Startup Function] This function is a modification of [4.2.1. SRC Single Unit · GC Driven CPRG Launch Function], which allows multiple units to be specified as the src unit when launching a single GC driven CPRG.

[0333] Here, the number of DST units is equal to the number of SRC units, and the LUA of each DST unit is unchanged from the LUA of each SRC unit.

[0334] FIG. 30 is a diagram for explaining an example of parameters of input data to the CPRG 24 and parameters of output data from the CPRG 24. In FIG.

[0335] CSDC28 can specify multiple LUAs and src cmp buffer numbers for CPRG24. CPRG24 specifies whether or not to modify each input unit and the destination for output data. Parameters can be omitted for duplicated information, just like in [4.1. GC-Driven CPRG Startup Function] and [4.2.1. SRC Single Unit GC-Driven CPRG Startup Function].

[0336] This function has the following advantages over [4.2.1. SRC Single Unit GC Driven CPRG Startup Function].

[0337] (1) CPRG24 allows modification of data across multiple units. (2) The overhead of CPRG startup can be reduced by reducing the number of CPRG startups when performing GC on the same data. The number of units to be passed at one time may be a value determined by the system, or may be configured by the host 4 for GC-driven CPRG startup.

[0338] In this embodiment, it is assumed that LUT updates are the same as those of the conventional FTL, that is, the unit of exclusion for data updates by the host 4 and the GC is handled in units of units.

[0339] [4.2.3. SRC LUA address condition specification and GC driven CPRG startup function] [4.2.3.1. SRC LUA Address Condition Specification · GC Driven CPRG Startup (Configuration Method)] This function specifies the conditions for LUA to start CPRG24 as a configuration for the GC-driven function.

[0340] Using the configuration setting function explained in [2.4. Internal Event-Driven CPRG Startup Function with Configuration Function], the host 4 sets the LUA conditions for GC-driven CPRG startup in the CSD 2. The method for specifying the LUA conditions must be agreed upon in advance between the CSD 2 and the host 4. For example, a method such as a "list of LUA ranges for which GC-driven startup is enabled" may be decided in advance.

[0341] 31 is a diagram for explaining an example of the configuration of the SRC address condition. The value of the starting LUA and the number of LUAs are set for each area of ​​the source unit.

[0342] As explained in [2.4. Internal Event-Driven CPRG Startup Function with Configuration Function], the configuration value can be set as a configuration setting command, allowing dynamic switching while GC event-driven CPRG startup is enabled. By allowing dynamic switching, it becomes easier to dynamically switch the target area, improving convenience.

[0343] In addition, by combining this with the function of [3.2. Single Event, Multi-Slot, Multi-Connection, Internal Event Driven CPRG Startup Function], it is possible to efficiently handle various types of GC-driven CPRG24 processing by switching the CPRG24 to be started depending on the LUA condition, such as slot_a when LUA condition A is met, slot_b when LUA condition B is met, etc.

[0344] [4.2.3.2. SRC LUA address condition specification and GC-driven CPRG startup (two-stage CPRG method)] This function adds functionality to [4.1. GC-driven CPRG activation function] by allowing two CPRG24s to be connected, with the first CPRG24 determining the address conditions and returning a Boolean value to CSDC28, and the second CPRG24 switching whether to activate or not depending on the return value of the first CPRG24.

[0345] The first CPRG 24 is called the first-stage CPRG 24, and the second CPRG 24 is called the second-stage CPRG 24. The slots that store each CPRG 24 are called the first-stage slot and the second-stage slot.

[0346] The host commands for this function are obtained by slightly extending the host commands used in the GC-driven function.

[0347] FIG. 32 is a diagram illustrating an example of a host command used in this function.

[0348] The host command H_CONNECT_GC_DRIVEN_CPRG() is extended to instruct that CPRG1 in the first stage slot and CPRG2 in the second stage slot are connected to the GC so that they are started during GC.

[0349] Other host commands H_UNCONNECT_GC_DRIVEN_CPRG(), H_ENABLE_GC_DRIVEN_CPRG(), H_DISABLE_GC_DRIVE_CPRG(), H_SET_MAX_GC_DRIVEN_CPRT(), H_SET_GC_DRIVEN_CPRG_HOST_PARAM(), and H_SET_GC_DRIVEN_CPRG_CONFIG() have no extensions.

[0350] In this function, the CSDC28 performs the following processing instead of the "CPRG startup" described in [4.1.GC-driven CPRG startup function (basic form)].

[0351] FIG. 33 is a flow diagram for explaining an example of the CPRG activation function in [4.2.3.2. SRC LUA address condition specified GC driven CPRG activation (two-stage CPRG method)].

[0352] The CSDC 28 creates an LUA list of units to be GC-targeted (S102). The CSE 18 starts the first CPRG by specifying the LUA list as an argument (S104).

[0353] The CSE 18 determines whether the return value of the first CPRG is true (the first CPRG was executed normally) (S106).

[0354] If the return value of the first CPRG is true, the CSE 18 starts the second CPRG by specifying the LUA list as an argument (S108).

[0355] The CSE 18 stores the DST unit data or the SRC unit data in the gc_dst zone according to the result of the second CPRG (S110).

[0356] If the return value of the first CPRG is not true, the CSE 18 stores the SRC unit data in the gc_dst zone (S112).

[0357] After S110 or S112, the CPRG startup ends.

[0358] In this flow diagram, the following two processes are omitted.

[0359] (Process 1) Reading unit data from gc_src to SCM 22.

[0360] (Process 2) The SRC unit data to be passed to the second CPRG 24 is stored in the CPM 20.

[0361] These two processes may be performed at any time as long as the following conditions are met:

[0362] (Process 1) is before S112 (Process 2) is before S108 The actual processing timing may vary depending on the CSD implementation, such as the following conditions:

[0363] (Condition 1) When storing unit data read from gc_src in CPM 20, the difference is whether it can be transferred directly to CPM 20 or whether it is transferred to SCM first and then transferred to CPM 20.

[0364] (Condition 2) The difference is whether or not it is necessary to read unit data to determine whether each unit of gc_src is valid.

[0365] (Condition 3) The difference is whether or not to use CPM 20 as the destination for expanding unit data, regardless of whether or not the second stage CPRG 24 is called. If CPM 20 is used, (Condition 1) and (Condition 2) can be achieved in the same step.

[0366] This function has the advantage that it allows for more flexible determination of LUA conditions compared to [4.2.3.1. SRC LUA address condition specification · GC driven CPRG startup (configuration method)].

[0367] However, since two stages of CPRG startup are involved, it can be said that the overhead is larger than in [4.2.3.1. SRC LUA address condition specified · GC driven CPRG startup (configuration method)].

[0368] [4.2.4. SRC PUA address reverse order specification · GC driven CPRG startup] This function adds a feature to [4.1.1. GC-Driven CPRG Startup Function] that enables the order in which valid data holding units are read from gc_src to be in descending order of PUA within the zone, rather than in ascending order of PUA. This function is one of the configuration functions for the GC-Driven CPRG function.

[0369] The number of SRC units when starting a single GC-driven CPRG can be one or more, but it is more likely to be effective when there are multiple units.

[0370] GC processes the units with valid data in a zone in order. In the example where there is only one SRC unit when a GC-driven CPRG is started, if there are N units with valid data in a zone, CPRG24 is started N times for that zone. This function determines whether the units passed to CPRG24 each time it is started are the first unit in the zone or the last unit.

[0371] Below, we explain GC-driven CPRG startup when the number of SRC units is three.

[0372] FIG. 34 is a diagram for explaining GC-driven CPRG activation with SRC PUA address reverse order specification.

[0373] Zone=10 is selected for gc_src.

[0374] CSDC28 reads out the data "P", "O", and "M" from the valid data holding units of gc_src, starting from the end of PUA, for the number of valid data holding units required to be handed over to CPRG24, and stores them in CPM20 (#g1).

[0375] CSDC28 starts CPRG24, which is linked to the GC-driven function (#g2).

[0376] The CPRG 24 receives the data on the CPM 20 read from gc_src, performs arithmetic processing, and outputs the processing results "P'", "O'", and "M'" to the CPM 20 (#g3).

[0377] It is acceptable if the processing result of CPRG24 is no change. In this case, it is acceptable to return the information "no change" instead of outputting the same data as the input data.

[0378] The CSDC 28 stores the output results "P'", "O'", and "M'" of the CPRG 24 in the gc_dst zone (#g4).

[0379] If the processing result of CPRG24 is unchanged, the same data as that read from gc_src is stored in the gc_dst zone.

[0380] This function has the advantage of improving the flexibility of CPRG24 data processing compared to GC-driven CPRG startup, in which the processing order of PUA during GC is fixed to ascending order.

[0381] In other words, when processing data that spans multiple units, having the option of sorting in either ascending or descending order widens the variety of data processing that can be performed. This is particularly effective in cases where the data spans multiple units and the metadata indicating the data content is placed after the PUA.

[0382] It is relatively common for management data such as metadata to be located behind the PUA. In cases where the data includes content and metadata that describes the content, if the host 4 writes the content to the CSD2 in a sequence that writes the content first and the metadata last, the PUA for the metadata will be located at the back. Even if the metadata is located at the front in the LUA space, the PUA will be assigned according to the write order.

[0383] For example, this applies to an application in which the host 4 writes a series of log data and then writes metadata indicating the contents of the log data at the end.

[0384] A specific example of this function will be described later in "5.5.2.2 (Embodiment CASE_C) Log Compaction."

[0385] There are various methods for specifying the configuration, but two examples are shown below.

[0386] Example 1: Order specification method for gc_src PUA "Normal" or "reverse" can be specified in the configuration. "Normal" and "reverse" are defined as specifying whether the gc_src PUA should be sorted in ascending or descending order. When a dynamic configuration switch request is made by the host 4, the CSDC 28 switches the order as quickly as possible, even if the request is made while writing gc_src or gc_dst.

[0387] Example 2: Host write ordering method "Normal" or "reverse" can be specified in the configuration. "Normal" and "reverse" are defined as specifying whether the PUA should be written in ascending or descending order when the host writes. One gc_dst is assumed to be written in either "normal" or "reverse" order, and the zone attribute of whether the write was performed in "normal" or "reverse" is managed for each zone. When a dynamic configuration switch request is made from host 4, the order of the gc_dst that was being written up until that point will not be changed, and the scan order of gc_src will be switched when the next write to gc_dst begins.

[0388] Comparing the first and second examples, the first example has the advantage of requiring fewer implementation resources because it does not need to manage attributes for each zone. On the other hand, the second example has the advantage that the application can intentionally select whether "host 4 wants to know the data written later first, or the data written earlier first," allowing host 4 to explicitly specify the order processing as intended.

[0389] [4.3. DST unit related functions] [4.3.1. DST Allocation Function and GC Driven CPRG Startup] This function adds the following two changes to [4.1.GC-driven CPRG startup function] to enable CPRG24 to specify deallocation of the unit to be processed to CSDC28.

[0390] (Change 1) Add a parameter indicating whether to deallocate or not to the information returned from CPRG24 to CSDC28.

[0391] (Change 2) CSDC28 performs the following processing for units that have been specified for deallocation by CPRG24.

[0392] (Process 1) Omit writing to gc_dst (Process 2) In the LUT update process, a check is made to see if the PUA of the target unit is still valid (whether the PUA indicated by the target LUA in the LUT is still the unit in gc_src), and if it is still valid, the PUA of the LUA in question is changed to deallocate. If it is invalid (pointing to another PUA) at the time of the validity check, the LUT is not updated.

[0393] This function can be combined with any of the functions in [4.1.GC-driven CPRG startup function].

[0394] Figure 35 shows an example of parameters when this function is combined with [4.2.1. SRC single unit GC driven CPRG startup function].

[0395] Figure 36 shows an example of parameters when this function is combined with [4.2.2. SRC Multiple Unit GC Driven CPRG Startup Function].

[0396] In both cases, the parameter status from CPRG24 is set to deallocate. When status is set to deallocate, the value of dst cpm_buff_id becomes invalid.

[0397] This function makes it possible to further compact the amount of usage on the storage media 10 at the timing of GC.

[0398] [4.3.2.DST address order change function and GC driven CPRG startup] This function adds the following two changes to [4.1. GC-driven CPPG startup function] to provide the ability to change the write order to gc_dst of the unit being processed when returning from CPRG24 to CSDC28.

[0399] (Change 1) A parameter for setting LUA is added to the entry order of information returned from CPRG 24 to CSDC 28. CPRG 24 may switch the output LUA order with respect to the input LUA order.

[0400] The information returned from CPRG24 to CSDC28 has a table structure as shown in OUTPUT in Fig. 30. Assuming that writing to the gc_dst unit will be performed in the order of entries in this table, and if parameters for setting LUA are added to the table entries, the information returned from CPRG24 to CSDC28 will look like the OUTPUT table in Fig. 38, which will be described later.

[0401] (Change 2) The CSDC 28 writes to gc_dst and updates the LUT in the order of entries output from the CPRG 24.

[0402] This function can be combined with any of the functions in [4.1. GC-driven CPRG startup function]. As an example, we will explain two examples of combining this function with [4.2.2. SRC multiple unit GC-driven CPRG startup function].

[0403] (Example 1) When there is no change in address order This example shows the case where the GC driven function with DST address order change function is used, but CPRG24 uses the GC driven function without changing the address order.

[0404] FIG. 37 is a diagram for explaining the state of the LUT and gc_src at the start of GC-driven CPRG activation.

[0405] Figure 38 is a diagram illustrating an example of the input and output of CPRG24 when it is started with three units, LUA="a", "b", and "c", as input. Here, the order of the input LUAs, "a", "b", and "c", is maintained in the order of the output LUAs.

[0406] Upon receiving this output, the CSDC 28 writes the unit data to gc_dst in the order of LUA=a, b, c. Fig. 39 is a diagram for explaining the state of the LUT and gc_dst after storing the unit data in gc_dst (zone=20) and updating the LUT in this order.

[0407] PUA=20_11, the target of LUA=a, stores "A", PUA=20_12, the target of LUA=b, stores "B'", and PUA=20_13, the target of LUA=c, stores "C'".

[0408] (2) When there is a change in address order This shows an example of when CPRG24 changes the address order using the GC driven function with DST address order change function.

[0409] Assume that the state of the LUT and gc_src at the start of the CPRG startup process using the GC-driven function is the same as that shown in FIG.

[0410] Figure 40 is a diagram illustrating an example of the input and output of CPRG24 when it is started with three units, LUA="a", "b", and "c", as input, as in Usage Example 1.

[0411] In this example, the input LUA sequence "a", "b", "c" is replaced by the output LUA sequence "a", "c", "b".

[0412] Upon receiving this output, the CSDC 28 writes units to gc_dst in the order of LUA=a, c, b. Figure 41 shows the status of the LUT and gc_dst after saving unit data to gc_dst (zone=0x20) and updating the LUT in this order.

[0413] The pointer of LUA=c is PUA=20_12, where "C'" is stored. The pointer of LUA=b is PUA=20_13, where "B'" is stored.

[0414] From Use Case 1, we can see that even if the DST address order change function is available, it is possible not to change the order, as in Use Case 1.

[0415] Furthermore, by comparing the results of usage examples 1 and 2, it can be seen that depending on how this function is used, CPRG24 can change the placement order of PUAs while leaving the content for each LUA unchanged.

[0416] This function allows applications to take measures such as placing meaningful sequences of data consecutively on the PUA.

[0417] This will improve the read speed of data stored on a series of PUAs. Also, considering that data with similar attributes tends to have a uniform write workload, this will have the effect of improving the efficiency of GC in the future.

[0418] [4.3.3. DST unit attribute specification function and GC-driven CPRG startup function] This function is a modification of [4.1.GC-driven CPRG startup function] in the following two points, which allows the attribute information of the data of the unit to be processed to be set when returning from CPRG24 to CSDC28.

[0419] (Change 1) A parameter that allows setting of data attribute information is provided in the entry for each unit of information returned from CPRG24 to CSDC28.

[0420] (Modification 2) The CSDC 28 writes the data of the corresponding unit to the gc_dst of the zone corresponding to the data attribute, according to the attribute information of the data for each unit output from the CPRG 24. The data attribute can be defined as, for example, a write attribute or a read attribute.

[0421] The technology that allows FTL to use different zones depending on the data attributes was explained above in "Use of Different Zones Depending on Data Attributes." In this function, the attribute information used for this technology is determined by the GC-driven CPRG24, and the determination result is fed back to the CSDC28.

[0422] FIG. 42 is a diagram for explaining an example of parameters when this function is applied to [4.3.2. DST Address Order Change Function and GC Driven CPRG Start Function].

[0423] Here, the data attributes (attribute) can be specified for each unit as either a write attribute w_hot / w_normal / w_cold or a read attribute r_hot / r_normal / r_cold. The write attribute indicates how frequently the target LUA data is overwritten or written, and the write attribute indicates how frequently the target data is read. Note that the classification of data attributes is not limited to this, and other classifications may also be used.

[0424] [4.3.4. DST unit carryover function and GC-driven CPRG startup] [4.3.4.1. Overview] This function adds the following three functions to [4.1.GC-driven CPRG startup function].

[0425] (Function 1) The CPRG24 sets the carryover of processing of the unit specified in the input to the CSDC28. (Function 2) When CPRG24 completes the processing of a unit that has been carried over, it sets up a payout to CSDC28. (Function 3) A function in which CSDC 28 requests CPRG 24 to issue units whose processing is being carried over.

[0426] Carrying over processing means that the processing result cannot be obtained during the current CPRG call, but will be determined in the next or subsequent CPRG call.

[0427] The following explains "Carryover / Payout" and "Payout Request" in that order.

[0428] [4.3.4.2. Carryover and Withdrawal] FIG. 43 is a diagram for explaining examples of what types of CPRGs require processing to be carried over.

[0429] Consider a situation where there is a series of data a, b, c, d, e, f in LUA, and metadata about b to f is stored in the first address a. For simplicity's sake, let's assume that the data is also arranged on the PUA in the same order as in LUA. By writing a to f sequentially when writing to the host, it is expected that the data will also be sequential on the PUA.

[0430] Assume that after first modifying the data stored in b to f using CPRG, you want to store the metadata generated using the results in a.

[0431] This is possible if all LUA=a~f units are entered in the first CPRG that is started.

[0432] However, if only three units are entered in the first CPRG, LUA=a, b, c will be entered in the first CPRG, and d, e, f will be entered in the second CPRG.

[0433] In such a case, the first CPRG processes LUA=b and c while carrying over the unit processing of LUA=a, and the second CPRG processes LUA=d, e, and f while completing the unit processing of LUA=a and issuing it. This is how units are carried over and issued.

[0434] FIG. 44 is a diagram for explaining the first CPRG and carryover settings.

[0435] FIG. 45 is a diagram for explaining the second CPRG and payout settings.

[0436] 46 is a diagram illustrating the input / output of csd_param for the first CPRG and the usage of the cpm buffer. When the first CPRG is started, the CPRG 24 sets carry_over to the status of the entry for LUA=a in the output csd_param.

[0437] 47 is a diagram illustrating the input and output of csd_param for the second CPRG and the usage of the cpm buffer. During the second CPRG startup, CPRG 24 adds an entry for LUA=a to the output csd_param, sets the status to payoff and the processing result, i.e., status=modified, and enters the output destination number out4 into the cpm buffer number of the DST.

[0438] The cpm buffer number in1 that stores the input data of LUA=a for which carryover has been set remains allocated. This is because the input data of LUA=a that has not yet been processed by either CPRG24 or CSDC28 cannot be released even after the first invocation of CPRG24.

[0439] The input buffer is released after the CPRG 24 has completed the allocation and the CSDC 28 has completed the corresponding processing.

[0440] Although not explicitly stated here, the CSDC 28 is currently processing the data for LUA=a and internally manages information on the number of PUAs in gc_src. This information will also continue to be held within the CSDC 28 until the processing associated with the issuance of LUA=a is completed.

[0441] Carrying over unit processing involves a delay in releasing these resources, and therefore, in effect, involves restrictions such as an upper limit on the number of processes that can be carried over at the same time.

[0442] [4.3.4.3. Withdrawal Request] In the example of [4.3.4.1. Carryover and Payout], the payout of the LUA=a unit that was set as carryover in the first CPRG was performed in the second CPRG. Depending on the size of the series of data, the data confirmation of the unit carried over in the first CPRG may not be completed when the second CPRG is started, and the carryover may continue into the third and fourth CPRGs.

[0443] On the other hand, it is convenient for CSDC to return the gc_src zone to free as soon as it has finished processing all valid data holding units in the gc_src zone.

[0444] Therefore, when CSDC28 specifies that "this CPRG cannot be carried over. Please pay out the units being carried over," this constitutes a payout request.

[0445] When the CPRG is started up after receiving a payout request, it must confirm the carried-over units and pay them out.

[0446] In other words, when using the carryover function, CPRG must use it under the premise set by CSD2, which is that "the data for the carried-over units must be confirmed at the time the payout request is received."

[0447] [4.3.5. DST address addition function and GC-driven CPRG startup function] This function adds the ability to specify that CPRG24 writes unit data to LUA that is not specified as input to CSDC28 by making the following two changes to [4.1. GC-Driven CPRG Startup Function].

[0448] (Change 1) A function that allows you to set a new entry for writing to LUA in the information returned from CPRG24 to CSDC28. (Change 2) The CSDC 28 performs the following processing for the unit specified by the CPRG 24 to be written to the new LUA.

[0449] (Process 1) Write to gc_dst (Process 2) In the LUT update process, the check to see if the PUA of the target unit remains valid (checking whether the PUA indicated by the target LUA in the LUT remains the corresponding unit in gc_src) is "omitted" and the PUA of the corresponding LUA is updated.

[0450] This function is implemented in a significantly different manner, although the parameter configuration is similar to [4.3.1. DST allocation function with GC-driven CPRG activation], [4.3.2. DST address order change function with GC-driven CPRG activation], [4.3.3. DST unit attribute specification function with GC-driven CPRG activation], and [4.3.4. DST unit carryover function with GC-driven CPRG activation], which all involve specifying the attributes of the DST unit.

[0451] This is because this function does not have a way to check the exclusion between host writes and CPRG24 writes during LUT update processing. In other words, with this function, exclusion between host 4 writes and CPRG24 writes must be done at the application level across host 4 and CPRG24.

[0452] FIG. 48 is a diagram illustrating an example of the csd_param and cpm buffer related to this function.

[0453] This function increases the flexibility of CPRG24. For example, it can handle input data modifications that increase the data size.

[0454] By combining this function with [4.3.1. DST Allocation Function · GC Driven CPRG Start], it becomes possible to respond to the movement of units' LUA.

[0455] [4. GC-Driven CPRG Activation Function] reduces the overlap between data reads and writes by applications and data reads and writes by GC. Reducing the overlap improves the WAF and extends the life of CSD2. Reducing the overlap improves performance due to IO processing. It enables data processing across multiple units on a single GC-linked CPRG. It enables the GC-linked CPRG to be activated by specifying an SRC address. By allowing GC execution within a zone to be performed in descending order of PUA rather than ascending order, data processing can be performed in descending order of PUA in GC-linked CPRGs. The data deallocation function improves the WAF and extends the life of CSD2. Specifying the data allocation order after GC allows processing such as consolidating similar data into consecutive addresses, improving performance. The data attribute specification function improves the WAF by using different zones, thereby improving performance. When the data conversion process cannot be completed using only the input data for one GC-linked CPRG, it is possible to perform data conversion using input data for multiple GC-linked CPRGs. GC-linked CPRGs allow data conversion processes in which the output data is larger than the input data.

[0456] [Application example] [Basic example] This section explains application examples of the GC-driven CPRG startup function of [4.2.1. SRC single unit · GC-driven CPRG startup function] to [4.3.5. DST address addition function · GC-driven CPRG startup function], showing what kind of data configuration and what kind of CPRG can be used to their advantage.

[0457] As in the above-mentioned (Example 1) to (Example 7), when large amounts of data are read and large amounts of data are written back in duplicate, the GC-driven CPRG startup function is advantageous.

[0458] (Example 1) Data conversion (single unit, same LUA) Consider a use case where meaningful data is stored in a format that is complete in one LUA unit, and there is a large amount of data in the same format.

[0459] The B-tree structure used in many data systems is a prime example of such a use case.

[0460] FIG. 49 shows a unit structure that is schematically represented by imagining a leaf page of a B-tree.

[0461] For example, suppose this unit structure is used as a membership list for a certain association, with "member number" entered in the index and "name, address" entered in the value. The association has a huge number of members, and there are a large number of units with this structure.

[0462] One day, several addresses were changed due to land readjustment. You want to update the addresses in the register, but there is no need to rush, as the old addresses will still be valid for a while.

[0463] This data conversion will be performed by the GC-driven CPRG startup function.

[0464] Although the size of each value may become larger or smaller due to conversion, there is sufficient margin in the unit, so conversion rarely exceeds the unit size, and even if it does, it is extremely rare.

[0465] In this case, the following functions come into play: [4.2.1. SRC single unit / GC driven CPRG startup function] It will be even more effective if you use the following functions in conjunction with it. [1.1. Asynchronous notification setting function from CPRG24 to host 4] [2.3. Host parameter setting function and internal event-driven CPRG startup function] For GC-driven CPRGs, the host 4 specifies the LUA range of the units to be processed using host_param, which is set using [2.3. Internal Event-Driven CPRG Startup Function with Host Parameter Setting Function].

[0466] CPRG24 processes each unit and records the progress of the processing (creates a list of LUAs that have completed processing).

[0467] Once a certain amount of progress information has been accumulated, CPRG24 uses the function [1.1. Asynchronous notification setting function from CPRG24 to host 4] to report the progress to host 4 via asynchronous notification. At this time, if there is a record that CPRG24 did not perform conversion because the conversion would have exceeded the unit size, it will also notify host 4 to that effect.

[0468] Host 4 checks the progress and performs the conversion itself only on data that has been deferred to conversion by CPRG 24. To do this, complex processing across multiple units is required, such as splitting leaves in the case of a B-tree and updating the contents of upper nodes.

[0469] As the GC progresses, all units to be processed will eventually be converted.

[0470] The host 4 can stop the GC driven function when it has confirmed that conversion of all units to be processed has been completed.

[0471] If the unit to be processed is not selected by gc_src for some reason, such as being stored in a zone with a lot of cold data, and the conversion of all data cannot be completed within the period desired by the host 4, the host 4 may stop the GC-driven function without waiting for CPRG24 to complete processing of all units, and convert only the unprocessed data on the host 4.

[0472] [Examples of data content and address focus] (Example 2) Data conversion (multiple units, same LUA) This example is a use case where the data to be processed spans multiple units.

[0473] FIG. 50 is a diagram for explaining a case where one meaningful block of data spans multiple units.

[0474] In the example in Figure 50, the length value in the first unit is determined only after the data in the payload spanning multiple units has been finalized. In the example in Figure 50, which is a name list, if the payload contains information such as member number, name, address, phone number, etc., and at some point there is a reorganization, you may want to replace the address with a new one.

[0475] In such cases, the following functions are effective. [4.2.2. SRC Multiple Unit GC Driven CPRG Startup Function] In addition, depending on the division of data and processing, the following functions are also effective. [4.3.4. DST unit carryover function and GC-driven CPRG startup] (Example 3) Compaction This example shows a case where a large amount of unnecessary data exists in the data to be processed. An example of unnecessary data is duplicated log data. Figure 51 is a diagram for explaining the log-structured data structure adopted in many data systems.

[0476] Here, transaction logs consisting of key and value pairs (**** in the diagram) are written sequentially in chronological order to a log area spanning multiple units. Of the transactions with the same key, only the most recent one is valid.

[0477] The metadata contains a pointer that indicates the location of valid data for each key in a block of log called the log section. Because the metadata is written to the CSD after the log section is written, it is placed after the log section in the PUA space.

[0478] Compaction of a log section by an application involves removing duplicate key data from such a log, generating a new log that collects only the latest data for each key, and discarding the original log section.

[0479] However, even without waiting for compaction of this application, it is clear from the metadata that unit_1 and unit_M in Figure 51 contain only unnecessary data and will therefore never be referenced.

[0480] In this case, it is more efficient to omit the zone movement of unit_1 and unit_M in GC and handle them as deallocate in the LUT.

[0481] In this case, the combination of the following functions is effective. [4.2.4. SRC PUA address reverse order specification · GC driven CPRG startup] [4.3.1. DST Allocation Function and GC Driven CPRG Startup] (Example 4) Changing the PUA address order In this example, we consider a case where multiple types of data with different meanings are randomly mixed together on a PUA.

[0482] If one application on the host 4 writes data while another application writes data, the write requests from these two applications will be issued to the CSD in a jumble.

[0483] As a result, even if each application performs sequential writes, the two data will end up being stored intermixed on the PUA.

[0484] FIG. 52 is a diagram for explaining the change in the PUA address order in Example 4. In FIG.

[0485] In such cases, storage performance can be expected to improve by rearranging similar types or similar LUAs (or those with the same namespace) so that they are placed contiguously on the PUA.

[0486] In this case, the combination of the following functions is effective. [4.2.2. SRC Multiple Unit GC Driven CPRG Startup Function] [4.3.2.DST Address Order Change Function and GC Driven CPRG Startup Function] (Example 5) Sorting data attributes In this example, data that has hot / cold attributes is the target.

[0487] Consider the data of a tweet system of a social network service, which consists of a key and value pair. The key stores the user ID, and the value stores the tweet of the corresponding user.

[0488] By assigning the attribute "read hot" to tweets from popular users and sorting them into a zone with a fast read response, it is possible to improve system performance while suppressing increases in costs.

[0489] In this case, the following functions are effective: [4.3.3. DST unit attribute specification function and GC-driven CPRG startup function] (Example 6) Data movement If you want to move data in LUA, the following functions are effective. [4.3.1. DST Allocation Function and GC Driven CPRG Startup] [4.3.5. DST address addition function and GC-driven CPRG startup function] (Example 7-1) Data conversion (data format change / size reduction) Consider a data structure in which, as a result of format conversion of data spanning multiple units, the number of units of data after conversion is less than that before conversion.

[0490] In this case, the following functions are effective: [4.3.1. DST Allocation Function and GC Driven CPRG Startup] (Example 7-2) Data conversion (changing data format and enlarging size) Consider a data structure in which, as a result of format conversion of data spanning multiple units, the number of units of data after conversion is greater than before conversion.

[0491] In this case, the following functions are effective: [4.3.5. DST address addition function and GC-driven CPRG startup function]

[0492] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims. [Explanation of symbols]

[0493] 2...CSD, 4...Host, 6...CPU, 8...HM, 10...Storage Media, 12...FE, 14...B, 16...Slot, 18...CSE, 20...CPM, 22...SCM, 24...CPRG, 28...CSDC, 52...EDCC

Claims

1. a first memory for storing a plurality of programs; a second memory accessible when any of the plurality of programs is executed; a storage medium for storing data sent from the host; a processor that executes any one of the plurality of programs to process data stored in the second memory; a controller that receives a request from the host and writes data to and reads data from the storage media, that receives a request from the host and manages the storage media, and that controls the execution of asynchronous events that are processes independent of requests from the host; Equipped with Upon occurrence of the asynchronous event, The controller reads data from the storage medium; the processor executes a program associated with the asynchronous event among the plurality of programs, and performs data processing on the data read from the storage medium using the second memory; the controller writes the processed data to the storage medium; The program associated with the asynchronous event includes at least one program specified by the host.

2. A computational storage drive as described in claim 1, wherein the controller causes the processor to execute a program associated with an asynchronous event when the asynchronous event occurs.

3. A computational storage drive as described in claim 1, wherein the controller causes the processor to execute multiple programs related to an asynchronous event when the asynchronous event occurs.

4. A computational storage drive as described in claim 1, wherein the controller causes the processor to execute one program associated with each of the plurality of asynchronous events upon the occurrence of each of the plurality of asynchronous events.

5. A computational storage drive as described in claim 1, wherein the controller causes the processor to execute multiple programs associated with each of the multiple asynchronous events upon the occurrence of each of the multiple asynchronous events.

6. A first memory for storing a plurality of programs; a second memory accessible when any of the plurality of programs is executed; a storage medium for storing data sent from the host; a processor that executes any one of the plurality of programs to process data stored in the second memory; a controller that receives a request from the host and writes data to and reads data from the storage media, that receives a request from the host and manages the storage media, and that controls the execution of asynchronous events that are processes independent of requests from the host; Equipped with Upon occurrence of the asynchronous event, The controller reads data from the storage medium; the processor executes a program associated with the asynchronous event among the plurality of programs, and performs data processing on the data read from the storage medium using the second memory; the controller writes the processed data to the storage medium; Upon occurrence of the asynchronous event, The controller When the host has enabled the initiation of a program related to the asynchronous event, the processor is caused to execute the program related to the asynchronous event; A computational storage drive that, when the host has set the execution of a program associated with an asynchronous event to be disabled, does not cause the processor to execute the program associated with the asynchronous event.

7. A first memory for storing a plurality of programs; a second memory accessible when any of the plurality of programs is executed; a storage medium for storing data sent from the host; a processor that executes any one of the plurality of programs to process data stored in the second memory; a controller that receives a request from the host and writes data to and reads data from the storage media, that receives a request from the host and manages the storage media, and that controls the execution of asynchronous events that are processes independent of requests from the host; Equipped with Upon occurrence of the asynchronous event, The controller reads data from the storage medium; the processor executes a program associated with the asynchronous event among the plurality of programs, and performs data processing on the data read from the storage medium using the second memory; the controller writes the processed data to the storage medium; The controller causes the processor to simultaneously execute multiple programs set by the host among the multiple programs when the asynchronous event occurs.

8. A first memory for storing a plurality of programs; a second memory accessible when any of the plurality of programs is executed; a storage medium for storing data sent from the host; a processor that executes any one of the plurality of programs to process data stored in the second memory; a controller that receives a request from the host and writes data to and reads data from the storage media, that receives a request from the host and manages the storage media, and that controls the execution of asynchronous events that are processes independent of requests from the host; Equipped with Upon occurrence of the asynchronous event, The controller reads data from the storage medium; the processor executes a program associated with the asynchronous event among the plurality of programs, and performs data processing on the data read from the storage medium using the second memory; the controller writes the processed data to the storage medium; The computational storage drive, wherein the controller, upon occurrence of the asynchronous event, causes the processor to execute at least one program from among the plurality of programs, specified by the host, according to startup parameters set by the host.

9. A first memory for storing a plurality of programs; a second memory accessible when any of the plurality of programs is executed; a storage medium for storing data sent from the host; a processor that executes any one of the plurality of programs to process data stored in the second memory; a controller that receives a request from the host and writes data to and reads data from the storage media, that receives a request from the host and manages the storage media, and that controls the execution of asynchronous events that are processes independent of requests from the host; Equipped with Upon occurrence of the asynchronous event, The controller reads data from the storage medium; the processor executes a program associated with the asynchronous event among the plurality of programs, and performs data processing on the data read from the storage medium using the second memory; the controller writes the processed data to the storage medium; When the asynchronous event occurs, if the host has set to enable the launch of a program associated with the asynchronous event, the controller causes the processor to execute at least one program associated with the asynchronous event, which is specified by the host among the plurality of programs, in accordance with launch parameters set by the host; The computational storage drive, wherein the startup parameters are dynamically changed by the host while the host is enabling startup of the program associated with the asynchronous event.

10. A computational storage drive as described in claim 9, wherein when the controller receives a request from the host to change the boot parameters, it suspends changing the boot parameters until the running program is terminated.

11. A first memory for storing a plurality of programs; a second memory accessible when any of the plurality of programs is executed; a storage medium for storing data sent from the host; a processor that executes any one of the plurality of programs to process data stored in the second memory; a controller that receives a request from the host and writes data to and reads data from the storage media, that receives a request from the host and manages the storage media, and that controls the execution of asynchronous events that are processes independent of requests from the host; Equipped with Upon occurrence of the asynchronous event, The controller reads data from the storage medium; the processor executes a program associated with the asynchronous event among the plurality of programs, and performs data processing on the data read from the storage medium using the second memory; the controller writes the processed data to the storage medium; Upon occurrence of the asynchronous event, The controller causing the processor to execute a program associated with the asynchronous event when a condition set by the host is satisfied; A computational storage drive that does not cause the processor to execute a program associated with the asynchronous event if a condition set by the host is not met.

12. A first memory for storing a plurality of programs; a second memory accessible when any of the plurality of programs is executed; a storage medium for storing data sent from the host; a processor that executes any one of the plurality of programs to process data stored in the second memory; a controller that receives a request from the host and writes data to and reads data from the storage media, that receives a request from the host and manages the storage media, and that controls the execution of asynchronous events that are processes independent of requests from the host; Equipped with Upon occurrence of the asynchronous event, The controller reads data from the storage medium; the processor executes a program associated with the asynchronous event among the plurality of programs, and performs data processing on the data read from the storage medium using the second memory; the controller writes the processed data to the storage medium; When the host has set activation of a program associated with the asynchronous event, the controller causes the processor to execute at least one program associated with the asynchronous event, which is designated by the host among the plurality of programs, if a condition set by the host is satisfied when the asynchronous event occurs; The computational storage drive, wherein the condition is dynamically changed by the host while event-linked program launch is enabled by the host.

13. A computational storage drive as described in claim 12, wherein when the controller receives a request from the host to change the condition, it suspends the change to the condition until the running program is terminated.

Images