A Configurable Functional Simulation and Verification System for NAND Flash Memory Design

Abstract

This invention discloses a configurable functional simulation and verification system for NAND Flash storage design, including an FPGA under test, a processor model CPU_MOD, a data transmission chip model Data_Gen_MOD, a NAND Flash model NAND_Flash_MOD, a data reception model Data_rec_MOD, a first data comparator Compare1, a second data comparator Compare2, a third data comparator Compare3, and a test case executor TESTCASE. Through high-fidelity models and precise fault injection, the platform can construct a realistic "virtual NAND Flash environment" in the early stages of FPGA code development. This enables, for the first time, full-process, observable testing and debugging of key reliability designs such as bad block management algorithms, ECC error correction logic, and abnormal state machines in a scenario identical to actual operation. Designers can intuitively simulate how the controller identifies, records, and switches to a spare block after encountering an injected bad block during a random write operation, thus achieving full-process verification before the design is finalized.

Description

Technical Field

[0001] This invention relates to the field of FPGA testing technology, specifically to a configurable functional simulation and verification system for NAND Flash memory design. Background Technology

[0002] On-orbit data processing and storage systems are a core component of spacecraft functionality. In recent years, with the rapid development of navigation, manned, and deep space exploration satellites, their payload capacity has continuously improved, leading to an exponential increase in onboard operational, health management, and telemetry data. Therefore, high-capacity, highly reliable onboard storage systems have become essential. FPGA-based NAND Flash control schemes, due to their comprehensive advantages in capacity, speed, and reliability, have become the mainstream implementation method in current aerospace system design.

[0003] In aerospace system design, the general design structure of FPGA-controlled NAND Flash is shown in Figure 1. The FPGA mainly records data from the receiving chip according to file sequence number based on CPU instructions, and outputs the data after playback of the specified file through the sending chip. Due to the technological characteristics of NAND Flash devices, the devices themselves may have local data bit errors or bad blocks. Therefore, the combined design of FPGA-controlled NAND Flash will inevitably involve bad block detection, bad block information storage, and bad block replacement. Furthermore, when a frame of data is recorded in different block spaces, if a bad block occurs, only the corresponding bad block content of the data frame is erroneous. Error correction mechanisms such as encoding / decoding or interleaving / deinterleaving can correct the error. Based on this, the general operation flow of FPGA-controlled NAND Flash in spaceborne design is as follows: 1) Initialize and read bad block information.

[0004] The Flash management module initializes the Flash memory unit, which includes three steps: reset, setting mode parameters, and reading parameters. After initialization, the bad block information table is read from the chip storage area (pre-set in Flash) and written to the BRAM inside the Flash management module. 2) Perform a full self-check and create a bad block information table.

[0005] a) The CPU interface module parses the instructions input by the CPU. If it is a self-test instruction, proceed to b). b) The Flash management module performs a full erase of the Flash storage unit. After the erase is complete, proceed to c). c) The Flash management module performs a self-test on the Flash storage units, specifically: bad block checking is performed on a block-by-block basis: by reading redundant data from each block, it checks whether the data is a detection value; if not, the block is determined to be bad. Bad chip checking is performed on a LUN-by-LUN basis; blocks with more than 31 bad blocks are considered bad chips. After the bad block and bad chip checks are completed, proceed to d). d) The Flash management module updates the number of bad blocks and the address of bad blocks for each chip to the bad block information table, and finally updates it to the BRAM inside the Flash management module for bad block replacement during recording and playback.

[0006] 3) Data recording and playback.

[0007] a) The data input from the data transmission chip is processed sequentially by the RS encoding buffer module, RS encoding module, and data interleaving module before being recorded into the corresponding Flash storage unit (the internal address management module parses the CPU input storage file sequence number to obtain the Flash write address). Before the write operation, the Flash management module checks whether the block is bad according to the bad block information table. If it is, the data is written into the corresponding replacement block. b) The internal address management module parses the CPU input playback file sequence number to obtain the Flash read address. The data read from the Flash storage unit is processed by the data deinterleaving module, RS decoding module, and playback output buffer module before being output through the data receiving chip. Before the read operation, the Flash management module checks whether the block is bad according to the bad block information table. If it is bad, it is read from the corresponding replacement block.

[0008] In aerospace system design, different missions have varying requirements for storage capacity, interface standards, and reliability management (such as bad block handling), resulting in highly "non-standardized" and "customized" characteristics in FPGA control logic design. Therefore, the verification methods for onboard FPGA-controlled NAND Flash face significant challenges in practical engineering applications. Traditional verification methods mainly employ a combination of hardware test platforms and software simulation, or traditional RTL functional simulation. Traditional physical hardware test platforms heavily rely on physical prototype construction, i.e., using a real FPGA development board and a specific NAND Flash chip for joint debugging. This method has significant limitations: high hardware costs, requiring adjustments to the hardware platform for each design change; long verification cycles, limited by the speed of physical debugging and iteration; limited test scenarios, making it difficult to cover all extreme conditions (such as specific bad block distributions and timing boundary conditions); and extremely poor reusability, as a verification environment customized for one model cannot be directly used for the next project, leading to redundant development. Traditional RTL functional simulation uses tools such as ModelSim to simulate the basic functions of the FPGA controller logic during the design phase. However, traditional simulations typically only include a simplified Flash behavior model, mainly used to verify the correctness of the basic functions of the control logic, rather than fully simulating all the characteristics of real Flash (such as bad blocks and precise timing).

[0009] This invention proposes a verification method based on modular behavioral simulation and reconfigurable interface configuration. This method builds a flexible reconfigurable verification platform by constructing a highly modular and parameterized NAND Flash all-digital simulation model. It can realistically simulate the behavior of Flash devices with different capacities, interface timings and bad block characteristics, and realize efficient, reliable and reusable verification of FPGA storage control logic. Summary of the Invention

[0010] The purpose of this invention is to provide a configurable functional simulation and verification system for NAND Flash storage design, so as to solve the problems existing in the prior art.

[0011] To achieve the above objectives, the present invention provides the following technical solution: a configurable functional simulation and verification system for NAND Flash storage design, including an FPGA under test, a processor model CPU_MOD, a data transmission chip model Data_Gen_MOD, a NAND Flash model NAND_Flash_MOD, a data reception model Data_rec_MOD, a first data comparator Compare1, a second data comparator Compare2, a third data comparator Compare3, and a test case executor TESTCASE; The processor model CPU_MOD is connected to the CPU interface of the FPGA under test (FPGA) and is used to generate and send instruction sets to the FPGA under test. The data transmission chip model Data_Gen_MOD is connected to the data input interface of the FPGA under test and is used to generate and inject test data streams into the FPGA under test. The NAND Flash model NAND_Flash_MOD is connected to the Flash interface of the FPGA under test and is used to simulate the hardware interface and timing behavior of the NAND Flash memory chip. The data receiving model Data_rec_MOD is connected to the data output interface of the FPGA under test and is used to collect the data and signals output by the FPGA under test. The first data comparator Compare1 is connected to both the data transmission chip model Data_Gen_MOD and the data receiving model Data_rec_MOD and is used to compare the original input data with the final output data of the FPGA under test. The second data comparator Compare2 is connected to both the data transmission chip model Data_Gen_MOD and the NAND Flash model NAND_Flash_MOD and is used to compare the input data with the NAND Flash memory chip. The Flash model stores data internally; the third data comparator Compare3 is connected to the NAND Flash model NAND_Flash_MOD and the data receiving model Data_rec_MOD respectively, and is used to compare the data read back from the NAND Flash model with the output data of the FPGA under test; the test case executor TESTCASE is connected to the processor model CPU_MOD, the data transmitting chip model Data_Gen_MOD, the NAND Flash model NAND_Flash_MOD, the data receiving model Data_rec_MOD, the first data comparator Compare1, the second data comparator Compare2, and the third data comparator Compare3 respectively, and is used to schedule the execution of test cases by each module.

[0012] Furthermore, the instruction set generated by the processor model CPU_MOD includes self-test instructions, storage file number instructions, and playback file number instructions; the address range of the storage file number and playback file number is configurable, covering the maximum address space of the NAND Flash memory under test.

[0013] Furthermore, the data transmission chip model Data_Gen_MOD supports the configuration of data frame quantity and frame length parameters to generate test stimuli for different scenarios; the data reception model Data_rec_MOD is used to convert the physical layer response output by the FPGA under test into a higher-level data format for use by the data comparator.

[0014] Furthermore, the NAND Flash model NAND_Flash_MOD includes an I / O control module, a control logic module, an address register, a command register, a status register, a bidirectional data channel, and a storage matrix. The I / O control module is connected to the Flash interface, address register, command register, and status register of the FPGA under test, and is used to parse the bus commands and data issued by the FPGA under test and return chip status information. The control logic module is connected to the command register, address register, status register, bidirectional data channel, and storage matrix, and is used to receive operation commands, generate internal control timing, and coordinate the work of each sub-module. The registers are connected to the I / O control module, the control logic module, and the storage matrix to receive and latch address information, and manage read, write, and erase addresses. The command register is connected to the I / O control module and the control logic module to receive and latch decoded operation commands. The status register is connected to the control logic module and the I / O control module to store and update the chip's operating status. The bidirectional data channel is connected to the I / O control module, the control logic module, and the storage matrix to transmit data between the FPGA under test and the storage matrix. The storage matrix is ​​connected to the control logic module and the bidirectional data channel to simulate the physical data buffer and storage cell array of the NAND Flash, and to perform data storage, reading, and erasing operations.

[0015] Furthermore, the NAND Flash model NAND_Flash_MOD supports parameterized configuration, with configurable parameters including the number of chips, the number of logic units (LUNs), the block size, the number of pages per block, and the page size; the storage matrix supports simulating the latency and bad block characteristics of NAND Flash chips, which are considered non-ideal behaviors.

[0016] Furthermore, the I / O control module supports dynamic parameterized configuration of the interface mode. It can configure the Flash operation mode to synchronous or asynchronous mode according to the Flash initialization instructions of the FPGA under test, and match the timing model required by the corresponding chip. The timing model includes delay time, setup time and hold time.

[0017] Furthermore, the NAND Flash model NAND_Flash_MOD also integrates a fault injection task module, which includes a memory_write task, a memory_read task, a status_write task, and a status_read task. The status_write task is used to modify the status information of the status register or return timing errors, injecting operation errors. The status_read task is used to confirm the modification result of the status register. The memory_write task is used to modify specific data in the memory array, setting bad block markers, tampering with bad block information table data, or injecting data bit errors. The memory_read task is used to confirm the modification result of the memory array.

[0018] Furthermore, the test case executor TESTCASE is used to instantiate the drivers of all external modules, specifying the calling order and interaction method of each module; the test case executor TESTCASE supports the organization of different test cases, including standard functional test cases and abnormal fault test cases, to realize the automation and systematization of the verification process.

[0019] A verification method for a configurable functional simulation verification system for NAND Flash memory design includes the following steps: Step 1: Build a basic verification platform, instantiate and connect the FPGA under test, processor model CPU_MOD, data transmission chip model Data_Gen_MOD, NAND Flash model NAND_Flash_MOD, data reception model Data_rec_MOD, first data comparator Compare1, second data comparator Compare2, third data comparator Compare3, and test case executor TESTCASE; Step 2: Based on the actual selected NAND Flash chip, configure the NAND Flash model NAND_Flash_MOD parameterizedly to construct a high-fidelity NAND Flash behavior model; Step 3: Configure the operating mode and timing parameters of the NAND Flash model by parsing the initialization instructions of the FPGA under test to the Flash. Step 4: Perform a standard Flash verification scenario to conduct closed-loop verification of the power-on self-test, erase, data recording, and data playback functions of the FPGA controller under test; Step 5: Execute the fault injection scenario to inject predefined faults into the NAND Flash model and verify the fault tolerance mechanism of the FPGA controller under test.

[0020] Compared with the prior art, the beneficial effects of the present invention are: The platform, through high-fidelity models and precise fault injection, can construct a realistic "virtual NAND Flash environment" in the early stages of FPGA code development. This enables, for the first time, full-process, observable testing and debugging of critical reliability designs such as bad block management algorithms, ECC error correction logic, and abnormal state machines in a scenario identical to actual operation. Designers can intuitively simulate how the controller identifies, records, and switches to a spare block after encountering an injected bad block during a random write operation, thus achieving full-process verification before the design is finalized.

[0021] Traditional testing, limited by physical conditions, struggles to cover extreme and rare error scenarios. This platform, however, can easily simulate complex scenarios such as "a single data frame scattered across multiple blocks, one of which is suddenly marked as a bad block"; perform stress and endurance testing: by randomly and batch-injecting errors, it quickly verifies the system's stability under long-term operation or extreme conditions; and achieve automated regression testing: all test scenarios can be scripted, ensuring that the verification process for subsequent code changes can be automated after any design modifications.

[0022] By exposing potential design flaws at the earliest and lowest-cost stage, it avoids the massive rework and delays caused by discovering fatal problems only at the hardware prototype or even product stage; it reduces the material and time costs of building multiple hardware test platforms and purchasing different models of Flash chips for compatibility testing; the platform model and test cases themselves become reusable core verification assets, supporting rapid iteration of subsequent models, moving from "project-based" verification to "product-based" verification. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the FPGA-controlled NAND Flash design structure of the present invention; Figure 2 This is a structural diagram of the verification platform of the present invention; Figure 3 This is a schematic diagram of the NAND Flash storage structure of the present invention; Figure 4 This is a standard Flash verification scenario diagram for this invention; Figure 5 This is a flowchart of the self-test operation of the present invention; Figure 6 This is a flowchart of the erasure operation of the present invention; Figure 7 This is a flowchart of the data recording process of the present invention; Figure 8 This is a flowchart of the data playback process of the present invention; Figure 9 This is a simulation diagram of the power-on self-test scenario 1 of the present invention; Figure 10This is a simulation diagram of the erasure scenario 1 of the present invention; Figure 11 This is a simulation diagram of the data recording of the present invention; Figure 12 This is a simulation diagram of data playback for the present invention; Figure 13 This is a simulation diagram of the self-test anomaly of the present invention; Figure 14 This is a simulation diagram of the erasure timeout in this invention; Figure 15 This is a simulation diagram of the original data tampering in this invention; Figure 16 This is a simulation diagram of a specific data error in this invention. Detailed Implementation

[0024] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0025] Please see Figure 1-16 This invention provides a configurable functional simulation and verification system for NAND Flash storage design, including an FPGA under test, a processor model CPU_MOD, a data transmission chip model Data_Gen_MOD, a NAND Flash model NAND_Flash_MOD, a data reception model Data_rec_MOD, a first data comparator Compare1, a second data comparator Compare2, a third data comparator Compare3, and a test case executor TESTCASE.

[0026] The processor model CPU_MOD is connected to the CPU interface of the FPGA under test (FPGA) to generate and send instruction sets to the FPGA. The data transmission chip model Data_Gen_MOD is connected to the data input interface of the FPGA under test to generate and inject test data streams into the FPGA. The NAND Flash model NAND_Flash_MOD is connected to the Flash interface of the FPGA under test to simulate the hardware interface and timing behavior of the NAND Flash memory chip. The data receiving model Data_rec_MOD is connected to the data output interface of the FPGA under test to acquire the data and signals output by the FPGA. The first data comparator Compare1 is connected to both the data transmission chip model Data_Gen_MOD and the data receiving model Data_rec_MOD to compare the original input data with the final output data of the FPGA under test. The second data comparator Compare2 is connected to both the data transmission chip model Data_Gen_MOD and the NAND Flash model NAND_Flash_MOD to compare the input data with the data stored internally in the NAND Flash model. The third data comparator Compare3 is connected to both the NAND Flash chip model Data_Gen_MOD and the NAND Flash model NAND_Flash_MOD to compare the input data with the data stored internally in the NAND Flash model. The NAND Flash model NAND_Flash_MOD and the data receiving model Data_rec_MOD are connected to compare the data read back from the NAND Flash model with the output data of the FPGA under test. The test case executor TESTCASE is connected to the processor model CPU_MOD, the data transmitting chip model Data_Gen_MOD, the NAND Flash model NAND_Flash_MOD, the data receiving model Data_rec_MOD, the first data comparator Compare1, the second data comparator Compare2, and the third data comparator Compare3, respectively, to schedule the execution of test cases by each module.

[0027] The instruction set generated by the processor model CPU_MOD includes self-test instructions, storage file number instructions, and playback file number instructions; the address range of the storage file number and playback file number is configurable, covering the maximum address space of the NAND Flash memory under test.

[0028] The data transmission chip model Data_Gen_MOD supports the configuration of data frame quantity and frame length parameters to generate test stimuli for different scenarios; the data reception model Data_rec_MOD is used to convert the physical layer response output by the FPGA under test into a higher-level data format for use by the data comparator.

[0029] The NAND Flash model (NAND_Flash_MOD) includes an I / O control module, a control logic module, an address register, a command register, a status register, a bidirectional data channel, and a storage matrix. The I / O control module is connected to the Flash interface, address register, command register, and status register of the FPGA under test (FPGA), and is used to parse bus commands and data issued by the FPGA and return chip status information. The control logic module is connected to the command register, address register, status register, bidirectional data channel, and storage matrix, and is used to receive operation commands, generate internal control timing, and coordinate the work of each sub-module. The registers are connected to the I / O control module, the control logic module, and the storage matrix to receive and latch address information, and manage read, write, and erase addresses. The command register is connected to the I / O control module and the control logic module to receive and latch decoded operation commands. The status register is connected to the control logic module and the I / O control module to store and update the chip's operating status. The bidirectional data channel is connected to the I / O control module, the control logic module, and the storage matrix to transmit data between the FPGA under test and the storage matrix. The storage matrix is ​​connected to the control logic module and the bidirectional data channel to simulate the physical data buffer and storage cell array of the NAND Flash, and to perform data storage, reading, and erasing operations.

[0030] The NAND Flash model NAND_Flash_MOD supports parameterized configuration, with configurable parameters including the number of chips, the number of logic units (LUNs), the block size, the number of pages per block, and the page size. The storage matrix supports simulating the latency and bad block characteristics of NAND Flash chips, which are considered non-ideal behaviors.

[0031] The I / O control module supports dynamic parameterized configuration of the interface mode. It can configure the Flash operation mode to synchronous or asynchronous mode according to the Flash initialization instructions of the FPGA under test, and match the timing model required by the corresponding chip. The timing model includes delay time, setup time and hold time.

[0032] The NAND Flash model NAND_Flash_MOD also integrates a fault injection task module, which includes a memory_write task, a memory_read task, a status_write task, and a status_read task. The status_write task is used to modify the status information of the status register or return timing errors, injecting operation errors. The status_read task is used to confirm the modification result of the status register. The memory_write task is used to modify specific data in the memory array, setting bad block markers, tampering with bad block information table data, or injecting data bit errors. The memory_read task is used to confirm the modification result of the memory array.

[0033] The test case executor TESTCASE is used to instantiate the drivers of all external modules and specify the calling order and interaction method of each module. The test case executor TESTCASE supports the organization of different test cases, including standard functional test cases and abnormal failure test cases, to realize the automation and systematization of the verification process.

[0034] Example: Based on the verification method proposed in this invention, this section will demonstrate the full-process verification scheme using a specific example of a spaceborne storage system design. In this example, the main control FPGA is model XQR2V3000, the storage device is Micron's NAND Flash chip MT29F64G08AJABAWP, and the processor model is BM3803MGRH. The specific implementation steps will be described in detail below with reference to the accompanying drawings.

[0035] Step 1: Set up a basic verification platform in accordance with Figure 2 The verification platform structure shown demonstrates the construction of a complete simulation verification platform. Based on the selected peripheral device models, all necessary functional models are instantiated and connected, including: a processor model (CPU_MOD), a data transmission model (Data_Gen_MOD), a data reception model (Data_rec_MOD), three comparators (Compare1, Compare2, Compare3) for path, recording, and playback comparisons respectively, and a controllable test case executor (TESTCASE).

[0036] The test case executor, TESTCASE, serves as the central scheduling hub for the entire verification process. It first completes the initialization of all modules, including setting the simulation time precision, initializing the internal states of each model, and establishing signal connections between modules. Subsequently, TESTCASE schedules each module to execute its corresponding operations sequentially according to the predefined test case order, while monitoring the operational status of each module in real time and collecting simulation data and results.

[0037] Step 2: Construct a high-fidelity NAND Flash behavior model A high-fidelity NAND Flash behavior model (NAND_Flash_MOD) is constructed as the core for verification. Based on the MT29F64G08AJABAWP chip architecture specified in the project, parameterized configuration is performed: managing a total of 26 Flash chips (24 working chips + 2 reserved replacement chips), divided into 4 groups, each group containing 6 chips, and each chip having 4 logical units (LUNs). Each LUN contains 4096 blocks, each block contains 128 pages, and each page has a capacity of (4K+224) bytes, or 4320 bytes. Internally, block 0 is planned to store bad block table information, and blocks 1 to 31 are used for global replacement.

[0038] Simultaneously, in accordance with design requirements, all its sub-modules were fully constructed: I / O control, control logic, address register, command register, status register, bidirectional data channel, and NAND flash array. These sub-modules are interconnected via internal signals, working collaboratively to accurately simulate the behavior of a physical NAND flash chip.

[0039] Step 3: Configure operating mode and timing parameters The platform automatically configures the operation mode to asynchronous mode by parsing the FPGA's Flash initialization instruction configuration values. In this mode, all key timing parameters, such as delay time, setup and hold time, are precisely configured according to the specifications in the Micron MT29F64G08AJABAWP chip datasheet to ensure that the simulation timing is completely consistent with the actual behavior of the physical chip.

[0040] After receiving the initialization command from the FPGA, the I / O control module first decodes the command to extract the operation mode configuration information. Then, the I / O control module passes this configuration information to the control logic module. The control logic module adjusts its internal timing generation logic based on the configuration information, setting the corresponding delay time, setup time, and hold time parameters. Finally, the control logic module writes the configured status information into the status register and returns it to the FPGA through the I / O control module, completing the operation mode configuration process.

[0041] Step 4: Perform the standard Flash verification scenario A complete closed-loop verification under normal operating conditions was performed on the controller's core functional modules, including power-on self-test, erasure, data logging (programming), and data playback (reading). The specific verification process is as follows: Figures 4 to 8 As shown. To clarify, the following will describe in detail the specific verification process and execution steps of power-on self-test, erasure, data recording and data playback in turn.

[0042] 4.1 Verification of Power-On Self-Test Function 1) Use the `memory_write` task to write a bad block to a specific address (e.g., block 32) in the NAND Flash array. Then, use the `memory_read` task to read the data at that address and compare it using the `Compare1` comparator to confirm that the bad block information was accurately written, thus verifying that the fault injection channel and the basic functions of the storage model are normal. The verification is conducted in two specific scenarios: Scenario 1 (Single Bad Block): When only block 32 is set as a bad block, verify whether the bad block information table is updated correctly. Figure 9 As shown, address 32 (block address 0x20, page address 0x00, page address sum) is a bad block, and the bad block information table has been updated; Scenario 2 (Continuous bad block limit exceeded): When blocks 32 to 63 (a total of 32 blocks) are set as bad blocks, verify whether the bad block information table is updated correctly and whether the block is a bad block and unusable.

[0043] 2) The CPU_MOD processor model sends a self-test command to the FPGA controller, triggering its execution as follows: Figure 5 The self-test process is shown below. The self-test process includes: the Flash management module performing a full erase of the Flash storage unit; after erasure, performing a bad block check on a block-by-block basis; reading redundant data from each block to check if the data is a detection value; if not, the block is determined to be a bad block; and performing a bad chip check on a LUN-by-LUN basis, where more than 31 bad blocks are considered bad chips. After the bad block and bad chip checks are completed, the Flash management module updates the number of bad blocks and bad block addresses for each chip in the bad block information table, and finally updates it in the BRAM inside the Flash management module.

[0044] 3) Check whether the bad block mapping table stored in the BRAM inside the Flash management module has been updated synchronously. Read the bad block mapping table data in the BRAM inside the Flash management module through the memory_read Task, compare it with the pre-injected bad block information, and confirm that the contents of the bad block mapping table are accurate.

[0045] 4.2 Verification of the erase function 1) The CPU_MOD processor model sends an erase command (to a specific block or the entire chip) to the FPGA controller, triggering its execution as follows: Figure 6 The erase process is shown below. The erase process includes: the Flash management module parses the erase command to obtain the block address to be erased or the full-chip erase flag; sends the erase command to the NAND Flash model; waits for the NAND Flash model to return the erase completion status; and confirms the erase operation was successful. Specific verification is performed in the following two scenarios: Scenario 1 (Single Block Erase): When the instruction only erases a specific block, verify whether the data was erased correctly, such as... Figure 10 As shown, the original data is 0x24, 0xed, 0x12, 0x80, and after erasure, it becomes 0xff, 0xff, 0xff, 0xff; Scenario 2 (Full Disk Erase): When the instruction is a full disk erase instruction, verify whether the data has been erased correctly.

[0046] 2) Read data at a specified address (a block / the entire chip) through the memory_read Task, and compare it with the Compare1 comparator to confirm that the data information has been erased, thereby verifying that the erasure function is normal.

[0047] 4.3 Verification of Data Recording and Playback The CPU_MOD processor model sends data logging and data playback instructions to the FPGA controller according to system timing requirements, triggering its execution as follows: Figure 7 Data recording process and Figure 8 The data playback process is shown. It is verified in two specific scenarios: Scenario 1: Recording and replaying single-page data 1) The platform automatically generates random data through Data_Gen_MOD simulation and inputs it to the FPGA. According to the design requirements, 8 data channels are input simultaneously and 1 frame is sent. 2) A data recording instruction is issued via the CPU_MOD model, specifying the target address as page 0 of block 32 of the NAND Flash. For example... Figure 11 As shown, the data record at address 32 is correct; 3) The Compare2 comparison module is used to compare the original input data generated by Data_Gen_MOD with the stored data read from page 0 of block 32 by memory_read Task, thereby verifying whether the RS encoding and data interleaving operations performed by the FPGA during the recording process are correct; 4) The CPU_MOD CPU model issues a replay instruction, and the source address requested to be read is also specified as page 0 of block 32; 5) The Data_rec_MOD module receives and buffers playback data output from the FPGA, such as... Figure 12 As shown, the data at address 32 was played back correctly; 6) The Compare3 comparison module is used to compare the data directly read from the Flash physical page by the memory_read Task with the FPGA output data received by Data_rec_MOD to verify whether the data deinterleaving and RS decoding operations performed by the FPGA during playback are correct. 7) The Compare3 comparator is used to compare the data input to the FPGA (data generated by Data_Gen_MOD) and the data output to the FPGA (data received by Data_rec_MOD) to verify the closed-loop operation of single-block data recording and playback. 8) Use the Compare3 comparison module to compare the initial raw input data (Data_Gen_MOD generated) with the final FPGA output data (Data_rec_MOD received) to complete the closed-loop verification of the entire data path from recording to playback, and confirm the integrity and correctness of the single block data operation.

[0048] Scenario 2: Recording and replaying entire blocks of data By modifying steps 1, 2, and 4 of the above scenario from 1 frame to 129 frames, the FPGA controller's ability to record and play back the entire block of data was verified. The verification steps were the same as those for recording and playing back single-page data, sequentially executing steps such as data generation, recording command issuance, recorded data comparison, playback command issuance, playback data acquisition, playback data comparison, and full data path comparison to confirm the integrity and correctness of the entire data operation.

[0049] Step 5: Execute the error / fault injection scenario To comprehensively evaluate the robustness of the controller, it is necessary to build verification systems for key anomaly scenarios such as self-test anomalies, erase timeout anomalies, original data tampering anomalies, and specific / random data errors. The verification steps for each anomaly scenario will be described in detail below.

[0050] Scenario 1: Self-test anomaly 1) A self-test instruction is sent via the CPU_MOD CPU model, and the status register is modified via the status_write Task. An error is injected into the 32nd block erase operation, such as... Figure 13 As shown, the status register 0xe1 is displayed, and the least significant bit 1 indicates a self-test failure flag; 2) The status_read Task is used to confirm whether the above modification operation on the status register has been completed, i.e. whether the erasure failed; 3) Observe the response behavior of the FPGA controller to verify whether it can correctly identify the erase operation error and take corresponding abnormal handling measures, such as marking the block as a bad block and updating the bad block information table.

[0051] Scenario 2: Erase Timeout Exception 1) A self-test command is sent via the CPU_MOD CPU model. The status register is modified via the status_write Task. If the return time exceeds the maximum erase time, such as... Figure 14 As shown, after the maximum erase waiting time has elapsed, the erase status abnormally displays as incomplete; 2) The status_read Task is used to confirm whether the above modification operation on the status register has been completed, i.e. whether the erasure failed; 3) Observe the response behavior of the FPGA controller to verify whether it can correctly identify the erase timeout exception and take corresponding exception handling measures, such as retrying the erase operation or marking the block as a bad block.

[0052] Scenario 3: Abnormal Original Data Tampering After completing the self-test (where block 32 is preset as a bad block in step 1 and block 1 is designated as the replacement block), the original data recording and playback verification process (steps 1 to 8) is maintained and executed again to verify whether the FPGA controller's function of recording and playing back the entire data chip is still correct after triggering the bad block replacement mechanism. Figure 15 As shown, the data recording and playback are completely consistent.

[0053] Scenario 4: Specific / Random Data Errors and Exceptions By pre-setting a bit error in the NAND Flash memory array (specifically, a specific data bit in byte 40 of page 0 of block 32), and reusing the established data recording and playback verification process (steps 1 to 8) under this abnormal condition, the real-time error correction capability of the RS encoding and decoding design in the FPGA controller when a bit error occurs is specifically verified. This ensures that it can guarantee the integrity and correctness of end-to-end data, thereby confirming the functional reliability of the fault-tolerant design under non-ideal storage conditions. Figure 16As shown, the data displayed in block 32, page 0, byte 40 is inconsistent.

[0054] Through all the above verification steps, the functional correctness and reliability of the FPGA-controlled NAND Flash storage system can be comprehensively and systematically verified, ensuring that it meets the application requirements of high-reliability fields such as aerospace.

[0055] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A configurable functional simulation and verification system for NAND Flash memory design, characterized in that: This includes the FPGA under test, the processor model CPU_MOD, the data transmission chip model Data_Gen_MOD, the NAND Flash model NAND_Flash_MOD, the data receiving model Data_rec_MOD, the first data comparator Compare1, the second data comparator Compare2, the third data comparator Compare3, and the test case executor TESTCASE; The processor model CPU_MOD is connected to the CPU interface of the FPGA under test (FPGA) and is used to generate and send instruction sets to the FPGA under test. The data transmission chip model Data_Gen_MOD is connected to the data input interface of the FPGA under test and is used to generate and inject test data streams into the FPGA under test. The NAND Flash model NAND_Flash_MOD is connected to the Flash interface of the FPGA under test and is used to simulate the hardware interface and timing behavior of the NAND Flash memory chip. The data receiving model Data_rec_MOD is connected to the data output interface of the FPGA under test and is used to collect the data and signals output by the FPGA under test. The first data comparator Compare1 is connected to both the data transmission chip model Data_Gen_MOD and the data receiving model Data_rec_MOD and is used to compare the original input data with the final output data of the FPGA under test. The second data comparator Compare2 is connected to both the data transmission chip model Data_Gen_MOD and the NAND Flash model NAND_Flash_MOD and is used to compare the input data with the data stored inside the NAND Flash model. The third data comparator Compare3 is connected to both the NAND Flash chip model Data_Gen_MOD and the NAND Flash model NAND_Flash_MOD and is used to compare the input data with the data stored inside the NAND Flash model. The NAND Flash model NAND_Flash_MOD and the data receiving model Data_rec_MOD are connected to compare the data read back from the NAND Flash model with the output data of the FPGA under test. The test case executor TESTCASE is connected to the processor model CPU_MOD, the data transmitting chip model Data_Gen_MOD, the NAND Flash model NAND_Flash_MOD, the data receiving model Data_rec_MOD, the first data comparator Compare1, the second data comparator Compare2, and the third data comparator Compare3, respectively, to schedule the execution of test cases by each module.

2. The configurable functional simulation verification system for NAND Flash storage design according to claim 1, characterized in that: The instruction set generated by the processor model CPU_MOD includes self-test instructions, storage file number instructions, and playback file number instructions; the address range of the storage file number and playback file number is configurable, covering the maximum address space of the NAND Flash memory under test.

3. The configurable functional simulation verification system for NAND Flash storage design according to claim 1, characterized in that: The data transmission chip model Data_Gen_MOD supports the configuration of data frame quantity and frame length parameters to generate test stimuli for different scenarios; the data reception model Data_rec_MOD is used to convert the physical layer response output by the FPGA under test into a higher-level data format for use by the data comparator.

4. The configurable functional simulation verification system for NAND Flash storage design according to claim 1, characterized in that: The NAND Flash model (NAND_Flash_MOD) includes an I / O control module, a control logic module, an address register, a command register, a status register, a bidirectional data channel, and a storage matrix. The I / O control module is connected to the Flash interface, address register, command register, and status register of the FPGA under test, and is used to parse bus commands and data issued by the FPGA under test and return chip status information. The control logic module is connected to the command register, address register, status register, bidirectional data channel, and storage matrix, and is used to receive operation commands, generate internal control timing, and coordinate the work of each submodule. The address register is connected to the I / O control module, control logic module, and storage matrix, and is used to receive and latch address information, managing read, write, and erase addresses. The command register is connected to the I / O control module and control logic module, and is used to receive and latch decoded operation commands. The status register is connected to the control logic module and the I / O control module to store and update the chip's operating status; the bidirectional data channel is connected to the I / O control module, the control logic module, and the storage matrix to transmit data between the FPGA under test and the storage matrix. The storage matrix is ​​connected to the control logic module and the bidirectional data channel to simulate the physical data buffer and storage cell array of NAND Flash, and to perform data storage, reading and erasing operations.

5. A configurable functional simulation verification system for NAND Flash storage design according to claim 4, characterized in that: The NAND Flash model NAND_Flash_MOD supports parameterized configuration, with configurable parameters including the number of chips, the number of logic units (LUNs), the block size, the number of pages per block, and the page size. The storage matrix supports simulating the latency and bad block characteristics of NAND Flash chips, which are considered non-ideal behaviors.

6. A configurable functional simulation verification system for NAND Flash storage design according to claim 4, characterized in that: The I / O control module supports dynamic parameterized configuration of the interface mode. It can configure the Flash operation mode to synchronous or asynchronous mode according to the Flash initialization instructions of the FPGA under test, and match the timing model required by the corresponding chip. The timing model includes delay time, setup time and hold time.

7. A configurable functional simulation verification system for NAND Flash storage design according to claim 4, characterized in that: The NAND Flash model NAND_Flash_MOD also integrates a fault injection task module, which includes a memory_write task, a memory_read task, a status_write task, and a status_read task. The status_write task is used to modify the status information of the status register or return timing errors, injecting operation errors. The status_read task is used to confirm the modification result of the status register. The memory_write task is used to modify specific data in the storage array, set bad block markers, tamper with bad block information table data, or inject data bit errors. The memory_read task is used to confirm the results of modifications to the storage array.

8. A configurable functional simulation verification system for NAND Flash memory design according to claim 1, characterized in that: The test case executor TESTCASE is used to instantiate the drivers of all external modules and specify the calling order and interaction method of each module. The test case executor TESTCASE supports the organization of different test cases, including standard functional test cases and abnormal fault test cases, to realize the automation and systematization of the verification process.

9. A verification method for a configurable functional simulation verification system for NAND Flash memory design according to any one of claims 1-8, characterized in that: Includes the following steps: Step 1: Build a basic verification platform, instantiate and connect the FPGA under test, processor model CPU_MOD, data transmission chip model Data_Gen_MOD, NAND Flash model NAND_Flash_MOD, data reception model Data_rec_MOD, first data comparator Compare1, second data comparator Compare2, third data comparator Compare3, and test case executor TESTCASE; Step 2: Based on the actual selected NAND Flash chip, configure the NAND Flash model NAND_Flash_MOD parameterizedly to construct a high-fidelity NAND Flash behavior model; Step 3: Configure the operating mode and timing parameters of the NAND Flash model by parsing the initialization instructions of the FPGA under test to the Flash. Step 4: Perform a standard Flash verification scenario to conduct closed-loop verification of the power-on self-test, erase, data recording, and data playback functions of the FPGA controller under test; Step 5: Execute the fault injection scenario to inject predefined faults into the NAND Flash model and verify the fault tolerance mechanism of the FPGA controller under test.

Images