Verification method, verification device and storage medium of flash translation layer algorithm

Abstract

This application relates to the field of solid-state drive technology, and in particular to a verification method, verification device, and storage medium for a flash memory conversion layer algorithm. In this method, a processor can configure different flash memory characteristic parameters for a flash memory simulation platform to simulate different virtual flash memory chips. This method does not require consuming real flash memory chips, which helps reduce verification costs. The processor drives the flash memory conversion layer algorithm to run in the test scenario corresponding to the test script by executing a test script. During the execution of the test script, the processor can monitor flash memory operation instructions, obtain the real flash memory operation data generated by the flash memory simulation platform, and obtain the flash memory operation metadata recorded by the flash memory conversion layer algorithm that corresponds to the real flash memory operation data. Based on this data, the flash memory conversion layer algorithm can be more thoroughly verified, which helps improve the reliability of the verification results.

Description

Technical Field

[0001] This application relates to the field of verification technology for flash memory conversion layer algorithms, and in particular to a verification method, verification device, and storage medium for flash memory conversion layer algorithms. Background Technology

[0002] Current mainstream file systems are designed for traditional hard drives and cannot be directly applied to flash-based solid-state drives (SSDs). SSDs introduce a flash translation layer between the file system and the flash memory chips, simulating the underlying flash memory chips as a block device just like a hard drive, to ensure the compatibility of existing file systems with SSDs.

[0003] SSD performance largely depends on the design of its flash translation layer (FTL) algorithm within the controller chip. Designing and optimizing the FTL algorithm is a primary means of improving SSD read / write performance and extending lifespan. Therefore, FTL algorithm validation is necessary during the SSD development process.

[0004] Currently, the testing and verification of the FTL algorithm mainly relies on physical hardware testing and software simulation testing. Physical hardware testing typically involves burning the flash translation layer algorithm firmware into a real flash-based solid-state drive (SSD) to verify the FTL algorithm. This method requires a large number of real flash memory chip samples, resulting in high verification costs. Software simulation testing, on the other hand, often cannot verify the flash translation layer algorithm based on flash memory operation metadata, leading to insufficient verification and reduced reliability of the verification results. Summary of the Invention

[0005] This application provides a verification method, verification device, and storage medium for a flash translation layer algorithm. It can simulate real flash memory chips, reduce the verification cost of the FTL algorithm, and verify the flash translation layer algorithm based on flash memory operation metadata. This facilitates a more thorough verification of the flash translation layer algorithm and improves the reliability of the verification results.

[0006] To address the aforementioned technical problems, the embodiments of this application provide the following technical solutions: In a first aspect of this application, a verification method for a flash memory conversion layer algorithm is provided. This method is applied to a verification device, which is configured with a flash memory simulation platform. The flash memory simulation platform has configurable flash memory characteristic parameters and is configured to receive and execute flash memory operation instructions from the flash memory conversion layer algorithm. The method includes: configuring flash memory characteristic parameters of a real flash memory chip to be simulated on the flash memory simulation platform to generate a virtual flash memory chip corresponding to the real flash memory chip; executing a test script to drive the flash memory conversion layer algorithm to run in a test scenario corresponding to the test script; during the execution of the test script, monitoring the flash memory operation instructions received by the flash memory simulation platform from the flash memory conversion layer algorithm; acquiring real flash memory operation data generated by the flash memory simulation platform executing the flash memory operation instructions, and acquiring flash memory operation metadata recorded by the flash memory conversion layer algorithm corresponding to the real flash memory operation data; and verifying the flash memory conversion layer algorithm based on the flash memory operation instructions, the real flash memory operation data, and the flash memory operation metadata to obtain a verification result.

[0007] In the embodiments of this application, the flash memory simulation platform has configurable flash memory characteristic parameters; the processor can configure different flash memory characteristic parameters for the flash memory simulation platform to simulate different virtual flash memory chips. This method does not require consuming real flash memory chips, which helps reduce high verification costs. The processor drives the flash memory conversion layer algorithm to run in the test scenario corresponding to the test script by executing a test script, so that the flash memory conversion layer algorithm generates flash memory operation instructions, and the flash memory simulation platform receives and executes the flash memory operation instructions from the flash memory conversion layer algorithm. The processor can monitor the flash memory operation instructions, obtain the real flash memory operation data generated by the flash memory simulation platform executing the flash memory operation instructions, and obtain the flash memory operation metadata recorded by the flash memory conversion layer algorithm that corresponds to the real flash memory operation data; the flash memory conversion layer algorithm is verified based on the flash memory operation instructions, real flash memory operation data, and flash memory operation metadata, which helps to verify the flash memory conversion layer algorithm more fully and improve the reliability of the verification results.

[0008] In some embodiments, the flash memory characteristic parameters include architectural characteristic parameters, which are used to simulate the hierarchical storage architecture of the real flash memory chip; and / or, the flash memory characteristic parameters include factory bad block characteristic parameters, which are used to simulate the number of factory bad blocks and the distribution pattern of factory bad blocks in the physical address space of the real flash memory chip.

[0009] In some embodiments, configuring the flash memory characteristic parameters of the real flash memory chip to be simulated for the flash memory simulation platform includes: obtaining a parameter configuration file, the parameter configuration file having configurable flash memory characteristic parameters; obtaining the flash memory characteristic parameters of the real flash memory chip to be simulated based on the parameter configuration file, and configuring the flash memory characteristic parameters of the real flash memory chip to be simulated for the flash memory simulation platform.

[0010] In some embodiments, the test script includes at least one of a basic functionality test script, a programmable error injection test script, and a late-life test script.

[0011] In some embodiments, the test script includes a basic function test script; executing the test script to drive the flash conversion layer algorithm to run in the test scenario corresponding to the test script includes: executing the basic function test script to drive the flash conversion layer algorithm to run in the test scenario corresponding to the basic function test script; wherein, the basic function test script is used to perform basic function tests on the flash conversion layer algorithm, and the basic function tests include at least one of basic read-write-erase test, aging test, input / output performance test and Monkey test.

[0012] In some embodiments, the test script includes a programmable error injection test script, the virtual flash memory chip includes multiple physical blocks, and the first designated physical block is at least one of the multiple physical blocks; executing the test script to drive the flash conversion layer algorithm to run in the test scenario corresponding to the test script includes: executing the programmable error injection test script; configuring the state machine of the first designated physical block through the programmable error injection test script to define the exception triggering conditions of the first designated physical block and the exception behavior corresponding to the exception triggering conditions; driving the flash conversion layer algorithm to run in the test scenario corresponding to the programmable error injection test script; wherein, the state machine is used to: when the first designated physical block satisfies the exception triggering conditions, trigger the first designated physical block to simulate the exception behavior corresponding to the exception triggering conditions.

[0013] In some embodiments, the test script includes a late-life test script, the virtual flash memory particle includes multiple physical blocks, and the second specified physical block is at least one of the multiple physical blocks; executing the test script to drive the flash conversion layer algorithm to run in the test scenario corresponding to the test script includes: executing the late-life test script; setting the number of erases of the second specified physical block recorded on the flash simulation platform side as the target number of erases; setting the number of erases of the second specified physical block recorded on the flash conversion layer algorithm side as the target number of erases through the debugging interface of the flash conversion layer algorithm; driving the flash conversion layer algorithm to run in the test environment corresponding to the late-life test script; wherein, the target number of erases is used to represent the number of erases of the second specified physical block in the late life.

[0014] In some embodiments, verifying the flash conversion layer algorithm based on the flash operation instructions, the actual flash operation data, and the flash operation metadata includes: determining illegal behaviors in the flash operation instructions based on the flash operation instructions and a preset flash operation protocol monitoring specification; evaluating the protocol compliance of the flash operation instructions generated by the flash conversion layer algorithm based on the illegal behaviors to obtain a protocol compliance evaluation result; the preset flash operation protocol specification is used to define illegal operation behavior rules for flash operations; calculating the difference between the actual flash operation data and the flash operation metadata corresponding to the actual flash operation data; evaluating the accuracy of the flash operation metadata based on the difference to obtain a metadata accuracy evaluation result; evaluating the wear leveling performance of the flash conversion layer algorithm based on the erase count of all physical blocks in the flash operation metadata to obtain a wear leveling performance evaluation result; and evaluating the bad block management capability of the flash conversion layer algorithm based on the bad block list in the actual flash operation data and the bad block list in the flash operation metadata to obtain a bad block management capability evaluation result.

[0015] In some embodiments, illegal behaviors in the flash memory operation instructions are determined based on the flash memory operation instructions and a preset flash memory operation protocol monitoring specification. The protocol compliance of the flash memory operation instructions generated by the flash memory conversion layer algorithm is then evaluated based on the illegal behaviors to obtain a protocol compliance evaluation result. This includes: comparing the flash memory operation instructions with the preset flash memory operation protocol monitoring specification to monitor whether the flash memory operation instructions include illegal behaviors; if illegal behaviors are found in the flash memory operation instructions, real-time error reporting and recording of violation context information are performed on the illegal behaviors; and the protocol compliance of the flash memory operation instructions generated by the flash memory conversion layer algorithm is evaluated based on the violation context information to obtain a protocol compliance evaluation result.

[0016] In some embodiments, the method further includes: generating a visualization chart in real time based on the verification results during the execution of the test script; wherein the visualization chart includes a wear heat map of each physical block in the current wear state, a write magnification factor trend chart, and an operation number distribution comparison chart.

[0017] In a second aspect of this application, a verification device is also provided, the verification device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect.

[0018] In a third aspect of this application, a non-volatile computer-readable storage medium stores computer-executable instructions that, when executed, enable the execution of the method described in the first aspect.

[0019] It should be understood that the description in the Summary of the Invention section is not intended to limit the key or essential features of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0021] Figure 1 This is a schematic diagram of the internal architecture of a solid-state drive provided in some embodiments of this application; Figure 2 This is a schematic diagram of the hierarchical storage structure of flash memory chips provided in some embodiments of this application; Figure 3 This is a flowchart illustrating the verification method of the flash memory conversion layer algorithm provided in some embodiments of this application; Figure 4 This is a flowchart illustrating a method for executing a test script and driving a flash conversion layer algorithm to run in the test scenario corresponding to the test script, as provided in some embodiments of this application. Figure 5 This is a flowchart illustrating a method for verifying the flash conversion layer algorithm based on flash memory operation instructions, real flash memory operation data, and the flash memory operation metadata, according to some embodiments of this application, to obtain verification results. Figure 6This is a schematic diagram of the hardware structure of a verification device for performing a verification method for a flash memory conversion layer algorithm, provided in some embodiments of this application. Detailed Implementation

[0022] The principles and spirit of this disclosure will be described below with reference to several exemplary embodiments illustrated in the accompanying drawings. It should be understood that these specific embodiments are described merely to enable those skilled in the art to better understand and implement this disclosure, and are not intended to limit the scope of this disclosure in any way. In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art.

[0023] As used herein, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects and are used only to distinguish the objects referred to, without implying a particular spatial order, temporal order, order of importance, etc., of the objects referred to.

[0024] For example, Figure 1 Schematic diagrams of the internal architecture of solid-state drives provided in some embodiments of this application are presented. For example... Figure 1 As shown, a solid-state drive (SSD) includes an SSD controller, a host interface logic unit (HMAC) communicating with the SSD controller, a random access memory (RAM) cache, and at least one flash memory chip. The SSD controller establishes a connection with an external host (such as a computer) through the HMAC. The SSD controller includes a flash memory controller and a main control processor and a cache manager communicating with the flash memory controller. The flash memory controller communicates with each of the at least one flash memory chip (e.g., flash memory chip #1, flash memory chip #2, flash memory chip #3, and flash memory chip #4) through flash memory channels (e.g., flash memory channel #1 and flash memory channel #2), and directly performs operations such as reading, writing, and erasing the stored data on each flash memory chip.

[0025] When an external host sends a data storage command to the SSD controller through the host interface logic unit, the main controller processor temporarily stores the data to be stored in the RAM cache through the cache manager, and then writes the data temporarily stored in the RAM cache to the flash memory chip through the flash memory channel via the flash memory controller. When the host sends a data read command to the SSD controller through the host interface logic unit, the main controller processor retrieves the data to be read from the flash memory chip through the flash memory controller, and temporarily stores the retrieved data in the RAM cache through the cache manager, and then transmits it to the host through the host interface logic unit.

[0026] Flash memory chips can specifically be NOT AND (NAND) flash memory chips. A flash memory chip includes at least one die, each die includes several planes, each plane includes several physical blocks, and each physical block includes several physical pages. Specifically, each die can include tens to thousands of physical blocks, and each physical block can contain tens to hundreds of physical pages, such as 128 pages or 256 pages. For different models of solid-state drives (SSDs), the number and capacity of dies, planes, physical blocks, and / or physical pages in their flash memory chips can vary. For the same model of SSD, the number of initial bad blocks (IBBs) and / or the distribution pattern of IBBs in the physical address space can differ.

[0027] For example, Figure 2 The following are schematic diagrams illustrating the hierarchical storage structure of NAND flash memory chips provided in some embodiments of this application, such as... Figure 2 As shown, a NAND flash memory chip includes multiple planes, namely: chip 0, chip 1... chip n2; each plane includes multiple physical blocks, namely: block 0, block 1... block n1; each physical block includes multiple physical pages, namely: page 0, page 1... page n3.

[0028] Flash memory controllers operate on flash memory chips in three main ways: read, write, and erase. Read and write operations are performed at the physical page level, while erase operations are performed at the physical block level. The process of writing data into a physical page is also called a programming operation.

[0029] The Flash Translation Layer (FTL) is typically embedded as firmware within the storage area of ​​the SSD controller. The main controller processor runs the FTL algorithm. The FTL simulates flash memory chips as disk-like block devices to manage their storage. The FTL algorithm primarily handles tasks such as address mapping, garbage collection (GC), wear leveling (WL), bad block management (BBM), and read disturbance management. The performance, lifespan, and reliability of SSDs are highly dependent on the quality of the FTL algorithm. Any defects in the FTL algorithm can easily lead to data loss, performance degradation, or premature failure of the SSD. Therefore, the performance of the FTL algorithm needs to be tested and verified during SSD development. Currently, the verification methods for the FTL algorithm mainly include physical hardware testing and software simulation testing.

[0030] The physical hardware testing method involves burning the FTL firmware into a real SSD sample and then verifying the performance of the FTL firmware using a verification device. This method has the following drawbacks: (1) The testing cycle is long; especially when verifying the stability of the FTL algorithm at the end of the flash memory chip's life (in a high wear state), it requires aging tests that can last for several months to reach a sufficient number of erase / write cycles (P / E Cycles), which seriously delays the development progress; (2) The testing cost is high; it requires a large amount of real SSD samples, verification equipment, and data center resources; (3) The controllability and observability are extremely poor; it is difficult to accurately reproduce and trigger specific error scenarios (such as "failure on the 100th erase of a physical block"), and it is also impossible to obtain the real flash memory operation count of each physical block from the real flash memory chip in real time and without loss as the gold standard for comparison, which makes it difficult to locate the problems of the FTL algorithm; (3) The coverage is limited; the distribution of bad blocks and error modes of real flash memory chips at the factory are random, making it difficult to systematically cover all extreme and boundary cases (Corner Case), and the sufficiency of the test is difficult to guarantee.

[0031] Existing software simulation testing methods typically use general-purpose storage simulators (such as DiskSim) to simulate SSDs, lacking deep customizability specifically for FTL verification. This method has the following drawbacks: (1) It cannot support dynamic modification and injection of specific physical block attributes (such as erase count, error status), making it difficult to actively construct test scenarios; (2) It lacks a bidirectional data synchronization acquisition and comparison mechanism, and cannot use the underlying data of the flash simulation platform (real flash operation data) as the "gold standard" to quantitatively evaluate the accuracy of the FTL algorithm in managing flash operation metadata; (3) It does not have the function of real-time protocol compliance monitoring of the flash operation instructions generated by the FTL algorithm, and cannot detect potential violations of the FTL algorithm's operational constraint specifications; (4) The simulated NAND behavior is usually more idealized, making it difficult to accurately simulate the specific behavior of different models and quality NAND chips (such as the distribution of bad blocks from the original manufacturer).

[0032] In view of this, embodiments of this application provide a verification method for a flash memory conversion layer algorithm. In this method, the processor can configure different flash memory characteristic parameters for a flash memory simulation platform to simulate different real flash memory chips and obtain corresponding virtual flash memory chips. The processor can also monitor the flash memory operation instructions received by the flash memory simulation platform from the flash memory conversion layer algorithm during the execution of the test script-driven flash memory conversion layer algorithm, obtain the real flash memory operation data generated by the flash memory simulation platform executing the flash memory operation instructions, and obtain the flash memory operation metadata recorded by the flash memory conversion layer algorithm corresponding to the real flash memory operation data. Based on the flash memory operation instructions, real flash memory operation data, and flash memory operation metadata, the processor can more fully verify the flash memory conversion layer algorithm, improving the reliability of the verification results. To facilitate the reader's understanding of this application, specific embodiments are described below.

[0033] For example, Figure 3 The present application provides flowcharts illustrating verification methods for flash memory conversion layer algorithms according to some embodiments. These methods are applied to a verification device equipped with a flash memory simulation platform. Figure 3 As shown, the method includes the following steps: S31. The processor configures the flash memory characteristic parameters of the flash memory chip to be simulated for the flash memory simulation platform, and generates a virtual flash memory chip corresponding to the real flash memory chip.

[0034] In the embodiments of this application, the flash memory simulation platform configured in the verification device can specifically be a software simulation system. The flash memory simulation platform has configurable flash memory characteristic parameters. The processor can configure the flash memory characteristic parameters of the real flash memory chip to be simulated for the flash memory simulation platform, so that the flash memory simulation platform simulates the real flash memory chip and generates a virtual flash memory chip corresponding to the real flash memory chip. When the processor configures different flash memory characteristic parameters for the flash memory simulation platform, the virtual flash memory chip simulated by the flash memory simulation platform will also be different.

[0035] In some embodiments, flash memory characteristic parameters include architectural characteristic parameters. These architectural characteristic parameters are used to simulate the hierarchical storage architecture of real flash memory chips; they include the number and / or capacity of flash memory chips' dies, planes, physical blocks, and physical pages. The processor can configure different architectural characteristic parameters for the flash memory simulation platform to construct virtual flash memory chips corresponding to different models of real flash memory chips through the platform.

[0036] In other embodiments, the flash memory characteristic parameters also include factory bad block characteristic parameters; these parameters are used to simulate the number of factory bad blocks in the real flash memory chip to be simulated, and the distribution pattern of these bad blocks in the physical address space. Accordingly, the factory bad block characteristic parameters include the number of factory bad blocks and the distribution pattern of these bad blocks in the physical address space; wherein the distribution pattern of the bad blocks in the physical address space can be clustered, random, or edge-region distributed. The processor can also configure different factory bad block characteristic parameters for the flash memory simulation platform to construct virtual flash memory chips corresponding to real flash memory chips of different quality levels through the flash memory simulation platform, thereby verifying the flash conversion layer algorithm's ability to manage factory bad blocks.

[0037] In some embodiments, different quality levels may specifically include multiple quality levels distributed sequentially from excellent to poor. The more bad blocks a device has at the time of manufacture, the lower the quality level of the real flash memory chip and the corresponding virtual flash memory chip. The processor can also determine the range of the number of bad blocks at the time of manufacture for the virtual flash memory chip corresponding to the model characteristics of the real flash memory chip to be simulated. The range of the number of bad blocks at the time of manufacture is between a minimum number value and a maximum number value. The processor can configure the number of bad blocks at the time of manufacture for the flash memory simulation platform to any value between the minimum number value and the maximum number value (including the minimum number value and the maximum number value). The processor can also configure the distribution pattern of the bad blocks at the time of manufacture in the physical address space to be a regular distribution, a random distribution, or an edge region distribution. In this embodiment, the processor accurately simulates virtual flash memory chips with different model characteristics and / or different qualities.

[0038] In some embodiments, the flash memory simulation platform supports dynamic configuration of flash memory characteristic parameters; that is, the processor can dynamically configure different flash memory characteristic parameters for the flash memory simulation platform to simulate flash memory chips with different models and / or factory bad block characteristics.

[0039] In some embodiments, step S31 specifically includes: the processor obtaining a parameter configuration file having configurable flash memory characteristic parameters; the processor obtaining flash memory characteristic parameters of the real flash memory chip to be simulated based on the parameter configuration file, and configuring the flash memory characteristic parameters of the real flash memory chip to be simulated for the flash memory simulation platform.

[0040] Specifically, in some embodiments, the verification device has a human-machine interface that communicates with the processor. The configuration file includes initial flash memory characteristic parameters. The processor obtains the flash memory characteristic parameters of the actual flash memory chip to be simulated based on the parameter configuration file, including: the processor receiving parameter modification instructions input by the tester through the human-machine interface, and in response to the parameter modification instructions, adjusting the initial flash memory characteristic parameters in the configuration file to obtain the flash memory characteristic parameters of the actual flash memory chip to be simulated. In this embodiment, the size of the flash memory characteristic parameters can be dynamically adjusted by modifying the flash memory characteristic parameters in the configuration file.

[0041] In some embodiments, the parameter configuration file specifically includes a first configuration file and a second configuration file; wherein the first configuration file has configurable architectural feature parameters, and the second configuration file has configurable factory bad block feature parameters. The processor can obtain the architectural feature parameters of the real flash memory chip to be simulated based on the first configuration file, and obtain the factory bad block feature parameters of the real flash memory chip to be simulated based on the second configuration file.

[0042] For example, in some embodiments, the configurable architectural feature parameters in the first configuration file include: the number of blocks contained in a LUN (BLOCK_OF_LUN), the number of pages contained in a word line (PAGE_OF_WL), the number of strings contained in a word line (STRING_OF_WL), the number of SLC mode pages within a block (SLC_PAGE_OF_BLOCK), the number of sectors contained in a page (SECTOR_OF_PAGE), the flash memory model (FLASH_NAME), the capacity (CAPACITY), the number of LUNs contained in a chip (LUN_OF_CHIP), the number of word lines contained in a block (WL_OF_BLOCK), the number of pages contained in a block (PAGE_OF_BLOCK), and the number of planes (PLANE_NUM). The configuration information of the architectural feature parameters in the first configuration file is as follows: BLOCK_OF_LUN:988 PAGE_OF_WL:3 STRING_OF_WL: 1 SLC_PAGE_OF_BLOCK: 1600 SECTOR_OF_PAGE: 32 FLASH_NAME: YMN09TF1B5DCBE CAPACITY: 512G LUN_OF_CHIP:1 WL_OF_BLOCK: 1600 PAGE_OF_BLOCK:4800 PLANE_NUM: 4 The flash memory emulation platform can initialize virtual flash memory chips based on the architecture feature parameters in the first configuration file, so that the virtual flash memory chips can simulate the physical characteristics and behavior of the corresponding model of flash memory chips.

[0043] For example, in some embodiments, the configurable factory bad block characteristic parameters in the second configuration file include the initial bad block rate (initial_bad_blocks_ratio) and the initial bad block distribution pattern (Distribution). The second configuration file is named BadBlock.bin. The configuration information for the factory bad block characteristic parameters in the BadBlock.bin file is as follows: initial_bad_blocks_ratio: 30% Distribution: random Users can define the initial bad block rate and distribution pattern required for this test by modifying the BadBlock.bin file. In the BadBlock.bin file, the initial bad block rate is 30%, and the initial bad block distribution pattern is random. In this embodiment, by setting the initial bad block rate to 30%, the user can make the flash memory simulation platform simulate a real flash memory chip of poor quality. According to the BadBlock.bin file, the flash memory simulation platform randomly selects 30% of the total number of blocks in the physical address space (PBA) of the virtual flash memory chip and marks the status of the selected 30% of blocks as "factory bad blocks". These factory bad blocks will return a failure status for any programming or erasing command in subsequent operations. In addition, configuring the distribution pattern of the factory bad blocks in the physical address space to random distribution in the BadBlock.bin file allows the flash memory simulation platform to simulate randomly distributed bad blocks caused by local wafer defects.

[0044] Step 32: The processor executes the test script, driving the flash memory conversion layer algorithm to run in the test scenario corresponding to the test script.

[0045] In the embodiments of this application, the processor executes a test script, drives the flash conversion layer algorithm to run in the test scenario corresponding to the test script, and the flash conversion layer algorithm sends flash operation instructions to the flash simulation platform. The flash simulation platform responds to the flash operation instructions and simulates the behavior of real flash memory chips through virtual flash memory chips.

[0046] Specifically, in some embodiments, the test scripts include at least one of a basic function test script, a programmable error injection test script, and a late-life test script. Different test scripts correspond to different test scenarios, allowing the processor to drive the flash conversion layer algorithm to run in different test environments. For example, the basic function test script corresponds to a normal test scenario, used to test the performance of the flash conversion layer algorithm under normal test scenarios. The programmable error injection test script corresponds to an abnormal test scenario, used to test the performance of the flash conversion layer algorithm under abnormal test scenarios. The late-life test script corresponds to a late-life test scenario, used to test the performance of the flash conversion layer algorithm under late-life test scenarios.

[0047] Specifically, in some embodiments, step 32 includes: the processor executing the target test script to drive the flash memory conversion layer algorithm to run in the test scenario corresponding to the target test script; wherein, the target test script includes at least one of a basic function test script, a programmable error injection test script, and a late-life test script. In this embodiment, the verification device includes a preset test script library, and the test script library pre-stores basic function test scripts, programmable error injection test scripts, and late-life test scripts. The processor can select at least one script from the basic function test scripts, programmable error injection test scripts, and late-life test scripts stored in the preset test script library as the target test script.

[0048] Please see Figure 4 In some embodiments, when the test script includes a basic function test script, step S32 specifically includes: step S321, the processor executes the basic function test script, driving the flash memory conversion layer algorithm to run in the test scenario corresponding to the basic function test script.

[0049] In the embodiments of this application, the basic function test script is used to perform basic function tests on the flash memory translation layer algorithm, such as at least one of basic read / write / erase tests, aging tests, input / output (I / O) performance tests, and Monkey tests. The basic function test script is used to verify the functional integrity and operational stability of the FTL algorithm under normal application scenarios (such as normal workloads).

[0050] Specifically, basic read / write / erase tests can be basic sequential / random write, read, and erase operation tests; aging tests can be long-term aging tests; I / O performance tests can include performance bandwidth / latency tests. Monkey testing is a random stress testing method that randomly generates read, write, and erase operation instruction sequences for flash memory, and verifies the robustness of the flash memory conversion layer algorithm under irregular, high-intensity random access scenarios, to expose boundary condition anomalies, logic vulnerabilities, and stability issues.

[0051] In some embodiments, the processor executes a basic function test script, generates a first I / O request sequence, and sends the first I / O request sequence to the flash memory translation layer algorithm to drive the flash memory translation layer algorithm to run. For example, the first I / O request sequence may include 4K random write requests, 128K sequential write requests, and mixed read / write requests, etc.; the flash memory translation layer algorithm responds to the first I / O request and generates flash memory operation instructions. For example, the basic function test script can perform a 72-hour aging test, continuously writing data and verifying the correctness of the written data; the continuous data writing is used to continuously consume the erase / write lifespan of the flash memory physical blocks, accelerating the simulation of the wear state after long-term use of flash memory, so that the wear leveling, bad block management, and other mechanisms of the flash memory translation layer can fully operate and expose potential defects; at the same time, the correctness verification of the written data is continuously performed to verify whether the flash memory translation layer algorithm can guarantee that the data is not lost, tampered with, or erroneous under long-term, continuous, and high-intensity read / write operations, ensuring the data reliability and system stability of the flash memory storage system throughout its entire life cycle. In addition, the basic function test script can also run a Monkey test to randomly generate read, write, and erase command sequences. In this embodiment, the processor can verify the functionality and stability of the flash conversion layer algorithm under normal test scenarios by executing a basic function test script.

[0052] In some embodiments, the test script includes a programmable error injection test script, the virtual flash memory chip includes multiple physical blocks, and the first specified physical block is at least one of the multiple physical blocks; step S32 may further include: Step S322: The processor executes the programmable error injection test script, driving the flash memory conversion layer algorithm to run in the test scenario corresponding to the programmable error injection test script.

[0053] In some embodiments, step S322 specifically includes: the processor executing a programmable error injection test script; the processor configuring the state machine of the first specified physical block through the programmable error injection test script to define the exception triggering conditions and the exception behaviors corresponding to the exception triggering conditions of the first specified physical block; driving the flash conversion layer algorithm to run in the test scenario corresponding to the programmable error injection test script through the programmable error injection test script; wherein, the state machine is used to: trigger the first specified physical block to simulate the exception behaviors corresponding to the exception triggering conditions when the first specified physical block meets the exception triggering conditions.

[0054] In some embodiments, the state machine of the first specified physical block is configured by a programmable error injection test script, specifically including: the processor calls the application programming interface (API) of the flash emulation platform through the programmable error injection test script to configure the state machine of the first specified physical block.

[0055] For example, the exception triggering condition for the first specified physical block can be that the number of erases, programs, or reads of the first specified physical block reaches a preset number, or it can be that a specified page of the first specified physical block is read. The exception behavior can be a program failure, an erase failure, a read failure, or a read data bit flipping and generating an ECC error, etc.

[0056] In this embodiment, the processor can actively create abnormal test scenarios by executing a programmable error injection test script to verify whether the FTL's bad block management mechanism can detect, mark, and replace bad blocks in a timely and correct manner, and ensure data reliability.

[0057] For example, in some embodiments, the error injection configuration parameter configuration information and logic are as follows: inject_error_type: BLOCK_READ_FAIL ce:0 lun:0 blockID:1024 pageNum:10 trigger_condition: READ_COUNT == 500 In other words: Error injection type (inject_error_type): configured as block read failure (BLOCK_READ_FAIL); Storage location parameters: channel (ce) configured to 0, logical unit number (lun) configured to 0, physical block identifier (blockID) configured to 1024, page number (pageNum) configured to 10; Trigger condition (trigger_condition): configured as "when the number of reads of physical block with identifier 1024 reaches 500 (rigger_condition: READ_COUNT == 500)". That is, when the number of reads of physical block with identifier 1024 reaches 500, a read failure exception is simulated.

[0058] In this embodiment, when the flash translation layer (FTL) algorithm attempts to perform its 500th read on the physical block identified as 1024, the flash simulation platform returns a failure status instead of a success status. The programmable error injection test script then monitors the FTL algorithm's response, for example, whether it correctly identifies the bad block and bad block page, adds the identified bad block to the bad block table, and migrates the data in the bad block to a spare block. Simultaneously, the protocol monitor monitors whether the FTL algorithm has committed any violations as a result.

[0059] In some embodiments, the test script includes a late-life test script, the virtual flash memory particle includes multiple physical blocks, and the second specified physical block is at least one of the multiple physical blocks; step S32 may further include: Step S323: The processor executes the late-life test script, driving the flash memory conversion layer algorithm to run in the test scenario corresponding to the late-life test script.

[0060] In some embodiments, step S323 specifically includes: the processor executing a late-life test script; setting the number of erases of the second specified physical block recorded on the flash simulation platform side as the target number of erases; setting the number of erases of the second specified physical block recorded on the flash conversion layer algorithm side as the target number of erases through the debugging interface of the flash conversion layer algorithm; and driving the flash conversion layer algorithm to run in the test environment corresponding to the late-life test script; wherein, the target number of erases is used to represent the number of times the second specified physical block is erased in the late life.

[0061] In some embodiments, step S322 specifically includes: the processor executing a late-life test script, calling the API interface of the flash memory simulation platform through the late-life test script, and setting the number of erases of the second specified physical block recorded on the flash memory simulation platform side to the target number of erases through the API interface of the flash memory simulation platform; the processor calling the debugging interface of the flash memory conversion layer algorithm through the late-life test script, and setting the number of erases of the second specified physical block recorded on the flash memory conversion layer algorithm side to the target number of erases through the debugging interface of the flash memory conversion layer algorithm; and driving the flash memory conversion layer algorithm to run in the test environment corresponding to the late-life test script.

[0062] For example, the erase count corresponding to the end of the lifespan of the second specified physical block is 3000. The processor can call the API interface of the flash memory simulation platform by executing the late-life test script, and set the initial value of the erase count of the second instruction physical block to 2990 through the API interface of the flash memory simulation platform. At the same time, the processor can also call the debugging interface of the flash memory conversion layer algorithm (this debugging interface is the API interface provided by the flash memory conversion layer algorithm) by executing the late-life test script, and modify the code of the flash memory conversion layer algorithm firmware through the debugging interface of the flash memory conversion layer algorithm to directly modify the erase count of the second specified physical block in the wear-leveling table maintained by the flash memory conversion layer algorithm to 2990. In this embodiment, the second specified physical block can be multiple physical blocks in the virtual flash memory chip, such as all odd-numbered physical blocks. In this embodiment, by synchronizing the erase counts of the second specified physical block recorded on the flash emulation platform side and the flash conversion layer algorithm side to the same value, it can be ensured that the flash conversion layer algorithm side's perception of the wear level of the second specified physical block is consistent with the physical state of the flash emulation platform side. In this state, the processor starts to perform regular read and write tests to observe whether the FTL garbage collection algorithm will experience a sharp drop in efficiency or fail due to a large number of blocks being in a high wear state, and to verify data integrity.

[0063] Step S33: During the execution of the test script, the processor monitors the flash operation instructions received by the flash simulation platform from the flash conversion layer algorithm, collects the real flash operation data generated by the flash operation instructions executed by the flash simulation platform, and collects the flash operation metadata recorded by the flash conversion layer algorithm that corresponds to the real flash operation data.

[0064] In the embodiments of this application, flash memory operation instructions are the triggering source for generating flash memory operation metadata: flash memory operation instructions are issued to the flash memory simulation platform by the FTL algorithm, instructing the flash memory simulation platform to perform specific flash memory operations such as programming, erasing, reading, and status query; after issuing each flash memory operation instruction, the FTL algorithm synchronously records the operation-related information corresponding to the instruction, and generates and updates the flash memory operation metadata based on this information. If there is no flash memory operation instruction to trigger it, the FTL algorithm will not generate the corresponding flash memory operation metadata, and each valid flash memory operation instruction corresponds to a set of associated flash memory operation metadata.

[0065] Flash operation metadata is a record and description carrier of flash operation instructions: Flash operation metadata does not directly participate in the execution of flash operations. Its core function is to record and describe the relevant information of flash operation instructions issued by the FTL algorithm, including the physical block address corresponding to the instruction, the operation type (programming / erasing / reading), the number of operations (erasing times, reading times, writing times), and the amount of IO data and write amplification factor obtained based on instruction execution statistics. It is the "cognitive record" of the flash operation instructions and corresponding operation behaviors issued by the FTL algorithm itself.

[0066] In some embodiments, the processor monitors flash operation instructions received by the flash emulation platform from the flash translation layer algorithm, including: the processor monitors in real time each flash operation instruction issued by the FTL algorithm to the flash emulation platform; the flash operation instruction includes a command, an address, and data. The processor can monitor the command, address, and data in each flash operation instruction in real time.

[0067] In some embodiments, the processor can acquire real flash memory operation data and flash memory operation metadata in real time. In other embodiments, the processor can also acquire real flash memory operation data and flash memory operation metadata periodically at a preset acquisition frequency; the preset acquisition frequency can be any suitable value, and those skilled in the art can set the value of the preset acquisition frequency according to actual testing needs, so that the current wear state and thermal map of each physical block can be dynamically displayed during the test.

[0068] Specifically, in some embodiments, the processor collects flash operation metadata recorded by the flash conversion layer algorithm that corresponds to the actual flash operation data. This includes the processor collecting flash operation metadata recorded by the flash conversion layer algorithm that corresponds to the actual flash operation data through the debugging interface or internal probe of the flash conversion layer algorithm.

[0069] In some embodiments, the real flash memory operation data collected by the processor from the flash memory emulation platform includes: the number of erases (PE Count), reads (Read Count), and writes (Write Count) for each physical block in the virtual flash memory chip recorded by the flash memory emulation platform, the amount of IO data received from the host, the amount of physical data actually written to the virtual flash memory, the amount of flash memory operation data, and the difference in write amplification factor (WAF) calculated by the flash memory emulation platform. Correspondingly, the flash memory operation metadata collected by the processor from the flash memory conversion layer algorithm includes: the number of erases, reads, and writes for each physical block in the virtual flash memory chip recorded by the flash memory conversion layer algorithm, the amount of IO data received from the host, the amount of physical data actually written to the virtual flash memory, the amount of flash memory operation data, and the difference in write amplification factor (WAF) calculated by the flash memory conversion layer algorithm. Wherein, write amplification factor = amount of physical data actually written to the virtual flash memory / amount of IO data received from the host. The write amplification factor in the real flash memory operation data is calculated by the virtual flash memory platform, while the write amplification factor in the flash memory operation metadata is calculated by the flash memory conversion layer algorithm.

[0070] For example, the flash memory emulation platform internally maintains a counter for all physical blocks. During testing, the counter records the number of erases, reads, and writes for all physical blocks every preset time period (the length of the time period is configurable, such as 10 seconds). Simultaneously, it records the amount of IO data received from the host as the host write data amount = 100GB, i.e., Host_Written_GB = 100, and the actual amount of physical data written to the virtual flash memory as the flash write data amount = 250, i.e., GBNAND_Written_GB = 250. Therefore, the actual WAF is calculated as 250 / 100 = 2.5.

[0071] During testing, the processor uses the debugging interface of the flash translation layer algorithm to read the wear leveling table from the memory corresponding to the FTL at preset time intervals (the length of the time interval is configurable, such as 10 seconds) to obtain the number of erases for each physical block recorded by the FTL. At the same time, it reads the FTL's IO statistics module to obtain the write amplification factor (Reported_WAF) calculated by the FTL, which is 2.3.

[0072] Step S34: Verify the flash conversion layer algorithm based on flash operation instructions, real flash operation data, and flash operation metadata to obtain the verification results.

[0073] Please see Figure 5 In some embodiments, step S34 specifically includes: Step S341: Based on the flash memory operation instructions and the preset flash memory operation protocol monitoring specifications, determine the illegal behaviors in the flash memory operation instructions, evaluate the protocol compliance of the flash memory operation instructions generated by the flash memory conversion layer algorithm based on the illegal behaviors, and obtain the protocol compliance evaluation results. The preset flash memory operation protocol specifications are used to define the illegal operation behavior rules of flash memory operation.

[0074] In some embodiments, prior to step S32, the method further includes: a processor preset flash memory operation protocol monitoring specification, which defines rules for illegal operation behaviors of flash memory operations.

[0075] Specifically, in some embodiments, the illegal operation behavior rules are a collection of all illegal operation behaviors, used to stipulate violations such as prohibiting repeated programming on the same page (Program Without Erase), prohibiting out-of-order programming, and prohibiting reading expired pages, providing a basis for judgment for subsequent real-time monitoring of flash memory operation instructions. The processor defines the illegal operation behavior rules by pre-setting flash memory operation protocol monitoring specifications in order to establish a unified standard for judging the legality of operations. This is used to monitor whether the flash memory operation instructions issued from the flash conversion layer algorithm side to the flash memory simulation platform side comply with the hardware operation constraint specifications of flash memory, in order to verify the correctness and robustness of FTL instruction output.

[0076] In some embodiments, the processor can also load a preset flash memory operation protocol monitoring specification into the protocol monitor. The protocol monitor, acting as a "sniffer," resides on the command channel between the FTL and the flash memory emulation platform. The processor can use the protocol monitor to parse the type and sequence of each flash memory operation command in real time.

[0077] For example, when the protocol monitor detects that the FTL attempts to perform page programming on block 1024 (the previous bad block marked as having failed to erase), it immediately triggers an alarm and records a violation event as follows: [Timestamp] Violation: Programming operation performed on known badblock PBA 1024, that is, [TIMESTAMP]Violation: PROGRAM on known badblock PBA 1024.

[0078] For example, in some embodiments, the preset flash memory operation protocol monitoring specification can be the ONFI protocol specification. The processor can load the ONFI protocol specification corresponding to the model of the real flash memory chip to be simulated in the flash memory simulation platform. The protocol monitor is preset to monitor the following illegal operations: (1) duplicate programming: executing page programming commands twice consecutively on the same physical page (PBA) without executing a block erase command in between; (2) reverse programming: programming the higher page address (e.g., Page 100) first and then programming the lower page address (e.g., Page 99) within the same physical block; (3) illegal address access: issuing an address value that exceeds the physical address range of the flash memory chip of that model.

[0079] In some embodiments, step S341 specifically includes: the processor comparing the flash memory operation instructions with the preset flash memory operation protocol monitoring specifications to monitor whether the flash memory operation instructions include illegal behavior; if the flash memory operation instructions do include illegal behavior, then the illegal behavior is reported in real time and the violation context information of the illegal behavior is recorded; and a protocol compliance assessment result is generated based on the violation context information.

[0080] Specifically, in some embodiments, the violation context information includes the type of violation, the time of occurrence, and the operation context. Protocol compliance monitoring results include the violation context information.

[0081] In some embodiments, the flash operation instructions received by the flash emulation platform from the flash conversion layer algorithm include: operation actions, operation order, and operation modes on each physical block in the virtual flash memory particle, and on each physical page in each physical block. The processor monitors the flash operation instructions received by the flash emulation platform from the flash conversion layer algorithm, specifically including: the processor monitors in real time the operation actions, operation order, and operation modes on each physical block in the virtual flash memory particle, and on each physical page in each physical block of each physical block in each flash operation instruction. The processor compares the flash operation instructions with a preset flash operation protocol monitoring specification to monitor whether the flash operation instructions include illegal behavior, specifically including: the processor compares the operation actions, operation order, and operation modes on each physical block and each physical page in the virtual flash memory particle in each flash operation instruction with the preset flash operation protocol monitoring specification to monitor whether the flash operation instructions include illegal behavior.

[0082] In some embodiments, if it is determined that the monitored flash memory operation instructions include one or more illegal behaviors such as reprogramming any physical block and reversing the programming of any physical block, the processor can report one or more illegal behaviors in real time and record violation context information.

[0083] In some embodiments, the processor can capture and parse each flash operation instruction (e.g., command type and operation sequence) sent by FTL to the flash emulation platform in real time, compare each flash operation instruction with the preset flash operation protocol monitoring specifications line by line, and immediately record the violation type and trigger an error once any violation operation (e.g., an attempt to repeatedly program a page) is detected; at the same time, the verification process can be configured to continue execution or be paused.

[0084] Step S342: The processor calculates the difference between the actual flash memory operation data and the corresponding flash memory operation metadata, evaluates the accuracy of the flash memory operation metadata based on the difference, and obtains the metadata accuracy evaluation result.

[0085] Specifically, in some embodiments, the data types of the real flash memory operation data and the corresponding flash memory operation metadata are the same, but the data sizes may be different. The data types of the real flash memory operation data and the corresponding flash memory operation metadata include: the number of erases (PECount), reads (Read Count), and writes (Write Count) of each physical block in the virtual flash memory chip, the amount of IO data received from the host, the amount of physical data actually written to the virtual flash memory, the amount of flash memory operation data, and the write amplification factor (WAF).

[0086] In some embodiments, the processor calculates the difference between real flash memory operation data and the corresponding flash memory operation metadata, and evaluates the accuracy of the flash memory operation metadata based on the difference. Specifically, the processor verifies the accuracy of the flash memory operation metadata recorded by the flash conversion layer algorithm based on the differences between the number of erases, reads, and writes of each physical block in the virtual flash memory chip recorded by the flash simulation platform side and the flash conversion layer algorithm side, respectively, the amount of IO data received from the host, the amount of physical data actually written to the virtual flash memory, the amount of flash memory operation data, and the write amplification factor (WAF).

[0087] In some embodiments, the processor evaluates the accuracy of flash memory operation metadata based on the difference, specifically including: the processor determining the number of physical blocks where there are differences between the real flash memory operation data and the flash memory operation metadata corresponding to the real flash memory operation data, and the proportion of these differing physical blocks in all physical blocks of the virtual flash memory particle, thereby evaluating the accuracy of the flash memory operation metadata.

[0088] For example, in some embodiments, the processor executes an automated script to compare the physical block erase count tables recorded by the flash emulation platform and the flash conversion layer algorithm, respectively. It finds that for block 505, the erase count recorded by the flash emulation platform is PE1=1500, while the erase count recorded by the flash conversion layer algorithm is PE2=1498, with an absolute difference of 2 between PE1 and PE2. Statistical analysis shows that for 98% of physical blocks, the difference between PE1 and PE2 is within ±5, indicating that the processor determines the accuracy of the flash operation metadata recorded by the flash conversion layer algorithm to be good.

[0089] Additionally, the processor can compare the WAF values ​​calculated by the flash emulation platform and the flash conversion layer algorithm, respectively. If the write amplification factor WAF1 calculated by the flash emulation platform is 2.5, and the WAF2 calculated by the flash conversion layer algorithm is 2.3, then there is a difference between WAF1 and WAF2, indicating that there is an error in the FTL's WAF statistics module.

[0090] Step S343: The processor verifies the wear leveling performance of the flash conversion layer algorithm based on the number of erases of all physical blocks in the flash memory operation metadata, and obtains the wear leveling performance evaluation result.

[0091] In this embodiment, the processor analyzes the distribution trend of the number of erases of all physical blocks based on the number of erases in the flash memory operation metadata, and generates a dynamically updated wear heatmap to intuitively evaluate the effectiveness of the wear leveling algorithm and obtain the wear leveling performance evaluation result; wherein, the distribution trend includes variance, extreme values ​​(maximum and minimum values), range and distribution pattern, etc.

[0092] For example, the processor can read the number of erases for all physical blocks, generate a two-dimensional wear heatmap based on the number of erases for all physical blocks, and display the wear heatmap on the screen to show the wear level of all physical blocks. If the wear heatmap image has uniform color, it indicates that the wear leveling flash conversion layer algorithm is effective; if the wear heatmap shows obvious bright spots (high wear) or dark spots (low wear), it indicates that the flash conversion layer algorithm needs to be optimized.

[0093] Step S344: The processor verifies the bad block management capability of the flash conversion layer algorithm based on the bad block list in the real flash operation data and the bad block list in the flash operation metadata, and obtains the bad block management capability evaluation result.

[0094] In this embodiment, the processor can verify whether the FTL can detect and isolate bad blocks in a timely and accurate manner, and whether there are any missed or false alarms, by comparing the bad block list in the real flash memory operation data with the bad block list in the flash memory operation metadata.

[0095] For example, the processor can compare the bad block list in the real flash memory operation data with the bad block list in the flash memory operation metadata. If the bad block list in the real flash memory operation data records bad blocks including blocks 1024 and 2048, while the bad block list in the flash memory operation metadata records bad blocks including only block 1024 and not block 2048, then it is determined that the flash conversion layer algorithm has missed reporting block 2048, and that the bad block management of the flash conversion layer algorithm has a defect.

[0096] In some embodiments, after step S34, the method further includes: generating a comprehensive verification report of the flash memory conversion layer algorithm based on the verification results.

[0097] In some embodiments, after step S34, the method further includes: generating a visualization chart in real time based on the verification results during the execution of the test script; wherein the visualization chart includes a wear heat map of each physical block in the current wear state, a write magnification factor trend chart, and an operation number distribution comparison chart.

[0098] In this embodiment, the processor can automatically generate a comprehensive verification report of the FTL algorithm based on the verification results. This comprehensive verification report includes an FTL algorithm verification report encompassing data recording accuracy assessment, wear heatmap, and bad block management capability analysis. The report not only includes traditional test pass / fail conclusions, but more importantly, it provides quantitative and visualized in-depth analysis results such as data recording accuracy scores, wear heatmaps, bad block management capability analysis, WAF consistency analysis, and protocol violation lists. Based on this comprehensive verification report, the processor can also output a final verification conclusion on the overall reliability and stability of the tested FTL algorithm.

[0099] In some embodiments, a comprehensive verification report for the flash conversion layer algorithm is generated based on the verification results. This includes automatically summarizing all verification results and generating a structured comprehensive verification report, which can be in JSON, XML, or PDF format. The comprehensive verification report includes the following sections: execution summary, protocol compliance violation list, metadata accuracy statistics table, wear heatmap, bad block list comparison results, WAF difference analysis, etc. Then, based on preset pass criteria (such as no serious Protocol Violation, metadata error rate <1%), the test conclusion is output: FAIL (reasons: bad block underreporting, WAF statistical errors), and a detailed list of various failure evidences is provided. For example, all violation events recorded by the protocol monitor can be summarized and analyzed to generate a protocol compliance report.

[0100] The verification method for the flash memory translation layer algorithm provided in this application helps to solve the problems of long cycle, high cost, insufficient coverage, and inability to quantitatively evaluate existing FTL testing methods. The method includes: configuring flash memory characteristic parameters for the flash memory simulation platform, preset physical block erase counts and original bad block distribution; executing test scripts and dynamically injecting programming failure, erase failure, and read failure errors; synchronously collecting the actual physical block operation mode, write / read / erase data volume, and write / read / erase counts recorded by the flash memory simulation platform and their corresponding data values ​​recorded internally by the FTL; comparing and analyzing bidirectional data from the flash memory simulation platform and the FTL algorithm side to generate a wear heatmap and verification report; and monitoring in real time whether the FTL operation commands conform to the preset flash memory operation protocol monitoring specifications. This application's embodiments simulate the factory quality of different flash memory chips by directly modifying block attributes, simulate extreme scenarios such as the end of the lifespan by directly modifying block wear values, verify the accuracy and reliability of FTL bad block management by dynamically injecting programming failure, erase failure, and read failure errors through scripts, quantitatively evaluate the accuracy of FTL wear leveling and read interference through bidirectional data comparison, assess the reliability and validity of FTL internal recorded data, and monitor and verify the compliance of FTL flash memory operation methods through protocol specifications, greatly shortening test time and improving test coverage and reliability.

[0101] Compared with the prior art, the embodiments of this application have the following beneficial effects: (1) Greatly improve testing efficiency and economy: By using the technology of "directly modifying the initial value of PE and synchronizing it to FTL metadata", the life test that takes several months can be shortened to a few hours, saving a lot of hardware costs and time costs, and accelerating the R&D iteration. (2) Achieve ultimate controllability and ultra-high coverage of testing: By using the technology of "programmable error injection" and "configurable bad block distribution", any test scenario can be constructed actively, accurately and repeatably, achieving systematic coverage of various extreme and boundary conditions, and the sufficiency of testing far exceeds that of traditional methods. (3) By using the technology of "two-way data synchronous acquisition and comparison", the accuracy of the internal metadata management of the FTL algorithm is objectively and quantitatively evaluated for the first time based on the real data of the platform, making the test results more convincing. (4) Enhance deep observability and problem location capabilities: By generating real-time wear heat maps, operation number distribution comparison maps and other visualization tools, developers are provided with the ability to deeply understand the internal behavior of the algorithm, which greatly facilitates performance bottleneck analysis and defect location. (5) Preventing risks and improving final product reliability: Through the "real-time protocol compliance monitoring" technology, operations that violate NAND physical specifications can be detected in the earliest algorithm development stage, fundamentally preventing potential data corruption or hardware failures caused by such problems, and significantly improving the quality and reliability of the product upon delivery. (6) Forming a systematic verification methodology: This invention provides a complete, systematic, and automated FTL verification process and platform solution, which has high versatility and scalability and is suitable for FTL algorithm testing of various architectures and strategies.

[0102] For example, Figure 6 The document presents schematic diagrams of the hardware structure of the verification device provided in some embodiments of this application. For example... Figure 6 As shown, the controller 700 includes: One or more processors 710 and memory 720, Figure 6 Take the 710 processor as an example.

[0103] The processor 710 and memory 720 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0104] The memory 720, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the methods in the embodiments of this application. The processor 710 executes various functional applications and data processing of the device by running the non-volatile software programs, instructions, and modules stored in the memory 720, thereby implementing the methods in the above-described method embodiments.

[0105] The memory 720 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory 720 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 720 may optionally include memory remotely located relative to the processor 710. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0106] The one or more modules are stored in the memory 720. When executed by the one or more processors 710, they perform the methods in any of the above method embodiments, for example, the methods described above. Figure 3 Method steps S31-S34, Figure 4 Method steps S321-S323, Figure 5 The method steps S341-S344 are described in the text.

[0107] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0108] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 710 can cause the one or more processors to perform the methods in any of the above method embodiments, for example, to perform the methods described above. Figure 3 Method steps S31-S34, Figure 4 Method steps S321-S323, Figure 5 The method steps S341-S344 are described in the text.

[0109] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0110] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0111] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; under the concept of the present invention, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the present invention as described above, which are not provided in detail for the sake of brevity; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for verifying a flash memory conversion layer algorithm, applied to a verification device, characterized in that, The verification device is equipped with a flash memory simulation platform, which has configurable flash memory characteristic parameters and is configured to receive and execute flash memory operation instructions from the flash memory conversion layer algorithm. The method includes: Configure the flash memory characteristic parameters of the real flash memory chip to be simulated for the flash memory simulation platform to generate a virtual flash memory chip corresponding to the real flash memory chip; Execute the test script to drive the flash conversion layer algorithm to run in the test scenario corresponding to the test script; During the execution of the test script, the flash operation instructions received by the flash simulation platform from the flash conversion layer algorithm are monitored, the real flash operation data generated by the flash simulation platform in executing the flash operation instructions is collected, and the flash operation metadata corresponding to the real flash operation data is collected by the flash conversion layer algorithm. The flash memory conversion layer algorithm is verified based on the flash memory operation instructions, the actual flash memory operation data, and the flash memory operation metadata, and the verification results are obtained.

2. The method according to claim 1, characterized in that, The flash memory characteristic parameters include architectural characteristic parameters, which are used to simulate the hierarchical storage architecture of the actual flash memory chips; and / or, The flash memory characteristic parameters include factory bad block characteristic parameters, which are used to simulate the number of factory bad blocks and the distribution pattern of factory bad blocks in the physical address space of the real flash memory chip.

3. The method according to claim 1, characterized in that, The step of configuring the flash memory characteristic parameters of the real flash memory chips to be simulated for the flash memory simulation platform includes: Obtain a parameter configuration file, which has configurable flash memory characteristic parameters; The flash memory characteristic parameters of the real flash memory chip to be simulated are obtained based on the parameter configuration file, and the flash memory characteristic parameters of the real flash memory chip to be simulated are configured for the flash memory simulation platform.

4. The method according to claim 1, characterized in that, The test scripts include at least one of the following: basic function test scripts, programmable error injection test scripts, and late-life test scripts.

5. The method according to claim 1, characterized in that, The test scripts include basic function test scripts; The execution of the test script drives the flash memory conversion layer algorithm to run in the test scenario corresponding to the test script, including: Execute the basic function test script to drive the flash conversion layer algorithm to run in the test scenario corresponding to the basic function test script; The basic function test script is used to perform basic function tests on the flash memory conversion layer algorithm. The basic function tests include at least one of the following: basic read / write / erase test, aging test, input / output performance test, and Monkey test.

6. The method according to claim 1, characterized in that, The test script includes a programmable error injection test script, and the virtual flash memory chip includes multiple physical blocks, with the first designated physical block being at least one of the multiple physical blocks. The execution of the test script drives the flash memory conversion layer algorithm to run in the test scenario corresponding to the test script, including: Execute the programmable error injection test script; The programmable error injection test script is used to configure the state machine of the first specified physical block to define the exception triggering conditions of the first specified physical block and the exception behavior corresponding to the exception triggering conditions. The drive flash conversion layer algorithm runs in the test scenario corresponding to the programmable error injection test script; The state machine is used to: trigger the first designated physical block to simulate abnormal behavior corresponding to the abnormal trigger condition when the first designated physical block satisfies the abnormal trigger condition.

7. The method according to claim 1, characterized in that, The test script includes a late-life test script, and the virtual flash memory particle includes multiple physical blocks, with the second designated physical block being at least one of the multiple physical blocks. The execution of the test script drives the flash memory conversion layer algorithm to run in the test scenario corresponding to the test script, including: Execute the late-life test script; Set the number of erases of the second specified physical block recorded on the flash emulation platform side as the target number of erases; Through the debugging interface of the flash conversion layer algorithm, the number of erases of the second specified physical block recorded on the side of the flash conversion layer algorithm is set as the target number of erases; The drive flash conversion layer algorithm runs in the test environment corresponding to the late-life test script; The target erase count is used to represent the number of times the second specified physical block is erased in the later stages of its life.

8. The method according to any one of claims 1-7, characterized in that, The verification of the flash conversion layer algorithm based on the flash memory operation instructions, the actual flash memory operation data, and the flash memory operation metadata includes: Based on the flash memory operation instructions and the preset flash memory operation protocol monitoring specifications, illegal behaviors in the flash memory operation instructions are determined. Based on the illegal behaviors, the protocol compliance of the flash memory operation instructions generated by the flash memory conversion layer algorithm is evaluated to obtain the protocol compliance evaluation result. The preset flash memory operation protocol specifications are used to define the illegal operation behavior rules for flash memory operations. Calculate the difference between the actual flash memory operation data and the flash memory operation metadata corresponding to the actual flash memory operation data, evaluate the accuracy of the flash memory operation metadata based on the difference, and obtain the metadata accuracy evaluation result; The wear leveling performance of the flash conversion layer algorithm is evaluated based on the number of erases of all physical blocks in the flash memory operation metadata, and the wear leveling performance evaluation result is obtained. The bad block management capability of the flash conversion layer algorithm is evaluated based on the bad block list in the real flash operation data and the bad block list in the flash operation metadata, and the bad block management capability evaluation result is obtained.

9. The method according to claim 8, characterized in that, Based on the flash memory operation instructions and the preset flash memory operation protocol monitoring specifications, illegal behaviors in the flash memory operation instructions are determined. Based on these illegal behaviors, the protocol compliance of the flash memory operation instructions generated by the flash memory conversion layer algorithm is evaluated to obtain a protocol compliance evaluation result, including: The flash memory operation instructions are compared with the preset flash memory operation protocol monitoring specifications to monitor whether the flash memory operation instructions include illegal behavior; If the flash memory operation instruction contains illegal behavior, then the illegal behavior will be reported in real time and the violation context information will be recorded. The protocol compliance of the flash memory operation instructions generated by the flash memory conversion layer algorithm is evaluated based on the violation context information to obtain the protocol compliance evaluation result.

10. The method according to claim 8, characterized in that, The method further includes: During the execution of the test script, a visual chart is generated in real time based on the verification results; The visualization charts include a wear heatmap of each physical block in its current wear state, a write magnification factor trend chart, and a comparison chart of operation count distribution.

11. A verification device, characterized in that, The verification equipment includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-10.

12. A non-volatile computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when executed, enable the execution of the method as described in any one of claims 1-10.

Images