Flash control layer independent testing method, testing device and computer program product

Abstract

This application discloses a flash memory control layer independent testing method, testing equipment, and computer program product. The method includes: parsing a received flash memory control layer independent test command; generating a corresponding random operation sequence in response to the parsing result indicating the execution of a random operation; obtaining a target superblock matching the operation type in the random operation sequence from a preset superblock state list; executing the corresponding operation; outputting a test result; and migrating the target superblock whose state has changed after the operation to the superblock state list corresponding to its state after the operation. Executing the corresponding operation includes: writing data to a target superblock stored in a preset active write unit in response to a write operation, wherein the active write unit stores the target superblock currently being written to. This application enables the independent completion of long-term random interleaving hybrid stress testing without the participation of a flash memory conversion layer.

Description

Technical Field

[0001] This application relates to the field of storage device testing, and more particularly to an independent testing method, testing equipment, and computer program product for flash memory control layer. Background Technology

[0002] Typical solid-state drive (SSD) firmware consists of a three-layer architecture: Front End Layer (FEL), Flash Translation Layer (FTL), and Flash Control Layer (FCL).

[0003] Without the involvement of FTL, traditional FCL tests can only perform single-function verification (such as single-function erase test, single-function write test, single-function read test) or fixed-order erase-write-read test (erase → write → read, and use different blocks each time) due to the lack of the state management mechanism provided by FTL, and cannot perform random interleaved mixed stress tests. Summary of the Invention

[0004] This application provides a flash memory control layer independent testing method, testing equipment, and computer program product to achieve independent random interleaving hybrid stress testing without the involvement of the FTL.

[0005] In a first aspect, embodiments of this application provide a method for independent testing of the flash memory control layer, the method comprising: Parse the received independent test commands for the flash memory control layer; In response to the parsing result, a random operation is performed, generating a corresponding sequence of random operations; Obtain the target superblock that matches the operation type in the random operation sequence from the preset superblock state list, execute the corresponding operation, output the test result, and migrate the target superblock whose state changes after the operation to the superblock state list corresponding to its state after the operation. The operation types include erase operation, write operation and read operation, and the preset superblock state list includes the corresponding eraseable state list, writable state list and readable state list. The corresponding operations performed include at least the following: In response to performing a write operation, data is written to a target superblock stored in a preset active write unit, wherein the active write unit is used to store the target superblock currently being written.

[0006] In at least one possible implementation, the response to perform a write operation further includes: If the target superblock in the active write unit is full, then the target superblock is moved to the readable state list; and / or If the active write unit is empty, a target superblock is obtained from the writable state list and placed into the active write unit; and / or The corresponding operation also includes: In response to the execution of a read operation, data is read from the target superblock in the readable state list or from the target superblock in the active write unit where data has already been written.

[0007] In at least one possible implementation, the active write unit includes a single-level storage mode write unit and a multi-level storage mode write unit.

[0008] In at least one possible implementation, the active write unit is configured as a pointer to the superblock being written.

[0009] In at least one possible implementation, the step of migrating the target superblock whose state has changed after the operation to the superblock state list corresponding to its state after the operation specifically includes: When the erase operation is successful, the target superblock is moved from the eraseable state list to the writable state list; When a write operation is successful and the target superblock is full, it is moved to the readable state list; When the read operation is successful, the state of the target superblock is not changed.

[0010] In at least one possible implementation, the preset superblock state list further includes a bad block state list, and the step of migrating the target superblock whose state has changed after the operation to the superblock state list corresponding to its state after the operation specifically includes: When the erase, write, or read operation fails, the target superblock is migrated to the bad block status list.

[0011] In at least one possible implementation, the output test results specifically include: After the preset test stop condition is met, check whether the bad block status list is empty; if it is empty, the test is considered to have passed; otherwise, the test is considered to have failed, and the superblock information in the bad block status list is output.

[0012] In at least one possible implementation, generating the corresponding random operation sequence includes: Randomly select one or more write and read operations from a pre-built operation library to generate a random operation sequence that mixes one or more write and read operations, and trigger an erase operation through a write operation; and / or When neither the erasable state list nor the writable state list has a usable superblock, a superblock is selected from the readable state list and migrated to the erasable state list.

[0013] In at least one possible implementation, the method further includes: Repeat the random operation sequence until a preset test stop condition is met; the test stop condition includes: the number of tests on the target superblock in single-level storage unit mode reaches a first threshold, and / or, the number of tests on the target superblock in multi-level storage unit mode reaches a second threshold.

[0014] In at least one possible implementation, the method further includes: In response to the parsing result being a sequential operation, the superblock is retrieved from the test block circular queue; The system iterates through various working modes formed by combinations of plane type and storage unit type, performs erase, write and read operations on the superblock in sequence, outputs the test results, and reattaches the superblock to the tail of the test block circular queue. The plane types include single-plane, multi-plane, and partial-plane types, and the storage unit types include single-layer storage units and multi-layer storage units.

[0015] In at least one possible implementation, the plane type is a partial plane, and the planes participating in the operation are specified by a plane bitmap, wherein the values ​​of the plane bitmap exclude all 0s and all 1s, as well as values ​​where the number of bits equal to 1 is less than 2.

[0016] In at least one possible implementation, the method further includes: In response to the parsing result being a special command operation, the special command interface is called to obtain the return result, the return result is compared with a preset reference value, and test anomaly information is output based on the comparison result; The special command interface includes at least one of the interfaces for reading flash memory identifiers, reading unique identifiers, obtaining temperature, setting characteristics, and obtaining status; the preset reference value includes a fixed value, a verification rule, or a numerical range.

[0017] In at least one possible implementation, the method further includes: In response to the parsing result, perform raw read / write performance operations, perform an erase operation on the target superblock, and perform data transmission operations according to the preset channel parallel access order; Record the start and end times of transmission to calculate the measured performance value, compare the measured performance value with the preset benchmark performance value, and output test anomaly information based on the comparison result.

[0018] Secondly, embodiments of this application provide a test device including a processor and a memory, the memory being coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, and when the processor reads the computer instructions from the memory, causing the processor to execute the steps in the flash memory control layer independent test method as described in the first aspect.

[0019] Thirdly, embodiments of this application provide a computer program product, the computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the steps in the independent flash memory control layer test method as described in the first aspect.

[0020] The beneficial effects of this application are: This application embodiment automatically maintains the state of each superblock by setting an independent state list and state transition management in the FCL, thereby ensuring that each operation in the randomly generated mixed operation sequence acts on the correct block without any FTL code, and updates the state after the operation, thus realizing long-term, high-intensity mixed stress testing. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating the independent testing method for the flash memory control layer according to an embodiment of this application.

[0023] Figure 2 This is a schematic diagram of the mixed sequential test process in the independent test method for the flash memory control layer of this application embodiment.

[0024] Figure 3 This is a schematic diagram of the structure of the test equipment according to an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0026] It should be noted that: throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions; in the description of this application, the terms "center," "longitudinal," "lateral," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the scope of protection of this application; in the description of this application, "first," "second," etc., are only used to distinguish each other, and do not indicate their degree of importance or order, etc.

[0027] In the description of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linkage" should be interpreted broadly. For example, they can refer to fixed connections, movable connections, or detachable connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; they can refer to the internal communication between two components, etc. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0028] To facilitate a full understanding of this application, we will first briefly describe the functions of FTL and FCL in the three-layer architecture of SSD firmware and their interrelationships.

[0029] I. FTL undertakes the following key responsibilities: Logical-to-physical address mapping (L2P mapping): Converts the logical block address (LBA) issued by the host into the physical address of the NAND flash memory (including channel, die, plane, block, page).

[0030] Superblock (SPB) state management: Maintaining the current state of each SPB, including: Free: A free block that has been erased and is writable; Closed / Used: Blocks that have been filled with data and are no longer accepting new data writes; Erasing: The block that is currently being erased; Open (Writing): The block that is currently being written to and has not yet been closed; Bad block: An unusable or invalid block; Garbage collection (GC): When there are not enough free blocks, blocks containing invalid data are reclaimed from the written blocks, erased, and then added back to the free pool; Wear leveling (WL): Ensures that the number of erases and writes on all superblocks is as even as possible, preventing some blocks from reaching their lifespan limit prematurely; Write amplification suppression: Reduces the amount of data actually written to NAND through intelligent data layout and recycling strategies.

[0031] II. The "Stateless" Design of FCL: FCL itself is stateless. Its only responsibility is: Receive commands from FTL (erase, write, read, special commands, etc.); Commands, addresses, and data are sent to the flash memory chips according to the NAND interface timing. Returns the operation result (success / failure, and the data read).

[0032] The FCL doesn't care whether the block it's erasing is free or has already been written to, whether the page being written to has already been written to, or how many times a block has been erased and written to before. It's simply an "executor" that returns the result to the FTL after execution, and the FTL decides what to do next.

[0033] III. State Management Requirements for Hybrid Testing: Mixed testing refers to a test sequence that randomly interweaves various operations such as erase, write, and read, rather than a fixed erase→write→read order. This type of testing imposes the following requirements on the FCL: 1. Write operations must be performed on the correct superblock: Write operations can only be performed on free blocks that have already been erased. Attempting to write data to a block that has not yet been erased (i.e., a block that still contains old data) will usually result in a program failure and may even corrupt the block.

[0034] Problem: Without an FTL, the FCL doesn't know which blocks are free. The FCL only knows the physical addresses of all blocks, but not which blocks have been written to.

[0035] 2. The erasing operation should not be performed arbitrarily: The erase operation can only be performed on blocks that are full and whose data is no longer needed. Erase a block that still contains valid data arbitrarily, and the data will be lost.

[0036] In mixed testing, if erase commands are generated randomly, it must be ensured that the blocks to be erased do not currently contain valid data (or the test framework allows data to be discarded, but at least it should know whether the block is being used).

[0037] Problem: FCL does not know whether there is valid data on a certain block (for example, the block may have just been written and has not yet been read; or it may have been read but the test framework has not yet released it).

[0038] 3. Read operations can read any block that contains data: Read operations can only read from blocks that have already been written to. If you read from a block that has never been written to (i.e., a block that has just been erased), the data read may be all 1s or random values, making it impossible to determine its correctness.

[0039] Problem: The FCL (Fulfilled Logical Class) doesn't know which block contains valid data. It can read from any address, but the results may not be usable for consistency checks.

[0040] 4. State dependencies between operations: In mixed sequences, a write operation is often followed by a read operation on the block (or pages within the block) to verify the correctness of the data.

[0041] If an erase operation occurs on the block between a write and a read operation, the read operation will fail (because the data has been erased).

[0042] Problem: FCL is unable to maintain a history of "which block was written to and when it was erased", and therefore cannot avoid this conflict.

[0043] IV. How does FTL solve these problems in real SSDs? When a real SSD is running, the FTL maintains a complete superblock state table to ensure that every operation is legal. Write operation: FTL takes a free block from the Free List, marks it as "Open for writing," and then notifies FCL to write data to that block. After the write is complete, if the block is not full, it remains in the "Open" state; if it is full, it is moved to the Closed List.

[0044] Erasure operation: The FTL selects a block from the full list (usually the block containing the most invalid data selected by the garbage collection algorithm), marks it as "Erasing", and notifies the FCL to erase it. After erasure, it is moved to the free list.

[0045] Read operation: FTL finds the physical address of the data (which may be located in an Open or Closed block) based on the L2P mapping table and notifies FCL to read it.

[0046] V. The challenges of mixed testing without FTL: Without FTL code, performing mixed testing using only FCL (i.e., randomly generating erase, write, and read commands) will encounter the following problems: Write operations may write to blocks that have not yet been erased, causing programming failures and early testing to stop due to errors, making long-term mixed testing impossible.

[0047] An erase operation may erase the block that was just written, causing the written data to be erased and subsequent reads to fail, but the test framework does not know whether this is expected behavior or an error.

[0048] A read operation may read a block that has never been written to, resulting in random data that does not match the expected data and the test fails.

[0049] The test framework cannot distinguish between "legitimate failures" and "abnormal failures." For example, a failure to write to an unerased block is an "expected failure" (because the operation is illegal), while a failure to write to a free block is a genuine hardware error.

[0050] Unable to simulate garbage collection and wear leveling, all superblocks become full as the test progresses, and there is no mechanism to reclaim and reuse the full blocks, making the test unsustainable.

[0051] It cannot simulate the sequential write behavior of Open blocks. If a new block is allocated for each write, it does not match the behavior of a real SSD and cannot expose defects related to "closing after the block is full".

[0052] Without the involvement of FTL, traditional FCL testing can only perform single-function verification (such as single erase test, single write test, single read test) or fixed-sequence erase-write-read test (erase → write → read, and use different blocks each time), and cannot perform random interleaved mixed stress test.

[0053] Therefore, existing flash controller testing generally focuses on hardware logic verification, FTL algorithm simulation, or system-level testing, and has not developed a set of high-coverage automated unit test solutions specifically for flash control layer (FCL) software code.

[0054] Therefore, this application provides a flash memory control layer independent testing method, aiming to automatically maintain the state of each superblock without any FTL code, ensuring that each operation in the randomly generated mixed operation sequence acts on the correct block, and updating the state after the operation, thereby achieving long-term, high-intensity mixed stress testing. Please refer to... Figure 1 The method includes: In step S100, the received flash memory control layer independent test command is parsed; In step S200, in response to the parsing result being a random operation, a corresponding random operation sequence is generated; In step S300, a target superblock matching the operation type in the random operation sequence is obtained from a preset superblock state list. After the corresponding operation is executed, the test result is output, and the target superblock whose state changes after the operation is moved to the superblock state list corresponding to its state after the operation. The operation types include erase operation, write operation and read operation, and the preset superblock state list includes the corresponding eraseable state list, writable state list and readable state list. The corresponding operations performed include at least the following: In response to performing a write operation, data is written to a target superblock stored in a preset active write unit, wherein the active write unit is used to store the target superblock currently being written.

[0055] The core of this application's embodiments lies in solving the problem that existing FCL tests cannot manage the superblock state without FTL participation, resulting in the inability to perform complex state-dependent tests; it achieves automatic maintenance of the state of each superblock through state lists and state transitions without any FTL code, ensuring that each operation in the randomly generated mixed operation sequence acts on the correct block, and updating the state after the operation, thus realizing long-term, high-intensity mixed stress testing.

[0056] In existing technologies, each write operation typically reallocates a new superblock from the free list, which cannot simulate the sequential write behavior of FTL open blocks during real SSD operation, making it difficult to expose defects related to block closing and state switching. This application introduces an active write unit, allowing multiple consecutive write operations to be performed on the same superblock until the block is full. This effectively improves the realism of the test and the coverage depth of the write path.

[0057] Specifically, this can be achieved through the following process: In the test framework, maintain an active write unit, which is set as a pointer to the superblock currently being written to. Separate active write units can be maintained for Single-Level Cell (SLC) mode and Multi-Level Cell (MLC / TLC / QLC) mode.

[0058] When performing a write operation, first check if the active write cell is empty.

[0059] If the list is empty, a superblock is retrieved from the list of writable states and its address is stored in the active write unit.

[0060] Then, data is written to the current page of the superblock pointed to by the active write unit (as indicated by the write pointer).

[0061] After writing, the write pointer is moved one page forward. If all pages of the superblock have been written, the block is marked as "full," and a migration operation is triggered subsequently.

[0062] In at least one possible implementation, the response to perform a write operation further includes: If the target superblock in the active write unit is full, then the target superblock is moved to the readable state list; and / or If the active write unit is empty, a target superblock is obtained from the writable state list and placed into the active write unit; and / or The corresponding operation also includes: In response to the execution of a read operation, data is read from the target superblock in the readable state list or from the target superblock in the active write unit where data has already been written.

[0063] This embodiment further defines two special cases for the active write unit: if the active write unit is full, the target superblock is moved to the readable state list; if the active write unit is empty, a superblock is retrieved from the writable state list and placed into the active write unit. This ensures that the active write unit always points to a valid, currently being written superblock, preventing write operations from failing due to a lack of available blocks, while also ensuring that a full block can be closed and enter a readable state in a timely manner.

[0064] Specifically, this can be achieved through the following process: After each write operation is completed, check whether the current superblock has been filled (i.e., whether the write pointer has pointed to the last page + 1 of the block).

[0065] If the superblock is full, it is removed from the active write cell and moved to the readable state list (Close list). The active write cell is then set to empty.

[0066] Before the next write operation begins, if the active write cell is empty, a new superblock is retrieved from the writable state list, placed into the active write cell, and the write pointer is reset.

[0067] If the writable state list is empty, the resource reclamation mechanism is triggered.

[0068] In at least one possible implementation, the active write unit includes a single-level storage mode write unit and a multi-level storage mode write unit.

[0069] SLC mode differs from non-SLC modes (such as MLC, TLC, and QLC) in terms of write speed, block size, and endurance. Mixing them with the same active write unit can lead to test distortion. This application addresses this by maintaining independent active write units for different storage unit modes to adapt to the write characteristics and block management strategies of different modes, making the tests more refined and accurate.

[0070] In at least one possible implementation, the active write unit is configured as a pointer to the superblock being written.

[0071] This embodiment defines the active write unit as a single-level storage mode write unit and a multi-level storage mode write unit.

[0072] Specifically, this can be achieved through the following process: During test initialization, two active write units are created: one for SLC mode and one for multi-level storage unit mode (such as MLC / TLC / QLC).

[0073] When the test case specifies the storage unit mode, the corresponding active write unit is selected for the write operation.

[0074] The two active write units are independent of each other, each maintaining its own write pointer and current superblock, and do not interfere with each other.

[0075] In at least one possible implementation, the step of migrating the target superblock whose state has changed after the operation to the superblock state list corresponding to its state after the operation specifically includes: When the erase operation is successful, the target superblock is moved from the eraseable state list to the writable state list; When a write operation is successful and the target superblock is full, it is moved to the readable state list; When the read operation is successful, the state of the target superblock is not changed.

[0076] In existing technologies, read operations only read from closed blocks, without considering reading from active blocks that are currently being written to. However, during real SSD operation, the host may read from the same address immediately after writing, at which point the data may still be in an active block and not yet closed. This application's embodiments, by setting an active write unit, support reading from the active write unit, simulating a scenario where firmware actually reads open blocks, and revealing defects related to cache consistency.

[0077] Specifically, the following process can be used to achieve this: When a read operation is performed, the test framework determines the read source based on the instructions of the operation sequence (which can be randomly selected or based on preset rules).

[0078] If reading from the active write unit, first check if the active write unit is empty. If it is not empty, then randomly select a page address from the superblock pointed to by the active write unit according to the write pointer range to read the data.

[0079] If reading from the readable state list, a superblock is randomly selected from the closed list, and then a page address within that block is randomly selected to read the data.

[0080] The read data is compared with the previously written expected data to verify data consistency.

[0081] In at least one possible implementation, the preset superblock state list further includes a bad block state list, and the step of migrating the target superblock whose state has changed after the operation to a superblock state list consistent with its state after the operation specifically includes: When the erase, write, or read operation fails, the target superblock is migrated to the bad block status list.

[0082] This application embodiment achieves automatic isolation of bad blocks by setting a bad block status list and a resource reclamation mechanism: when the erase, write or read operation fails, the target superblock is migrated to the bad block status list; when there are no available superblocks in both the erasable status list and the writable status list, a superblock is selected from the readable status list and migrated to the erasable status list, thus preventing the failure block from continuing to participate in the test and causing the error to spread, and ensuring the stability of the test.

[0083] In at least one possible implementation, the output test results specifically include: After the preset test stop condition is met, check whether the bad block status list is empty; if it is empty, the test is considered to have passed; otherwise, the test is considered to have failed, and the superblock information in the bad block status list is output.

[0084] This embodiment defines the output method of the test results: after the preset test stop condition is reached, check whether the bad block status list is empty; if it is empty, the test is determined to be passed; otherwise, the test is determined to be failed, and the superblock information in the bad block status list is output.

[0085] In at least one possible implementation, generating the corresponding random operation sequence includes: Randomly select one or more write and read operations from a pre-built operation library to generate a random operation sequence that mixes one or more write and read operations, and trigger an erase operation through a write operation; and / or When neither the erasable state list nor the writable state list has a usable superblock, a superblock is selected from the readable state list and migrated to the erasable state list.

[0086] This embodiment limits the repeated execution of a random operation sequence until a stopping condition is met. The stopping condition includes the number of tests in the single-level storage cell mode reaching a first threshold and / or the number of tests in the multi-level storage cell mode reaching a second threshold.

[0087] SLC mode has high durability (tens of thousands of write cycles), while non-SLC mode has low durability (approximately 3,000 TLC cycles). This application addresses these characteristics by applying differentiated test intensities to the two modes, ensuring the test intensity matches the hardware characteristics. This guarantees that the SLC mode is adequately tested while avoiding false bad blocks in the non-SLC mode due to excessive write / erase cycles.

[0088] In at least one possible implementation, the method further includes: Repeat the random operation sequence until a preset test stop condition is met; the test stop condition includes: the number of tests on the target superblock in single-level storage unit mode reaches a first threshold, and / or, the number of tests on the target superblock in multi-level storage unit mode reaches a second threshold.

[0089] This application embodiment generates operation sequences by randomly selecting more flexible and unpredictable operation sequences, thereby improving the randomness and coverage of the test, making it easier to expose defects under random interleaving, and discovering state machine errors and resource contention issues.

[0090] Specifically, it can be achieved through the following process: During the test initialization phase, an operation library is built, which contains two basic operation types: write operation and read operation. Each operation can be accompanied by parameters (such as data mode, address range, etc.).

[0091] When an operation sequence needs to be generated, a random number generator is used to randomly select operations from the operation library and arrange them into a sequence according to the order of selection.

[0092] The sequence length can be preset (e.g., 100 operations) or determined randomly.

[0093] The generated operation sequence can be purely random, or it can be weighted random according to a certain probability distribution (such as 60% write and 40% read).

[0094] And the erase operation is triggered by the write operation.

[0095] In at least one possible implementation, please refer to Figure 2 The method further includes: In step S400, in response to the parsing result in step S100, a sequential operation is performed to retrieve the superblock from the test block circular queue; In step S500, the various working modes formed by the combination of plane type and storage unit type are traversed, and the erase operation, write operation and read operation are performed on the super block in sequence. Then, the test result is output and the super block is remounted to the tail of the test block circular queue. The plane types include single-plane, multi-plane, and partial-plane types, and the storage unit types include single-layer storage units and multi-layer storage units.

[0096] The test procedure for the erase / write / read sequential operation sequence provided in this embodiment can be executed in combination with the above-mentioned random operation sequence, or it can be executed independently. Compared with the prior art, which only tests a single working mode (such as single-plane + SLC) when performing sequential operations, this embodiment systematically traverses all six combinations of plane types (single-plane, multi-plane, partial-plane) and storage cell types (SLC, non-SLC), solving the problem that the correctness of erase / write / read operations of FCL may vary in different working modes, and that single-mode testing cannot cover all scenarios. It comprehensively verifies the erase / write / read function, ensuring that FCL can correctly perform erase / write / read operations in all common operating modes, thus improving test coverage.

[0097] In at least one possible implementation, the plane type is a partial plane, and the planes participating in the operation are specified by a plane bitmap, wherein the values ​​of the plane bitmap exclude all 0s and all 1s, as well as values ​​where the number of bits equal to 1 is less than 2.

[0098] This application embodiment ensures that FCL can correctly perform partial plane operations under all possible plane combinations by excluding invalid combinations (no plane, single plane only, full plane), while avoiding invalid tests.

[0099] Taking a 4-plane NAND chip as an example, the plane bitmap is a 4-bit binary number, where each bit represents a plane (1 indicates operation on that plane).

[0100] Exclude all 0s (no plane operation, meaningless), all 1s (i.e., 1111, equivalent to multi-plane mode), and values ​​where the number of bits equal to 1 is less than 2 (i.e., 0001, 0010, 0100, 1000, these are equivalent to single-plane mode and have been covered in single-plane testing).

[0101] Valid bitmap values ​​include: 0011 (3), 0101 (5), 0110 (6), 0111 (7), 1001 (9), 1010 (10), 1011 (11), 1100 (12), 1101 (13), 1110 (14).

[0102] During testing, the bitmap values ​​are traversed in sequence: 0x3 → 0x5 → 0x6 → 0x7 → 0x9 → 0xA → 0xB → 0xC → 0xD → 0xE. A complete erase-write-read sequence is performed for each bitmap value, thus ensuring that all possible plane combinations are covered.

[0103] In at least one possible implementation, the method further includes: In response to the parsing result being a special command operation, the special command interface is called to obtain the return result, the return result is compared with a preset reference value, and test anomaly information is output based on the comparison result; The special command interface includes at least one of the interfaces for reading flash memory identifiers, reading unique identifiers, obtaining temperature, setting characteristics, and obtaining status; the preset reference value includes a fixed value, a verification rule, or a numerical range.

[0104] In at least one possible implementation, the method further includes: In response to the parsing result, perform raw read / write performance operations, perform an erase operation on the target superblock, and perform data transmission operations according to the preset channel parallel access order; The start and end times of transmission are recorded to calculate the measured performance value. This measured performance value is compared with a preset benchmark performance value, and test anomaly information is output based on the comparison result. This embodiment limits the implementation of the read operation: in response to the execution of the read operation, data is read from the target superblock in the readable state list or from the target superblock in the active write unit where data has already been written.

[0105] This application embodiment ensures the correctness of the FCL's function in correctly identifying special commands crucial to the stable operation of the system, such as flash memory, configuration parameters, and status acquisition, through systematic special command verification, thereby improving firmware reliability.

[0106] Specifically, the following process can be used to verify various special commands: Read NAND ID: Call the FCL interface to obtain the ID byte sequence and compare it byte by byte with the standard value in the chip datasheet.

[0107] Read Unique ID: After obtaining the unique ID, verify it according to the verification rules (such as the XOR result of all bytes being 0).

[0108] Get Temperature: Read the temperature value and determine whether it is within a reasonable range (e.g., -40℃ to 125℃).

[0109] Set / Get Feature: First, call Set Feature to set a value, then call GetFeature to read it, and compare whether the two are consistent.

[0110] Get Status: Read the status register to determine if the device is in a ready state (e.g., 0xE0).

[0111] If any comparison fails, an exception message will be output, including the type of the failed command, the expected value, the actual value, and the flash memory chip identifier.

[0112] In at least one possible implementation, the method further includes: In response to the parsing result, perform raw read / write performance operations, perform an erase operation on the target superblock, and perform data transmission operations according to the preset channel parallel access order; Record the start and end times of transmission to calculate the measured performance value, compare the measured performance value with the preset benchmark performance value, and output test anomaly information based on the comparison result.

[0113] Existing performance tests are typically performed at the system level (such as FIO), introducing FTL overhead, which makes it impossible to distinguish between FCL bottlenecks and FTL bottlenecks, making it difficult to accurately locate performance problems. The embodiments of this application directly measure the raw performance of the FCL, eliminating the influence of FTL and the file system, thus better reflecting the hardware's limits and accurately assessing the maximum bandwidth of NAND hardware, providing a basis for performance optimization.

[0114] Specifically, the following process can be used to achieve basic read and write performance operations: Select a free superblock and perform an erase operation.

[0115] Data transmission operations are performed according to a preset parallel access order for the channels. For example, for a configuration of 2 channels and 1 die per channel, the write order is: CH0 DIE0 PAGE0 → CH1 DIE0 PAGE0 → CH0 DIE0 PAGE1 → CH1 DIE0 PAGE1 … to fully utilize the channel parallelism.

[0116] Record the start time (time_start) and end time (time_end) of the transmission.

[0117] Calculate the measured performance value: Performance = TotalDataMB / (time_end - time_start) MB / s.

[0118] Compare the measured values ​​with the baseline values. The baseline values ​​can be obtained through theoretical calculations (based on the flash interface frequency, bit width, and number of channels) or by pre-measuring them on the same hardware using standard tools.

[0119] If the measured value is less than the benchmark value (with a certain margin of error), an abnormal performance information will be output, including the measured value, the benchmark value, and the test conditions.

[0120] The following example simulates a complete FCL hybrid stress test, covering state list initialization, random operation sequence generation, writing (active write unit), erasing, reading, failure handling, resource reclamation, stop condition checking, and result determination.

[0121] I. Test Environment: Hardware: Test board, equipped with SSD controller chip, connected to 4 NAND flash memory chips, each chip has 2 dies, each die has 4 planes, each plane has 256 superblocks, and each block has 2048 pages (16KB per page).

[0122] Firmware: Before testing begins, a separate compilation script can be used to generate only the FCL code and its corresponding unit test code. The generated target test firmware does not contain the business logic of FTL and FEL. This firmware is then burned to the target storage device using an activation tool. This decouples the test code from the business code, and adding or modifying test cases does not require recompiling the entire firmware project, greatly improving the flexibility and efficiency of testing.

[0123] Test host: A PC connects to the test board via a serial port and runs the test script.

[0124] II. Test Initialization: Power-on self-test: After the test board is powered on and the target test firmware starts, it first executes the FCL initialization process to verify the communication link with the NAND Flash chip (such as sending a reset command, reading the status register, and reading the NAND ID). If initialization fails, the test firmware immediately stops the test and reports the exception information via the serial port; if initialization is successful, it continues to execute subsequent tests.

[0125] Construct the superblock state list: Scan all SPBs and check the validity of each SPB by reading its status or the table of known bad blocks. Add completely intact SPBs to the eraseable state list (Invalid List), and partially damaged SPBs to the partially invalid state list (Partial Invalid List). In this example, 100 intact SPBs are obtained, with each SPB spanning 2 dies × 4 planes = 8 planes.

[0126] The initial free list of writable states is empty.

[0127] The initial readable state list (Close List) is empty.

[0128] The Bad List is initialized to be empty.

[0129] Initialize active write units: Create two active write units, one for SLC mode and one for multi-level storage cell mode (this example uses TLC mode), both initially empty.

[0130] Initialization operation library: Includes two operation types: write and read, each with default parameters (data mode 0x55AA, random address, etc.).

[0131] III. Test command reception: Receive the command to execute a mixed random test (mix_test) from the serial terminal: 10,000 tests in SLC mode and 3,000 tests in non-SLC (TLC) mode, based on the number of tests, with no time limit.

[0132] The test framework parses the command, identifies the target test case as mix_test, and begins execution.

[0133] IV. Test execution of the main loop: The test framework enters the main loop, with the loop variable `test_round` incrementing from 1 until the stopping condition is met. Each round executes the following steps: Step 1: Generate a sequence of random operations: Operations are randomly selected from a pre-defined operation library to generate the operation sequence for this round (length random, 5-20). For example, the sequence generated in round 1 is: [Write, Read, Write, Read, Write, Read, Write, Read, Write, Read] Step 2: Traverse the operation sequence and perform the following sub-steps for each operation: Initialize the current operation index i=0, and the current operation object current_op.

[0134] Operation 1: Write Type: Write.

[0135] Check the active write cell (SLC mode, because this example uses SLC mode for mixed testing by default; you can also choose a mode randomly, but for simplicity, we use SLC here). The current active write cell is empty.

[0136] Retrieve SPB from the writable state list: The current writable state list is empty (initially no free blocks), therefore the erase process is triggered. Take an SPB (e.g., SPB_0) from the list of erasable states.

[0137] Call the FCL erase interface to erase the SPB. After successful erasure, move the SPB from the eraseable state list to the writable state list.

[0138] To place an SPB into the active write unit: retrieve SPB_0 from the writable state list, place it into the active write unit, and set the write pointer to page 0 of the SPB.

[0139] Write operation: The FCL write interface is called to write test data (e.g., 0x55AA mode) to page 0 of SPB_0. Write successful.

[0140] Check if it is full: SPB has a total of 256 pages. This time, it is writing to page 0, which is not full. Therefore, it remains in the active write cell, and the write pointer moves forward.

[0141] Operation 2: Read: Type: Read.

[0142] Choose read source: Randomly decide whether to read from the active write cell (70% probability) or from the list of readable states (30% probability). This time, it was randomly selected to read from the active write cell.

[0143] Perform a read operation: Read data from page 0 of SPB_0, compare it with the expected data, and they match. Read successful, status unchanged.

[0144] Subsequent operations are similar. If a write operation encounters an empty writable state list, an erase process is triggered to retrieve a block from the eraseable state list. After erasure is completed, the block is moved into the writable state list, and writing continues.

[0145] Step 3: Failure Handling Suppose a write operation fails (e.g., a programming error is returned when writing to SPB_X): Remove SPB_X from its current list (active write cell or writable state list) and move it to the bad block state list.

[0146] At the same time, if the block is in the active write unit, the active write unit is cleared (set to empty).

[0147] The test continues (without stopping unless configured to stop upon encountering an error). The bad block list records the address of SPB_X and the reason for failure.

[0148] Step 4: Stop condition check: After each round, check the number of tests for each superblock: For SLC mode, each block needs to be tested ≥ 10000 times in SLC mode.

[0149] For TLC mode, each block needs to be tested ≥ 3000 times in TLC mode.

[0150] The test is stopped when the number of SLC tests for all active SPBs (excluding bad blocks) reaches 10,000, or the number of non-SLC tests for all active SPBs reaches 3,000.

[0151] V. Test Result Determination: After stopping, check the bad block status list: if the bad block list is empty, the test passes; if the bad block list is not empty, the test fails and outputs a bad block information list, and can also output statistical information such as total number of operations, number of tests in each mode, throughput, etc.

[0152] The test is complete. Return to the command prompt.

[0153] VI. Other operation examples: In addition to the mixed tests described above, other tests can also be performed, for example: Erase-write-read order test: Input `run erase_read_test` to execute six working modes, using a circular queue to manage the superblock, without relying on a state list. The specific process is as follows: A test block circular queue is pre-built, and test-available SPBs are added to the queue.

[0154] Take a superblock from the head of the queue.

[0155] The six working modes will be executed sequentially: SPSLC: Single-plane + SLC mode, performs erase → write → read, and verifies data consistency.

[0156] MPSLC: Multi-plane + SLC mode.

[0157] PPSLC: Partial Plane + SLC mode.

[0158] SP_NOT_SLC: Single-plane + non-SLC mode (such as TLC).

[0159] MP_NOT_SLC: Multi-plane + non-SLC mode.

[0160] PP_NOT_SLC: Partial planar + non-SLC mode.

[0161] In each mode, the corresponding interface function of FCL is called to write the preset test data, which is then read and compared with the original data.

[0162] If any step fails, stop the test immediately and report the exception.

[0163] After all modes are completed, the superblock is reattached to the end of the queue for repeated use.

[0164] Special command test: Enter run special_cmd_test to read NAND ID, unique ID, temperature, etc., and compare them with the reference values.

[0165] Performance testing: Enter `run perf_test --mode write` to measure the raw write bandwidth of the FCL.

[0166] These tests can be performed individually or in combination with mixed tests in sequence (the order can be specified via serial port commands).

[0167] Please refer to Figure 3 This application embodiment also provides a test device, including a processor 100 and a memory 200, wherein the memory 200 is coupled to the processor 100 and is used to store computer program code, the computer program code including computer instructions, wherein when the processor 100 reads the computer instructions from the memory 200, the processor 100 executes the steps in the flash memory control layer independent test method of any possible implementation of any of the foregoing embodiments.

[0168] This application also provides a computer program product, which includes computer program code that, when run on a computer, causes the computer to perform the steps of the method in any of the possible implementations of the foregoing embodiments.

[0169] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0170] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for independent testing of flash memory control layer, characterized in that, The method includes: Parse the received independent test commands for the flash memory control layer; In response to the parsing result, a random operation is performed, generating a corresponding sequence of random operations; Obtain the target superblock that matches the operation type in the random operation sequence from the preset superblock state list, execute the corresponding operation, output the test result, and migrate the target superblock whose state changes after the operation to the superblock state list corresponding to its state after the operation. The operation types include erase operation, write operation and read operation, and the preset superblock state list includes the corresponding eraseable state list, writable state list and readable state list. The corresponding operations performed include at least the following: In response to performing a write operation, data is written to a target superblock stored in a preset active write unit, wherein the active write unit is used to store the target superblock currently being written.

2. The independent testing method for the flash memory control layer according to claim 1, characterized in that, The response to perform a write operation also includes: If the target superblock in the active write unit is full, then the target superblock is moved to the readable state list; and / or If the active write unit is empty, a target superblock is obtained from the writable state list and placed into the active write unit; and / or The corresponding operation also includes: In response to the execution of a read operation, data is read from the target superblock in the readable state list or from the target superblock in the active write unit where data has already been written.

3. The independent testing method for the flash memory control layer according to claim 1, characterized in that, The active write unit includes a single-level storage mode write unit and a multi-level storage mode write unit; and / or, the active write unit is configured as a pointer to the superblock being written.

4. The independent testing method for the flash memory control layer according to any one of claims 1-3, characterized in that, The step of migrating the target superblock whose state has changed after the operation to the superblock state list corresponding to its state after the operation specifically includes: When the erase operation is successful, the target superblock is moved from the eraseable state list to the writable state list; When a write operation is successful and the target superblock is full, it is moved to the readable state list; When the read operation is successful, the state of the target superblock is not changed.

5. The independent testing method for the flash memory control layer according to claim 4, characterized in that, The preset superblock state list also includes a bad block state list. The specific steps of migrating the target superblock whose state has changed after the operation to the superblock state list corresponding to its state after the operation include: When the erase, write, or read operation fails, the target superblock is migrated to the bad block status list.

6. The independent testing method for the flash memory control layer according to claim 5, characterized in that, The output test results specifically include: After the preset test stop condition is met, check whether the bad block status list is empty; if it is empty, the test is considered to have passed; otherwise, the test is considered to have failed, and the superblock information in the bad block status list is output.

7. The independent testing method for the flash memory control layer according to any one of claims 1-3, characterized in that, The generation of the corresponding random operation sequence includes: Randomly select one or more write and read operations from a pre-built operation library to generate a random operation sequence that mixes one or more write and read operations, and trigger an erase operation through a write operation; and / or When neither the erasable state list nor the writable state list has a usable superblock, a superblock is selected from the readable state list and migrated to the erasable state list.

8. The independent testing method for the flash memory control layer according to any one of claims 1-3, characterized in that, Also includes: Repeat the random operation sequence until the preset test stop condition is met; The test stopping conditions include: the number of tests on the target superblock in single-level storage unit mode reaches a first threshold, and / or the number of tests on the target superblock in multi-level storage unit mode reaches a second threshold.

9. The independent testing method for the flash memory control layer according to any one of claims 1-3, characterized in that, The method further includes: In response to the parsing result being a sequential operation, the superblock is retrieved from the test block circular queue; The system iterates through various working modes formed by combinations of plane type and storage unit type, performs erase, write and read operations on the superblock in sequence, outputs the test results, and reattaches the superblock to the tail of the test block circular queue. The plane types include single-plane, multi-plane, and partial-plane types, and the storage unit types include single-layer storage units and multi-layer storage units.

10. The independent testing method for the flash memory control layer according to claim 9, characterized in that, The plane type is a partial plane, and the planes participating in the operation are specified by a plane bitmap. The values ​​of the plane bitmap exclude all 0s and all 1s, as well as values ​​where the number of bits equal to 1 is less than 2.

11. The independent testing method for the flash memory control layer according to any one of claims 1-3, characterized in that, The method further includes: In response to the parsing result being a special command operation, the special command interface is called to obtain the return result, the return result is compared with a preset reference value, and test anomaly information is output based on the comparison result; The special command interface includes at least one of the interfaces for reading flash memory identifiers, reading unique identifiers, obtaining temperature, setting characteristics, and obtaining status; the preset reference value includes a fixed value, a verification rule, or a numerical range.

12. The independent testing method for the flash memory control layer according to any one of claims 1-3, characterized in that, The method further includes: In response to the parsing result, perform raw read / write performance operations, perform an erase operation on the target superblock, and perform data transmission operations according to the preset channel parallel access order; Record the start and end times of transmission to calculate the measured performance value, compare the measured performance value with the preset benchmark performance value, and output test anomaly information based on the comparison result.

13. A testing device, characterized in that, It includes a processor and a memory coupled to the processor. The memory is used to store computer program code, which includes computer instructions. When the processor reads the computer instructions from the memory, the processor performs the steps in the independent test method for the flash memory control layer as described in any one of claims 1-12.

14. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the steps in the independent test method for the flash memory control layer as described in any one of claims 1-12.

Images