Flash memory controller prototype firmware, prototype verification method, system and hardware platform

Abstract

The present application relates to the field of storage technology, and discloses a flash memory controller prototype firmware, a prototype verification method, a system and a hardware platform. The firmware comprises a serial port interface module, a test instruction parsing module, a test control module and a flash memory control interface module. The serial port interface module is used to connect to a test host end, and the flash memory control interface module is used to connect to a flash memory; the serial port interface module is used to receive and verify corresponding request instructions issued by the test host end, and extract request instructions that have been successfully verified; the test instruction parsing module is used to perform instruction parsing and legality check on request instructions that have been successfully verified, so as to extract legal request instructions; the test control module is used to perform test execution on the flash memory connected to the flash memory control interface module according to the legal request instructions and obtain execution results; the test instruction parsing module is also used to return the execution results after processing according to a preset test interface protocol, so as to realize prototype verification of the flash memory controller.

Description

Technical Field

[0001] The present application relates to the field of storage testing technology, and in particular to a flash memory controller prototype firmware, a prototype verification method, a system and a hardware platform. Background Art

[0002] For flash-based storage products, such as EMMC (Embedded MultiMedia Card), UFS (Universal Flash Storage) embedded storage chips and SSD (Solid State Disk), the storage master chip is the main component that determines the competitiveness of storage products. There are two main parts that directly process storage business inside the storage master chip: the host storage protocol processor and the flash controller. Among them, the host storage protocol processor mainly completes the processing of standard storage protocols, such as EMMC, UFS, PCIE and other standard protocols. The flash controller is responsible for flash control and completes the function of data access. Because the host storage protocols are all standard protocols, most of the industry is based on existing IP development. Since the operation delay and data storage capacity of flash memory have a great impact on the main functions and performance indicators of the final flash storage product, in addition to implementing the standard flash control interface, the flash control will also implement more complex functions that are conducive to improving storage performance and reliability, such as flash IO scheduling, end-to-end protection, high error correction and low latency LDPC, etc. The addition of these functions will make the flash controller complex. How to ensure the verification quality of the flash controller during the storage controller chip development stage has become a difficult challenge.

[0003] During the development phase of storage controller chips, prototype verification is an important part of ensuring the correctness of chip functions. Currently, the following problems are common in prototype verification of flash memory controllers inside storage controller chips:

[0004] First, the unit test (UT) for single-point functions is relatively simple and has low coverage.

[0005] Second, IT is carried out through end-to-end system testing to cover the parts that UT cannot cover. This method has a long end-to-end request processing path, including host-side processing, storage master front-end protocol processing, storage master internal firmware processing and flash controller. Therefore, not only is the verification efficiency low, but the coverage cannot meet the complex flash controller verification requirements. For example, because the processing path is too long, it is almost impossible to fully pressurize the flash controller's working pressure, and it is also difficult to accurately construct the flash controller's workload (or conditions).

[0006] Third, the automation level is not high enough, and most operations are done manually. Because of the low automation level, precious chip R&D time cannot be effectively utilized. Summary of the invention

[0007] In view of this, in order to solve at least one of the above problems, the present application provides a flash memory controller prototype firmware, a prototype verification method, a system and a hardware platform.

[0008] In a first aspect, an embodiment of the present application provides a flash memory controller prototype firmware, including:

[0009] A serial port interface module, a test instruction parsing module, a test control module and a flash memory control interface module connected in sequence, wherein the serial port interface module is also used to connect to the test host end, and the flash memory control interface module is used to connect to the flash memory;

[0010] The serial port interface module is used to receive and verify the corresponding request instructions sent by the test host after being processed according to the preset test interface protocol, and extract the request instructions that have been successfully verified;

[0011] The test instruction parsing module is used to perform instruction parsing and legality check on the successfully verified request instruction to extract a legal request instruction;

[0012] The test control module is used to test and execute the flash memory connected to the flash memory control interface module according to the legal request instruction, and obtain the execution result;

[0013] The test instruction parsing module is also used to process the execution result according to the preset test interface protocol and return it to the test host end through the serial port interface module.

[0014] In some embodiments, the test control module includes a test configuration unit, a test load generation unit, a test thread scheduling unit, and a test monitoring unit;

[0015] The test configuration unit is used for configuring the test related information according to the configuration request when the legal request instruction is a configuration request;

[0016] The test load generating unit is used for generating a corresponding test load according to the test request when the legal request instruction is a test request;

[0017] The test thread scheduling unit is used to schedule the test threads according to the selected scheduling mode after the test load is generated, so that each test thread runs the corresponding test load;

[0018] The test monitoring unit is used to collect test status information during the test execution process; wherein the test status information is used for the test host to query the test status.

[0019] In some embodiments, each of the test requests includes at least: a specified flash memory storage page range, a flash memory IO type and size, an IO operation type, a data model, and a flash memory IO ratio.

[0020] In some embodiments, each of the test requests is executed by only one test thread, and one test thread is used to mount one or more of the test requests that need to be executed.

[0021] In some embodiments, the test load generating unit generates a corresponding test load according to the test request, including:

[0022] Describing the storage block information contained in all channels and all storage areas in the flash memory to obtain a storage block matrix;

[0023] According to the storage page range specified in the test request, determine and generate a test group from the storage block matrix, wherein the test group includes address information of each storage page to be operated;

[0024] Determine an operation address of a flash memory IO operation from the test group according to the flash memory IO type and size specified in the test request; wherein the flash memory IO type is sequential or random;

[0025] Generate test data written into a corresponding storage page in the flash memory and / or generate expected data according to the IO operation type and data model specified in the test request, wherein the expected data is used to compare with actual data read from the corresponding storage page in the flash memory;

[0026] According to the flash memory IO ratio specified in the test request, the IO ratio sent to the flash memory is controlled; wherein the IO ratio includes the ratio of write and read operations, the ratio of sequential and random operations, and the ratio of different IO sizes.

[0027] In some embodiments, generating test data to be written into a corresponding storage page in the flash memory and / or generating expected data according to the IO operation type and data model specified in the test request includes:

[0028] When the IO operation type is a write IO operation, generating test data to be written into a corresponding storage page in the flash memory according to a write data model specified in the test request;

[0029] When the IO operation type is a read IO operation, expected data for checking data consistency is generated according to a read data model specified in the test request.

[0030] In some embodiments, each of the test requests further includes an error injection read instruction and a specified flash memory IO; when the test load generating unit generates a corresponding test load according to the test request, it further includes:

[0031] The test load generation unit marks the specified flash memory IO when detecting the presence of the error injection read instruction in the test request; wherein the mark is used to indicate that error injection is performed when the specified flash memory IO is called.

[0032] In some embodiments, the preset test interface protocol includes a command format description, and the test host generates the corresponding request instruction issued according to the command format description;

[0033] The command format description includes: a command header, command data and command verification data, wherein the command header is used to indicate the specific type and command length of the current command, and the command verification data is calculated based on the command header and the command data.

[0034] In some embodiments, the preset test interface protocol further includes a response format description, and the test instruction parsing module processes the execution result according to the response format description;

[0035] The response format description includes: a response header, response data and response verification data. The response header is used to record the specific type of the corresponding command and the execution result type of the corresponding command. The response verification data is calculated based on the response header and the response data.

[0036] In a second aspect, an embodiment of the present application provides a flash memory controller prototype verification system, including: a test host end and an FPGA prototype verification hardware platform, wherein the FPGA prototype verification hardware platform is connected to the test host end via a serial port and is also used to connect to a flash memory;

[0037] The test host is used to receive the test script and command input by the user, and send corresponding request instructions to the FPGA prototype verification hardware platform according to the test script and command;

[0038] The FPGA prototype verification hardware platform is used to load and run the flash memory controller prototype firmware to achieve automated testing of the flash memory.

[0039] In some embodiments, the test host terminal includes a host terminal, and a Jenkins test tool or a test terminal;

[0040] The host terminal is used to receive control commands input by the user through the Jenkins test tool or the test terminal to control the execution of the test scripts and commands.

[0041] In a third aspect, an embodiment of the present application provides an FPGA prototype verification hardware platform, wherein the FPGA in the FPGA prototype verification hardware platform is loaded with the flash memory controller prototype firmware.

[0042] In a fourth aspect, an embodiment of the present application provides a flash memory controller prototype verification method, which is applied to a flash memory controller prototype verification system. The system includes a test host and an FPGA prototype verification hardware platform. The FPGA prototype verification hardware platform is used to execute the flash memory controller prototype verification method, including:

[0043] Receive and verify the corresponding request instructions sent by the test host end after being processed according to the preset test interface protocol through the serial port interface module, and extract the request instructions that have been successfully verified;

[0044] The successfully verified request instruction is parsed and checked for legality by a test instruction parsing module to extract a legal request instruction;

[0045] The test control module performs a test on the flash memory connected to the flash memory control interface module according to the legal request instruction, and obtains an execution result;

[0046] The execution result is processed by the test instruction parsing module according to the preset test interface protocol and returned to the test host end through the serial port interface module.

[0047] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium for storing the above-mentioned flash memory controller prototype firmware.

[0048] The embodiments of the present application have the following beneficial effects:

[0049] The present application proposes a flash memory controller prototype firmware, which includes a serial port interface module, a test instruction parsing module, a test control module and a flash memory control interface module, wherein the serial port interface module is used to receive and verify the corresponding request instruction issued by the test host end after processing according to the preset test interface protocol; the test instruction parsing module is used to parse and check the legality of the request instruction that has been successfully verified; the test control module is used to test and execute the flash memory connected to the flash memory control interface module according to the legal request instruction, and obtain the execution result; finally, the test instruction parsing module is also used to process the execution result according to the preset test interface protocol and return it to the test host end. The prototype firmware is loaded and run through the hardware platform, and can accurately generate various complex test loads, etc., so as to meet the verification requirements of the complex flash memory controller in the prototype verification stage. Compared with the currently commonly used method, while improving the verification efficiency, it also improves the verification coverage, and can simulate the workload of the flash memory controller under high pressure in the actual user usage scenario. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0051] Figure 1 A schematic diagram of a flash memory controller prototype verification system according to an embodiment of the present application is shown;

[0052] Figure 2 A schematic diagram of the structure of the prototype firmware of the flash memory controller according to an embodiment of the present application is shown;

[0053] Figure 3 A schematic diagram of the verification process of the flash memory controller prototype firmware according to an embodiment of the present application is shown;

[0054] Figure 4 A schematic diagram showing a command format description of a test interface protocol in an embodiment of the present application is shown;

[0055] Figure 5 A schematic diagram showing a response format description of a test interface protocol in an embodiment of the present application is shown;

[0056] Figure 6 A schematic diagram of the process of generating a test load in an embodiment of the present application is shown;

[0057] Figure 7 A schematic diagram showing a test request specifying a storage page range according to an embodiment of the present application is shown;

[0058] Figure 8 A schematic diagram of the structure of the FPGA prototype verification hardware platform of an embodiment of the present application is shown.

[0059] Description of main component symbols:

[0060] 10-test host side; 20-test device side; 100-FPGA prototype verification hardware platform;

[0061] 110 - serial port interface module; 120 - test instruction parsing module; 130 - test control module; 140 - flash memory control interface module; 210 - test configuration unit; 220 - test load generation unit; 230 - test thread scheduling unit; 240 - test monitoring unit. DETAILED DESCRIPTION

[0062] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments.

[0063] The components of the embodiments of the present application generally described and shown in the drawings herein may be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0064] Hereinafter, the terms "including", "having" and their cognates that can be used in various embodiments of the present application are intended only to indicate specific features, numbers, steps, operations, elements, components or a combination of the foregoing items, and should not be understood as first excluding the existence of one or more other features, numbers, steps, operations, elements, components or a combination of the foregoing items or increasing the possibility of one or more features, numbers, steps, operations, elements, components or a combination of the foregoing items. In addition, the terms "first", "second", "third" and the like are only used to distinguish descriptions and cannot be understood as indicating or implying relative importance.

[0065] Unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meanings as those generally understood by those skilled in the art to which the various embodiments of the present application belong. The terms (such as those defined in generally used dictionaries) will be interpreted as having the same meanings as the contextual meanings in the relevant technical field and will not be interpreted as having idealized meanings or overly formal meanings unless clearly defined in the various embodiments of the present application.

[0066] In conjunction with the accompanying drawings, some embodiments of the present application are described in detail below. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0067] Since the current prototype verification of flash memory controllers has problems such as low coverage, low automation, and low test efficiency, this application proposes a complete test system that can realize the prototype verification of flash memory controllers and a prototype firmware loaded and run based on an FPGA hardware platform, wherein the prototype firmware has multiple functions of a flash memory controller, including the ability to generate and execute flash memory test loads, support multi-threaded testing, support for flash memory controller-related error injection, etc. In addition, users can input various test requirements, such as test scripts, test instructions, etc., through the host-side terminal of the test system, thereby realizing the automated operation of the prototype verification of the flash memory controller.

[0068] The flash memory controller prototype firmware and the flash memory controller prototype verification system are described below in conjunction with some specific embodiments.

[0069] Exemplarily, the flash controller prototype firmware (also called NFC Test FW) runs on a hardware platform such as FPGA, SOC, etc., and forms a whole test system with the test host side and the flash memory under test. Taking the FPGA-based prototype verification platform (referred to as FPGA prototype verification hardware platform 100) as an example, Figure 1 A schematic diagram of the flash controller prototype firmware of the present application being applied to a test system is shown. For the test host end 10, it may include a host terminal, and a Jenkins-based test tool (or a Jenkins integrated test system) and / or a test terminal, etc.; for the test device end 20, it mainly includes an FPGA prototype verification hardware platform 100 and the flash memory under test.

[0070] Among them, the above-mentioned host terminal is mainly used to run test scripts and commands, which can interact with the FPGA prototype verification hardware platform 100 through a serial port (such as UART, etc.). It can be understood that the host terminal has two working modes: one is that the tester controls the execution of test scripts and commands through the test terminal; the other is to control the execution of test scripts and commands on the host terminal through the network interface through the Jenkins test tool. For the latter, the tester can also complete the automated testing of prototype verification and the processing of its test data through the Jenkins test tool, such as generating a test report, completing the archiving of test result data and test logs, etc. The NFC Test FW running on the FPGA is used to implement specific testing of the flash memory controller, and is also the core of the entire test system. The flash memory is used to connect to the FPGA prototype verification hardware platform 100 through the flash memory control interface to achieve access to the flash memory.

[0071] Next, the flash memory controller prototype firmware designed by this application is described in detail.

[0072] For example, Figure 2 As shown, the prototype firmware of the flash controller includes a serial port interface module 110, a test instruction parsing module 120, a test control module 130 and a flash control interface module 140 which are connected in sequence, wherein the serial port interface module 110 is also used to connect to the test host end 10, and the flash control interface module 140 is also used to connect to the flash memory. It can be understood that the function of the flash controller can be realized through the cooperation of the four modules. It should be noted that the serial port receiving module and the flash control interface module 140 in the firmware mainly refer to the serial port / interface driver at the software level.

[0073] like Figure 3 As shown, to achieve prototype verification of the flash controller, the flash controller prototype firmware will perform the following steps:

[0074] S110, the serial port interface module 110 receives and verifies the corresponding request instruction issued by the test host end 10 and processed according to the preset test interface protocol, and extracts the request instruction that has been successfully verified.

[0075] Exemplarily, when starting the flash controller prototype verification, the serial port interface module 110 can connect to the test host end 10 through the serial port to receive the corresponding request instruction issued by the test host end 10; then, the request instruction is verified to determine whether the instruction is correct or not tampered with, etc. Then, the request instruction that passes the verification is extracted and sent to the test instruction parsing module 120 for instruction parsing.

[0076] It is worth noting that in order to achieve efficient interaction between the host side and the device side in this application, this application will complete the interaction between the test host side and the FPGA prototype verification hardware platform 100 based on a set of customized test interface protocols. Among them, the test host side 10 is used as the master object (Host), and the FPGA prototype verification hardware platform 100 running the prototype firmware and the flash memory are used as the slave object (Device). The communication process between the two can adopt a master-slave communication mode of one question and one answer.

[0077] Considering the specific test requirements, the test interface does not need to implement a large amount of data interaction, but only needs to implement some communication functions of test control information and status information. Specifically, the above test interface protocol is divided into a CMD part and a Response part. In form, the test host end 10 will construct a request instruction (CMD) according to the requirements, and then send it to the FPGA prototype verification hardware platform 100 through the serial port. The FPGA prototype verification hardware platform 100 also constructs the corresponding Response information in the format of Response and sends it to the test host end 10 through the serial port. It can be understood that the Response information refers to the return data corresponding to the current request instruction (CMD). Therefore, after the test host end 10 initiates a command to the FPGA prototype verification hardware platform 100, it will poll to obtain the return data of the serial port, and after receiving the return data, it will parse the value returned by the FPGA prototype verification hardware platform 100 in the format of Response, thereby obtaining the execution result of the instruction. Optionally, if the request instruction returns a non-successful state, the test host end 10 can initiate a retry process.

[0078] In one embodiment, the test interface protocol includes a command format description content (ie, CMD part). Figure 4 As shown, the command format description includes: command header (Cmd Head), command data (Cmd Data) and command check data (command CRC), wherein Cmd Head is used to indicate the specific type and command length of the current command, which consists of two parts, namely, command code (OP Code) and command length (Cmd Len). Specifically, OP Code indicates what kind of command the current command is, for example, Host tells FPGA prototype verification hardware platform 100 that the command is a test configuration command through OP Code value A. Cmd Len indicates how large the data carried by the request command is. Usually, the length of the entire CmdHead is 4Bytes, of which Cmd Len occupies 1Byte. The typical length of Cmd Data is generally 8Bytes. The command CRC field generally occupies 2Bytes, and the command CRC is mainly used for data verification, which can be obtained by calculation based on the values ​​of Cmd Head and Cmd Data.

[0079] Furthermore, the preset test interface protocol also includes a response format description content (ie, the Response part). It can be understood that the test instruction parsing module 120 is used to process the above-mentioned execution results and other data according to the response format description and then return them to the test host end 10.

[0080] For example, Figure 5As shown, the response format description includes: response header (Resp Head), response data (RespData) and response check data (response CRC), where Resp Head is used to record the specific type of the corresponding command and the execution result type of the command. It consists of three parts, namely the command code (OP Code) corresponding to the CMD command, the command execution status (Cmd Sts) and the response length (Resp Len). Resp Data represents the data returned by the test equipment in response to the command. For example, if it is a test query request command, the returned data is the test status query result. Response CRC is used to protect RespHead and Resp Data, and is usually calculated based on Resp Head and Resp Data.

[0081] The above Cmd Sts is used to record the execution result status of the corresponding command, usually occupying 1 Byte. The types of execution result status include at least the following situations: 1) CRC check failed, indicating that an error occurred during command transmission, and the Host needs to resend the command. 2) Success, indicating that the command was received successfully and is legal, and the device system can execute the command. 3) Illegal, indicating that the command content is illegal. 4) Cannot execute, indicating that the device system cannot currently execute the command. The length of Resp Len is 1 Byte, which is used to record how long the return data is carried in the return information.

[0082] In this application, based on the above test interface protocol, at least the following must be implemented: test configuration instructions, test request instructions, test status query instructions, etc. It can be understood that only a few key instructions are given as examples here. In fact, users can implement more commands according to the above agreed interface protocol according to actual needs, and there is no limitation here.

[0083] S120, the test instruction parsing module 120 performs instruction parsing and legality check on the successfully verified request instruction to extract a legal request instruction.

[0084] Exemplarily, the test instruction parsing module 120 can extract specific instruction data according to the above test interface protocol, and detect whether the instruction is legal according to internal preset rules, such as whether the OP Code value is legal, etc. If legal, the legal request instruction can be sent to the test control module 130 for further processing.

[0085] S130, the test control module 130 performs a test on the flash memory connected to the flash memory control interface module 140 according to the legal request instruction, and obtains the execution result.

[0086] Next, the test control module 130, as the core module of the flash memory controller, will be responsible for the specific test execution operation and obtain the corresponding execution result after receiving the legal request instruction. It can be understood that the execution result here refers to the returned data after the operation, which may include but is not limited to the above-mentioned execution result type (Cmd Sts), etc. For example, if it is a test status query operation, the execution result may also include the returned test status information and other contents.

[0087] S140 , the test instruction parsing module 120 processes the execution result according to the preset test interface protocol and returns it to the test host end 10 through the serial port interface module 110 .

[0088] Finally, the test instruction parsing module 120 processes the data that needs to be returned to the test host end 10 so that the test host end 10 can identify and analyze the test results.

[0089] For the above-mentioned test control module 130, in order to better illustrate its function, the following will describe the test execution in combination with the main instructions of the above-mentioned example.

[0090] For example, Figure 2 As shown, the test control module 130 mainly includes four main units, namely, a test configuration unit 210 , a test load generation unit 220 , a test thread scheduling unit 230 and a test monitoring unit 240 .

[0091] The test configuration unit 210 is used to configure the test related information according to the configuration request when the legal request instruction is a configuration request. It can be understood that the test host end 10 can update the test related configuration information through the instruction, such as, but not limited to, setting the maximum number of threads, whether to verify data consistency, whether to require global random error injection, and whether to pause after the test fails.

[0092] The test load generation unit 220 is used to generate a corresponding test load according to the test request when the legal request instruction is a test request. It can be understood that the test host end 10 notifies the device end through different test request instructions that some specific tests need to be performed, such as, but not limited to, sequential write operations, random read operations, read operations with injected errors, etc.

[0093] In one embodiment, if Figure 6 As shown, the test load generating unit 220 generates a corresponding test load according to the test request, including:

[0094] S210, describing the storage block information contained in all channels and all dies in the flash memory to obtain a storage block matrix. It can be understood that each test request sent will specify the block group of the test operation.

[0095] S220, determining and generating a test group from a memory block matrix according to a memory page range specified in the test request.

[0096] Generally, for the generation of a test load, each test request should at least include: the specified flash storage page range, flash IO type and size, IO operation type, data model and flash IO ratio. Specifically, the test request will specify one or more specific Channel ranges, Die ranges and Block ranges within the Channel, and storage page ranges within the Block. The test load generation module will generate a test group based on the above information, for example, Figure 7 The five different memory blocks shown can generate a test group. It can be understood that the test group includes address information of different memory pages to be operated.

[0097] S230, according to the flash IO type and size specified in the test request, determine the operation address of a flash IO operation from the test group. The specified flash IO type can be sequential or random, and the flash IO size is usually an integer multiple of 512 bytes, which can be set according to actual needs.

[0098] S240, generating test data to be written into a corresponding storage page in the flash memory and / or generating expected data according to the IO operation type and data model specified in the test request, wherein the expected data is used to be compared with actual data read from the corresponding storage page in the flash memory.

[0099] The IO operation type may be a write IO operation, a read IO operation, etc. For example, for a write IO operation, the test generation module will generate test data written into the flash memory according to the write data model specified in the test request. For a read IO operation, the test generation module will generate expected data according to the read data model specified in the test request, and compare the expected data with the actual data read from the flash memory to check the consistency of the data.

[0100] It can be understood that the above-mentioned write data model mainly includes the generation of fixed values, sequential increments, random values, and IO addresses corresponding to write operations, etc. The read data model mainly includes the relevant rules for generating expected data, such as different values ​​corresponding to different IO addresses, etc.

[0101] S250, according to the flash memory IO ratio specified in the test request, control the IO ratio sent to the flash memory, wherein the IO ratio includes the ratio of write and read operations, the ratio of sequential and random operations, and the ratio of different IO sizes.

[0102] It can be understood that a test usually requires operations on multiple storage pages, and the operation types of different storage pages may be different. For example, it may be an erase-first-write operation, or a direct read operation, etc. Therefore, the test request will also specify a specific flash memory IO operation ratio, for example, how many write IOs are required before reading IO, whether the next operation is a sequential write or random read operation (mainly determined by the continuity of the address), etc., and how large the IO size is set each time, etc., so as to achieve flash memory operations of different sequences and combinations.

[0103] As an optional solution, each test request may also include an error injection read instruction and a specified flash memory IO; thus, Figure 6 As shown, when the test load generating unit 220 generates the corresponding test load according to the test request, the method further includes:

[0104] S260, the test load generation unit 220 detects the presence of an error injection read instruction in the test request and marks the specified flash memory IO. The mark is used to indicate that an error injection is performed when calling the specified flash memory IO. For example, the error injection may include but is not limited to NAND UNC (verification error), timeout, illegal buffer address, etc.

[0105] The test thread scheduling unit 230 is used to schedule the test threads according to the selected scheduling mode after the test load is generated, so that each test thread runs the corresponding test load.

[0106] It is worth noting that each test request is executed by one and only one test thread. There are two ways to specify the corresponding thread: one is that the test host 10 directly specifies it through the test request instruction; the other is that the test load generation module allocates idle threads by itself. Of course, one test thread can be used to mount one or more test requests that need to be executed.

[0107] It can be understood that each test thread runs its own test load independently, which can simulate the user's actual high-complexity workload. For example, IOs of different flash IO sizes can be run simultaneously; for example, flash IO can be run while an error injection test is run, thereby achieving multi-threaded testing.

[0108] Regarding scheduling modes, there are two types here. The first is the default weight scheduling mode. When each thread starts running, a weight will be pre-set. Generally, the larger the weight, the more times the thread will run. In this mode, the test threads will be executed in sequence in the order of activation. There are two ways to set the weights, namely, setting them on the host side or verifying the firmware default settings. For the second, it is a scheduling mode that is fully defined by the host side, that is, the host sets the execution order of each thread (including weight). It can be understood that the thread scheduling rules are only a small part of the commonly used functions in this application. Users can set them according to actual needs and existing scheduling modes, so they will not be explained in detail here.

[0109] The test monitoring unit 240 is used to collect test status information during the test execution process. It is understood that the test host end 10 can obtain the test execution status during the test process through this command, for example, including but not limited to, the execution status of a specific test request (such as whether it is completed), the number of timeouts, the number of data inconsistencies, etc.; in addition, it can also include test thread status, IO count, Error count, Error type, performance test value, etc.

[0110] This application designs a flash memory controller prototype firmware, which is loaded and run through a hardware platform, and can accurately generate various complex test loads to meet the verification requirements of complex flash memory controllers in the prototype verification stage. Compared with the currently commonly used methods, it improves the verification efficiency while also improving the verification coverage, and can simulate the flash memory controller workload in actual user usage scenarios, generate high-pressure test loads, etc.

[0111] Based on the above-mentioned flash memory controller prototype firmware, the present application also proposes a flash memory controller prototype verification system. Exemplarily, the system includes: a test host end 10 and a test device end 20, wherein the test device end 20 includes an FPGA prototype verification hardware platform 100, wherein the FPGA prototype verification hardware platform 100 is connected to the test host end 10 via a serial port and is also used to connect to the flash memory.

[0112] Specifically, the test host 10 is used to receive the test script and command input by the user, and send corresponding request instructions to the FPGA prototype verification hardware platform 100 according to the test script and command. The FPGA prototype verification hardware platform 100 is used to load and run the flash controller prototype firmware of the above embodiment to realize the automated test of the flash memory.

[0113] In one embodiment, referring to the above Figure 1The test host end 10 may include a host terminal and a test tool or a test terminal based on Jenkins; wherein the user may input a customized test script and command through the Jenkins test tool or the test terminal.

[0114] It can be understood that the FPGA prototype verification hardware platform 100 of this embodiment is used to run the flash controller prototype firmware of the above embodiment. The options regarding the flash controller prototype firmware are also applicable to this embodiment, so they are not repeatedly described here.

[0115] The flash memory controller prototype verification system of the present application implements the shortest flash memory control request processing path by sending request instructions processed by a customized test protocol interface through a host terminal, and can also accurately generate various complex test loads with large coverage and support for multi-threaded operation, thereby efficiently completing the prototype verification of the flash memory controller.

[0116] like Figure 8 As shown, the present application also provides an FPGA prototype verification hardware platform 100. Exemplarily, the FPGA prototype verification hardware platform 100 includes a readily available field programmable gate array (FPGA), wherein the FPGA is used to load and run the functions of each module in the above-mentioned flash controller prototype firmware to implement prototype verification of the flash controller. It can be understood that the optional options of the flash controller prototype firmware in the above-mentioned embodiment are also applicable to this embodiment, so they will not be described again here.

[0117] Please refer to Figure 3 The present application also provides a flash memory controller prototype verification method, which is applied to a flash memory controller prototype verification system. The system includes a test host end 10 and an FPGA prototype verification hardware platform 100. The FPGA prototype verification hardware platform 100 is used to execute the flash memory controller prototype verification method, including:

[0118] Receive and verify the corresponding request instructions sent by the test host terminal 10 after being processed according to the preset test interface protocol through the serial port interface module 110, and extract the request instructions that have been successfully verified;

[0119] The test instruction parsing module 120 performs instruction parsing and legality check on the successfully verified request instruction to extract the legal request instruction;

[0120] The test control module 130 performs a test on the flash memory connected to the flash memory control interface module 140 according to a legal request instruction, and obtains an execution result;

[0121] The test instruction parsing module 120 processes the execution result according to the preset test interface protocol and returns it to the test host end 10 through the serial port interface module 110 .

[0122] It can be understood that the method steps of this embodiment correspond to the functions of the flash controller prototype firmware in the above embodiment, and the functional options of the flash controller prototype firmware in the above embodiment are also applicable to this embodiment, so they will not be repeated here.

[0123] The present application also provides a computer-readable storage medium for storing the prototype firmware of the flash controller of the above embodiment. For example, the computer-readable storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0124] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and structure diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in an alternative implementation, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the structure diagram and / or the flow diagram, and the combination of boxes in the structure diagram and / or the flow diagram, can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0125] In addition, the functional modules or units in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0126] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0127] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A flash memory controller prototype firmware, characterized in that: include: A serial port interface module, a test instruction parsing module, a test control module and a flash memory control interface module connected in sequence, wherein the serial port interface module is also used to connect to the test host end, and the flash memory control interface module is used to connect to the flash memory; The serial port interface module is used to receive and verify the corresponding request instructions sent by the test host end after being processed according to the preset test interface protocol, and extract the request instructions that have been successfully verified; The test instruction parsing module is used to perform instruction parsing and legality check on the successfully verified request instruction to extract a legal request instruction; The test control module is used to test and execute the flash memory connected to the flash memory control interface module according to the legal request instruction, and obtain the execution result; The test instruction parsing module is also used to process the execution result according to the preset test interface protocol and return it to the test host end through the serial port interface module; Wherein, the test control module includes a test configuration unit and a test load generation unit, wherein the test configuration unit is used to configure the test related information according to the configuration request when the legal request instruction is a configuration request; the test load generation unit is used to generate a corresponding test load according to the test request when the legal request instruction is a test request; the test load is used for the test control module to execute and obtain the execution result; Each of the test requests at least includes: a specified flash memory storage page range, a flash memory IO type and size, an IO operation type, a data model and a flash memory IO ratio; The test load generating unit generates a corresponding test load according to the test request, including: Describing the storage block information contained in all channels and all storage areas in the flash memory to obtain a storage block matrix; According to the storage page range specified in the test request, determine and generate a test group from the storage block matrix, wherein the test group includes address information of each storage page to be operated; Determine an operation address of a flash memory IO operation from the test group according to the flash memory IO type and size specified in the test request; wherein the flash memory IO type is sequential or random; Generate test data written into a corresponding storage page in the flash memory and / or generate expected data according to the IO operation type and data model specified in the test request, wherein the expected data is used to compare with actual data read from the corresponding storage page in the flash memory; According to the flash memory IO ratio specified in the test request, the IO ratio sent to the flash memory is controlled; wherein the IO ratio includes the ratio of write and read operations, the ratio of sequential and random operations, and the ratio of different IO sizes.

2. The flash controller prototype firmware according to claim 1, characterized in that: The test control module also includes a test thread scheduling unit and a test monitoring unit; The test thread scheduling unit is used to schedule the test threads according to the selected scheduling mode after the test load is generated, so that each test thread runs the corresponding test load; The test monitoring unit is used to collect test status information during the test execution process; wherein the test status information is used for the test host to query the test status.

3. The flash controller prototype firmware according to claim 1, characterized in that: Each of the test requests is executed by only one test thread, and one test thread is used to mount one or more of the test requests that need to be executed.

4. The flash controller prototype firmware according to claim 1, characterized in that: The step of generating test data to be written into a corresponding storage page in the flash memory and / or generating expected data according to the IO operation type and data model specified in the test request includes: When the IO operation type is a write IO operation, generating test data to be written into a corresponding storage page in the flash memory according to a write data model specified in the test request; When the IO operation type is a read IO operation, expected data for checking data consistency is generated according to a read data model specified in the test request.

5. The flash memory controller prototype firmware according to any one of claims 1 to 4, characterized in that: Each of the test requests also includes an error injection read instruction and a specified flash memory IO; When the test load generating unit generates the corresponding test load according to the test request, it also includes: The test load generation unit marks the specified flash memory IO when detecting the presence of the error injection read instruction in the test request; wherein the mark is used to indicate that error injection is performed when the specified flash memory IO is called.

6. The flash controller prototype firmware according to claim 1, characterized in that: The preset test interface protocol includes a command format description, and the test host generates the corresponding request instruction issued according to the command format description; The command format description includes: a command header, command data and command verification data, wherein the command header is used to indicate the specific type and command length of the current command, and the command verification data is calculated based on the command header and the command data.

7. The flash controller prototype firmware according to claim 6, characterized in that: The preset test interface protocol also includes a response format description, and the test instruction parsing module processes the execution result according to the response format description; The response format description includes: a response header, response data and response verification data. The response header is used to record the specific type of the corresponding command and the execution result type of the corresponding command. The response verification data is calculated based on the response header and the response data.

8. A flash memory controller prototype verification system, characterized in that: include: A test host end and an FPGA prototype verification hardware platform, wherein the FPGA prototype verification hardware platform is connected to the test host end via a serial port and is also used to connect to a flash memory; The test host is used to receive the test script and command input by the user, and send corresponding request instructions to the FPGA prototype verification hardware platform according to the test script and command; The FPGA prototype verification hardware platform is used to load and run the flash memory controller prototype firmware according to any one of claims 1 to 7 to implement automated testing of the flash memory.

9. The flash memory controller prototype verification system according to claim 8, characterized in that: The test host end includes a host terminal and a Jenkins test tool or a test terminal; The host terminal is used to receive control commands input by the user through the Jenkins test tool or the test terminal to control the execution of the test scripts and commands.

10. An FPGA prototype verification hardware platform, characterized in that: The FPGA in the FPGA prototype verification hardware platform is loaded with the flash controller prototype firmware according to any one of claims 1 to 7.

11. A flash memory controller prototype verification method, characterized in that: Applied to a flash memory controller prototype verification system, the system includes a test host end and an FPGA prototype verification hardware platform, the FPGA prototype verification hardware platform is used to execute a flash memory controller prototype verification method, including: Receive and verify the corresponding request instructions sent by the test host end after being processed according to the preset test interface protocol through the serial port interface module, and extract the request instructions that have been successfully verified; The successfully verified request instruction is parsed and checked for legality by a test instruction parsing module to extract a legal request instruction; The test control module performs a test on the flash memory connected to the flash memory control interface module according to the legal request instruction, and obtains an execution result; Processing the execution result according to the preset test interface protocol through the test instruction parsing module and returning it to the test host through the serial port interface module; Wherein, the test control module includes a test configuration unit and a test load generation unit; the test configuration unit is used to configure the test related information according to the configuration request when the legal request instruction is a configuration request; the test load generation unit is used to generate a corresponding test load according to the test request when the legal request instruction is a test request; the test load is used for the test control module to execute and obtain the execution result; Each of the test requests at least includes: a specified flash memory storage page range, a flash memory IO type and size, an IO operation type, a data model and a flash memory IO ratio; The test load generating unit generates a corresponding test load according to the test request, including: Describe the storage block information contained in all channels and all storage areas in the flash memory to obtain a storage block matrix; determine and generate a test group from the storage block matrix according to the storage page range specified in the test request, wherein the test group includes address information of each storage page to be operated; determine an operation address of a flash memory IO operation from the test group according to the flash memory IO type and size specified in the test request; wherein the flash memory IO type is sequential or random; generate test data written to the corresponding storage page in the flash memory and / or generate expected data according to the IO operation type and data model specified in the test request, wherein the expected data is used to compare with the actual data read from the corresponding storage page in the flash memory; control the IO ratio sent to the flash memory according to the flash memory IO ratio specified in the test request; wherein the IO ratio includes the ratio of write and read operations, the ratio of sequential and random operations, and the ratio of different IO sizes.

12. A computer-readable storage medium, characterized in that: Used to store the flash controller prototype firmware according to any one of claims 1 to 7.

Images