Verification method and device for FLASH memory and universal verification platform
By using parametric signal timing modeling and automated simulation data generation, the problems of omissions and errors caused by manual timing modifications in FLASH memory simulation verification are solved, achieving an efficient and accurate verification process that is adaptable to FLASH memory of different specifications.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING TONGFANG MICROELECTRONICS
- Filing Date
- 2025-12-29
- Publication Date
- 2026-04-21
AI Technical Summary
In existing FLASH memory simulation verification methods, the risk of omissions and errors due to manual modification of signal timing is relatively high, affecting the accuracy and efficiency of verification, especially when there are many test modes to be verified.
Signal timing is modeled using executable tasks in a hardware description language, and key time intervals are parameterized. By configuring parameters, the timing requirements of different FLASH memories are adapted, and simulation data is automatically generated and verified through simulation.
It improves the accuracy and efficiency of simulation verification, reduces human error, supports rapid adaptation to FLASH memory of different capacities and specifications, and reduces verification preparation time and repetitive workload.
Smart Images
Figure CN121905255A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of non-volatile memory chip technology, such as a verification method and apparatus for FLASH memory, and a general verification platform. Background Technology
[0002] Currently, the FLASH simulation verification method involves writing the input signals sequentially into the testbench (verification platform) according to the timing sequence specified in the operation manual, then simulating the function of that timing sequence to generate a waveform file, and checking whether the FLASH function defined in the testbench is correct. However, the method of writing the timing sequence of each signal into the testbench still relies on manually modifying the timing sequence of each signal, or implementing the timing sequence of some FLASH input signals in the form of parameters.
[0003] In related technologies, a method for checking the test mode of FLASH memory is disclosed, which involves manually modifying a simulation file in sequence, adding configuration statements related to applied voltage or applied current to the simulation file, and manually writing the configuration code required for the current test mode into the test platform.
[0004] In the process of implementing the embodiments of this disclosure, at least the following problems were found in the related art: When there are a large number of test modes to be verified, the number of files that need to be modified is enormous. There is a risk of omissions due to human error and errors due to human mistakes, which affects the accuracy and efficiency of simulation verification.
[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0006] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.
[0007] This disclosure provides a verification method and apparatus for FLASH memory, as well as a general verification platform, to improve the accuracy and efficiency of FLASH memory simulation verification.
[0008] In some embodiments, the verification method for FLASH memory includes: modeling signal timing in the form of executable tasks in a hardware description language based on the timing requirements of the target FLASH memory's operating manual, and defining key time intervals between signals as configurable parameters; configuring the executable tasks and key time intervals according to parameter values input by the user to adapt to the target FLASH memory; generating simulation data based on the configured executable tasks and key time intervals, and simulating the design under test (DUT) of the target FLASH memory model based on the simulation data; the DUT includes read / write / erase function checks, read / write / erase decoding logic checks, or test mode checks; and checking the timing signals, voltage signals, and decoding logic signals in the DUT according to the parameterized timing requirements during the simulation.
[0009] Optionally, the signal timing is modeled as an executable task in a hardware description language, including: determining the basic timing in the signal timing; and determining other timings in the signal timing based on the basic timing and according to time interval parameters.
[0010] Optionally, in the read mode signal timing, the basic timing is the RECALL signal; and / or, in the write mode signal timing, the basic timing is the PROG signal.
[0011] Optionally, the address input in the signal timing can be implemented as follows: all addresses to be verified are collected and stored in the same address file; the addresses in the address file are classified and identified according to the address keywords, the type of each address is determined, and the identification result is obtained; based on the identification result, timing signals of different address types are generated according to the specified timing requirements.
[0012] Optionally, the read / write / erase decoding logic check is implemented as follows: The address to be checked is divided into a first address and a second address; the address controlling the Y direction is defined as the first address, and the address controlling the X direction is defined as the second address; the first address is traversed, checking whether the BL of the selected address is set to high voltage during a read operation, while other unselected BLs remain 0; the selected BL of the address is checked whether it is set to a low-level voltage below a first voltage threshold during a write operation, while other unselected BLs remain the power supply voltage; the second address is traversed, checking whether the WL corresponding to the address read during a read operation can be correctly selected and set to high voltage, while other unselected WLs remain 0; the WL corresponding to the address written during a write operation can be correctly selected and set to high voltage, while other unselected WLs remain 0; the CG corresponding to the address written during a write operation can be correctly selected and set to high voltage, while other unselected CGs remain 0; the EG corresponding to the address erased during an erase operation can be correctly selected and set to high voltage, while other unselected EGs remain 0.
[0013] Optionally, the address width to be traversed for read / write / erase decoding is determined as follows: Define the total address width of the FLASH memory, the address width in the X direction, the address width in the Y direction, and the number of FLASH memory arrays; based on the defined data, traverse the address decoding in the X and Y directions to obtain the address number to be generated; determine the address width to be traversed based on the address number.
[0014] Optionally, the test mode check is performed as follows: confirm the test mode associated data to be written to the simulation file; the test mode associated data includes the test mode code, the applied voltage parameters and applied current parameters required for the test mode to run; establish the parameter mapping relationship between the test mode associated data and the simulation file, determine the target writing position and data format requirements of each test mode associated data in the simulation file; and write the identified test mode code, applied voltage parameters and applied current parameters to the corresponding target writing position in the simulation file according to the data format requirements.
[0015] Optionally, a Verilog task can be used to model the signal timing.
[0016] In some embodiments, the verification apparatus for FLASH memory includes a processor and a memory storing program instructions, the processor being configured to execute the verification method for FLASH memory as described above when the program instructions are executed.
[0017] In some embodiments, the general verification platform stores program instructions that, when executed, cause the general verification platform to perform the verification method for FLASH memory as described above, realizing FLASH memory read / write / erase function checks, read / write / erase decoding logic checks, or test mode checks. The file structure of the general verification platform includes a netlist file, a measure file, a probe file, an option file, a parameter file, a task file, a template file, a configuration file, and a core script. The netlist file includes a netlist of the FLASH circuit, describing the interconnections between various components in the FLASH circuit. The measure file includes measurements of key AC and DC parameters related to the FLASH read / write / erase modes and low-power modes as described in the operation manual, as well as measurements of key analog quantities related to read / write / erase. The probe file includes FLASH read / write / erase modes and test... The mode needs to check key voltages and currents; the option file includes key options that need to be set for various FLASH operations; the parameter file contains the values of each parameter based on the specific values of read timing, erase timing, power-on / off timing, and test mode timing determined by the FLASH operation manual; the task file writes the various input signals used for FLASH decoding logic timing, read timing, write timing, erase timing, and test mode timing into task syntax according to the corresponding timing requirements; the template file defines the modules, PVT, measure path, probe path, and option path that need to be called for FLASH simulation; the core script defines the function options supported by the script, including the generation of simulation files and folders for read, write, and erase function checks, the generation of simulation files and folders for read, write, and erase decoding logic checks, and the generation of simulation files and folders for test mode checks.
[0018] The verification method and apparatus for FLASH memory and the general verification platform provided in this disclosure can achieve the following technical effects: In this embodiment, the timing parameters of different modes in the operation manual are modeled as executable tasks in a hardware description language, and the key time intervals between signals are parameterized, making the verification process more flexible and efficient. Users only need to modify the parameters to adapt to the timing requirements of different FLASH memories, without having to manually modify the timing of each signal, significantly reducing verification preparation time. The parameterized design makes the verification method universal, enabling it to quickly adapt to FLASH memories of different capacities and specifications, reducing repetitive work and improving verification efficiency. Furthermore, the parameterized timing constraints ensure that the simulation verification strictly follows the requirements of the operation manual, reducing verification errors caused by manual timing configuration mistakes. Automated generation of simulation data and execution of simulation verification reduce the risk of human error and improve the reliability and accuracy of verification results.
[0019] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description
[0020] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic diagram of a verification method for FLASH memory provided in an embodiment of this disclosure; Figure 2 This is a timing diagram of a read operation of a FLASH memory provided in an embodiment of this disclosure; Figure 3 This is a timing diagram of a write operation of a FLASH memory provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram of a general verification platform provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of a verification device for FLASH memory provided in an embodiment of the present disclosure. Detailed Implementation
[0021] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.
[0022] The terms "first," "second," etc., used in the technical solutions described in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.
[0023] Unless otherwise stated, the term "multiple" means two or more.
[0024] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.
[0025] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.
[0026] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.
[0027] Combination Figure 1 As shown, this disclosure provides a verification method for FLASH memory. The execution subject of this simulation verification method can be a processor, and the simulation verification method includes: S101, based on the timing requirements of the target FLASH memory's operation manual, models the signal timing in the form of an executable task in a hardware description language, and defines the key time intervals between signals as configurable parameters.
[0028] S102 configures the executable tasks and critical time intervals based on the parameter values input by the user to adapt to the target FLASH memory.
[0029] S103 generates simulation data based on the configured executable tasks and key time intervals, and performs simulation on the design under test of the target FLASH memory model based on the simulation data.
[0030] The design under test includes read / write / erase function checks, read / write / erase decoding logic checks, or test mode checks.
[0031] S104 checks the timing signals, voltage signals, and decoding logic signals in the design under test according to the parameterized timing requirements during the simulation process.
[0032] In this embodiment, the timing parameters of different modes in the operation manual are modeled as executable tasks in a hardware description language, and the key time intervals between signals are parameterized, making the verification process more flexible and efficient. Users only need to modify the parameters to adapt to the timing requirements of different FLASH memories, without having to manually modify the timing of each signal, significantly reducing verification preparation time. The parameterized design makes the verification method universal, enabling it to quickly adapt to FLASH memories of different capacities and specifications, reducing repetitive work and improving verification efficiency. Furthermore, the parameterized timing constraints ensure that the simulation verification strictly follows the requirements of the operation manual, reducing verification errors caused by manual timing configuration mistakes. Automated generation of simulation data and execution of simulation verification reduce the risk of human error and improve the reliability and accuracy of verification results.
[0033] Optionally, a Verilog task can be used to model the signal timing of each mode.
[0034] Optionally, the critical time interval includes at least one of write command setup time, write command hold time, page programming time, and block erase time.
[0035] In this embodiment, the AC (Alternating Current) parameters from the operation manual can be defined in Verilog. Table 1 shows some of the AC parameters from the operation manual.
[0036] Table 1
[0037] The parameters in Table 1 can be defined using Verilog. Taking tRC, tCK, and tCKH as examples, they can be defined as: parameter tRC=50; parameter tCK=10; parameter tCKH=5. Other parameters can also be defined using the same Verilog statements. Furthermore, depending on actual needs, other AC parameters in the operation manual can be defined in the same way, which will not be elaborated here. After defining the parameters, refer to the input timing relationships of each FLASH operation mode in the operation manual and define them using Verilog tasks.
[0038] Optionally, the signal timing includes the signal timing for read, write, erase operations and test modes.
[0039] Optionally, the signal timing is modeled as an executable task in a hardware description language, including: determining the basic timing in the signal timing; and determining other timings in the signal timing based on the basic timing and according to time interval parameters.
[0040] In this embodiment, by determining the basic timing sequence of the signals, a benchmark for the signal timing can be established. Then, based on the time interval parameter, the rise time, fall time, hold time, set time, etc., of each other signal can be precisely defined. Parameterizing the timing and implementing it in code can avoid errors that may occur when manually calculating the timing and ensure the consistency of all timing relationships.
[0041] Optionally, in the read mode signal timing, the basic timing is the RECALL signal; and / or, in the write mode signal timing, the basic timing is the PROG signal.
[0042] Combination Figure 2 The diagram shown is a timing diagram for a read operation of a FLASH memory, illustrating the entire read operation cycle from address validity to data output validity. Figure 2In the NVR / IARRDN, CEb represents the chip enable signal; when CEb is low, the FLASH memory is enabled. A (Address) represents the address signal, used to specify the memory cell to be accessed. (1) These signals are used to specify a particular memory region, such as a non-volatile register (NVR) or a read-only register (ARRDN). AE represents the access enable signal, used to initiate a read operation. WEb represents the write enable signal; when this signal is low, a write operation is allowed. DOUT represents the data output signal; memory data is output from this port. RECALL indicates the start of a "call" or "read" operation. VREAD0 and VREAD1 represent additional signals used to indicate a read operation, specifying the data type or source to be read.
[0043] Combination Figure 3 The diagram shown is a timing diagram for a write operation of a FLASH memory, illustrating the entire write operation cycle from address validity to data validity. Figure 3 In the diagram, CEb represents the chip enable signal. When CEb is low, the FLASH memory is enabled. Ax (2) and Ay (2) This indicates an address signal used to specify the address of the memory cell to be written to. (NVR / IARRDN) (1) Signals indicating specific memory areas, such as non-volatile registers (NVRs) or read-only registers (ARRDNs). AE indicates an access enable signal, used to initiate a write operation. DIN indicates a data input signal, used to write data to the FLASH memory. WEb (3) The first signal is the write enable signal; when WEB is low, write operations are allowed. The second signal is the programming signal, used to trigger a write operation. The third signal is the second stage or further confirmation signal for the write operation. The fourth signal is the pre-programming signal, used to prepare the programming sequence. The fifth signal is the erase signal, used to erase the memory array or block. The sixth signal is the chip select and block select signals, used to specify the specific chip or memory block to be operated on.
[0044] In one specific embodiment, for Figure 2 The timing mechanism allows defining key time intervals between signals as configurable parameters. Based on the RECALL signal, for the AE signal, the first rising edge occurs after the RECALL signal is pulled low for a duration of tRR, followed by the second rising edge after a duration of tRC. The high-level hold duration is tAEPH, completing the AE signal input. For the CEb signal, the falling edge occurs after the RECALL signal is pulled low for a duration of tRR-tCS. Figure 2Other signals in the process can be defined in the Verilog task in the same way, and will not be elaborated here. Furthermore, power-on / off operations in the Verilog task can also be written according to the read-mode timing. Figure 3 In the context of timing, the PROG signal is used as the basis. For the AE signal, the first rising edge of the AE signal occurs after the PROG signal goes high and is spaced for tPS. The high level is held for tAEPH. Figure 3 Other signals in the process can be defined in the Verilog task in the same way, and will not be elaborated here.
[0045] Optionally, the simulation data includes simulation stimuli, simulation files, and folders; simulation data is generated according to the configured executable tasks and key time intervals, including: generating simulation stimuli for the design under test in a hardware description language based on the specified timing requirements; and generating simulation files and folders for the design under test according to the function of the design under test, as well as the corner (boundary condition) information, temperature information, and voltage information that need to be verified.
[0046] In this embodiment, simulation stimulus signals conforming to the FLASH operation manual can be automatically generated according to specified timing requirements, and corresponding simulation files and folder structures can be automatically generated according to different simulation needs. Through automation and parameterization, human error is reduced, and the accuracy and efficiency of verification are improved.
[0047] Optionally, based on the specified timing requirements, simulation stimuli for the design under test are generated using a hardware description language, including: defining the simulation time unit and time precision; defining FLASH modules for simulating each port of the FLASH memory; defining a test platform for initializing the initial values of the FLASH ports and calling specific operations to verify the FLASH function; and dynamically switching different operations through scripts to achieve general simulation verification.
[0048] In a specific embodiment, the simulation time unit is defined as 11ns, and the time precision is 10ps. That is, the smallest unit of simulation time is 1ns, and the simulation result will be accurate to 10ps. Then, a module named "sim" is defined to simulate the various ports of the FLASH memory. For example, input ports: A (address line), CEb (chip enable), CLOCK (clock signal), etc.; output ports: DOUT (data output); bidirectional ports: VPP (programming voltage), VDD (power supply voltage), VSS (ground). Then, a test platform module "tb" is defined to initialize and drive the various ports of the FLASH module. All input signals are defined using reg type variables, and output signals are defined using wire type variables. The "sim" module is instantiated as main and connected to all ports. The initial values of all input signals are initialized in the initial block. All input signals are initialized to default values, such as CEb=1'b1, indicating that the chip enable signal is initially high; the "read" task or other tasks, such as program or erase, are called to execute specific FLASH operations; the simulation is ended using $finish. The "read" task can be dynamically replaced using scripts to perform different Flash operations (such as read, write, and erase). In the test platform, the "read" task can be automatically replaced by other tasks (such as program or erase) through scripts, thereby achieving general simulation verification.
[0049] This embodiment implements a module and test platform for FLASH memory simulation. By defining the simulation time unit, initializing port signals, and calling specific tasks, it achieves simulation verification of FLASH functionality. Dynamically switching between different tasks via scripts supports various FLASH operations, demonstrating high versatility and flexibility.
[0050] Optionally, based on the function of the design under test and the corner information, temperature information and voltage information that need to be verified, simulation files and folders for the design under test are generated, including: defining the function to be verified and the PVT conditions for functional checks; defining the decoding logic to be verified and the PVT conditions for functional checks; defining the test mode to be verified and the PVT conditions for functional checks; and generating the corresponding simulation files and folders based on the defined information.
[0051] In a specific embodiment, a variable named "functionlist" is defined to list the FLASH functions that need to be simulated and verified, such as: read, program, erase, and chiperase. A variable named "functioncorner" is defined to list the PVT conditions that need to be simulated and verified, such as: tt_1p2v_25c, representing a typical process, 1.2V voltage, and 25℃ temperature; ss_1p0v_n40c, representing a slow process, 1.0V voltage, and -40℃ temperature; ff_1p35v_120c, representing a fast process, 1.35V voltage, and 120℃ temperature. A variable named "decodelist" is defined to list the functions that need to be decoded and checked, such as: decode_check1 (decode check function 1), decode_check2 (decode check function 2), and decode_check3 (decode check function 3). A variable named "decodecorner" is defined to list the PVT conditions that need to be verified during decoding checks, such as tt_1p2v_25c, which represents typical process technology, 1.2V voltage, and 25℃ temperature. A variable named "testmodelist" is defined to list the functions that need to be checked for test modes, such as testmode1 (test mode 1), testmode2 (test mode 2), and testmode3 (test mode 3). A variable named "testmodecorner" is defined to list the PVT conditions that need to be verified for test mode checks, such as tt_1p2v_25c, which represents typical process technology, 1.2V voltage, and 25℃ temperature. Furthermore, for functions or PVTs that do not require simulation, a "#" symbol can be added to indicate that the definition in that line is ignored, such as #chiperase, which indicates ignoring chip-level erase operations, and #ff_1p35v_120c, which indicates ignoring the PVT condition of fast process technology, 1.35V voltage, and 120℃ temperature.
[0052] In this embodiment, the script automatically generates corresponding simulation files based on the defined functions and PVT conditions, reducing manual configuration workload and improving verification efficiency. Adding "#" to ignore unnecessary functions or PVT conditions makes simulation configuration more flexible and allows for rapid adaptation to different verification needs. Defining functions and PVT conditions in separate lists gives the simulation platform good modularity and scalability. When adding new functions or PVT conditions, only the corresponding list needs to be modified. Explicitly listing the functions and PVT conditions to be verified ensures comprehensive verification. Simultaneously, the automatically generated simulation files reduce human error and improve verification accuracy.
[0053] Optionally, the functions of the design under test include: read function X-direction decoding logic check, read function Y-direction decoding logic check, write function X-direction decoding logic check, write function Y-direction decoding logic check, erase function X-direction decoding logic check, erase function Y-direction decoding logic check, overall read function check, overall erase function check, overall write function check, function checks for each test mode, and information such as corner, temperature, and voltage that need to be verified.
[0054] Alternatively, addresses in the FLASH memory can be defined as follows: the addresses to be read are listed directly in Verilog; the memory regions to which these addresses belong are identified by keywords.
[0055] In a specific embodiment, the addresses to be read from the main array are listed, such as 0001, 0002, 0003, 0004, FFFC, FFFD, FFFE, and FFFF, representing the address range to be accessed in the main array. These addresses will be identified as belonging to the main array and directly written into the Verilog timing in the simulation. The addresses to be read from non-volatile registers are listed, such as 0000 and 0001, representing the addresses to be accessed in non-volatile registers. These addresses will be identified as belonging to non-volatile registers and directly written into the Verilog timing in the simulation. The addresses to be read from read-only registers are listed, such as 0000 and 0001, representing the addresses to be accessed in read-only registers. These addresses will be identified as belonging to read-only registers and directly written into the Verilog timing in the simulation.
[0056] In this embodiment, by directly listing the addresses, complex address generation logic is avoided, making address definitions more intuitive and easier to manage. The general verification script automatically identifies these addresses and writes them into the Verilog timing data, reducing the workload of manual configuration and improving simulation efficiency.
[0057] Optionally, the address input in the signal timing can be implemented as follows: all addresses to be verified are collected and stored in the same address file; the addresses in the address file are classified and identified according to the address keywords, the type of each address is determined, and the identification result is obtained; based on the identification result, timing signals of different address types are generated according to the specified timing requirements.
[0058] The address types include main array, non-volatile register array (NVR array), or read-only register array (RDN array).
[0059] In this embodiment, all addresses to be verified are stored in the same file for unified management and maintenance. The addresses in the address file are automatically classified and identified to determine the type of each address. Through automatic classification and identification, it is ensured that different types of addresses can generate corresponding read operation timing signals according to their types, thereby improving the flexibility and accuracy of verification.
[0060] Optionally, the timing requirements specified in the operation manual include read timing, write timing, erase timing, and test mode timing. Read timing includes FLASH power-on, read operation, and FLASH power-off. Write timing includes FLASH power-on, write operation, and FLASH power-off. Erase timing includes FLASH power-on, erase operation, and FLASH power-off. All read, write, and erase timings must be generated by parameters. Test mode timing includes FLASH power-on, entering test mode, inputting test mode code, reading / writing / erasing mode, exiting test mode, and FLASH power-off. All of the above timings must be configured strictly according to the timing relationships in the operation manual in the task file.
[0061] In a specific embodiment, the code can automatically classify addresses through keyword recognition and generate corresponding read operation timing signals based on the classification results. First, variables for storing matching results and address data are defined, such as: current_match_main_array, current_match_NVR, and current_match_RDN, used to mark whether the current address matches the corresponding storage area; addr_line, used to store the current line address data in a register; and addr_count, used to record the number of addresses. Then, the storage area to which the current address belongs is identified through keywords, such as: strlen(keywords[0])>0, used to check whether the keyword is valid; str_contains(addr_line, "main array"), used to check whether the current line address data contains the keyword "main array"; and current_match_main_array, current_match_NVR_array, and current_match_RDN_array, used to set the corresponding boolean variables according to the keyword matching results. The matching results are stored in the corresponding arrays, such as the arrays match_main_array, match_NVR, and match_RDN, used to store the matching results of each address; and the address counter addr_count is used to index the array. Finally, based on the matching results, read operation timing signals for different storage areas are generated. By traversing all addresses and setting the corresponding control signals (such as NVR, ARRDN) according to the matching results, read operation timing signals are generated, including address setting, read enable, clock signals, etc. Delays (#tas, #tah, #(trc / 2)) are used to ensure that the timing meets the specified requirements.
[0062] This embodiment automatically categorizes addresses using keyword recognition, reducing manual configuration workload and improving verification efficiency. It supports multiple storage regions (main array, NVR array, RDN array) to ensure comprehensive verification. Corresponding read operation timing signals are generated based on address type to ensure verification accuracy. Automated processing and timing signal generation reduce human error and improve overall verification efficiency.
[0063] Optionally, the X-direction decoding logic check for read, write, and erase functions includes traversing the X-direction address decoding of the FLASH main array region, the X-direction address decoding of the NVR region, and the X-direction address decoding of the ARRDN region. The Y-direction decoding logic check for read, write, and erase functions includes traversing the Y-direction address decoding of the FLASH array region.
[0064] Optionally, the overall read functionality check includes read functionality checks for the main array region, the NVR region, and the ARRDN region. The overall write functionality check includes write functionality checks for the main array region, the NVR region, and the ARRDN region. The overall erase functionality check includes erase functionality checks for the main array region and the ARRDN region.
[0065] Optionally, the read / write / erase decoding logic check is implemented as follows: The address to be checked is divided into a first address and a second address; the address controlling the Y direction is defined as the first address, and the address controlling the X direction is defined as the second address; the first address is traversed, and during a read operation, it is checked whether the selected BL (bit line) is set to high voltage, while other unselected BLs remain 0; during a write operation, it is checked whether the selected BL is set to a low-level voltage below a first voltage threshold, while other unselected BLs remain the power supply voltage; the second address is traversed, and during a read operation, it is checked whether the corresponding WL (word line) of the address being read can be correctly selected and set to high voltage, while other unselected WLs remain 0; during a write operation, it is checked whether the corresponding WL of the address being written can be correctly selected and set to high voltage, while other unselected WLs remain 0; during a write operation, it is checked whether the corresponding CG (control gate) of the address being written can be correctly selected and set to high voltage, while other unselected CGs remain 0; during an erase operation, it is checked whether the corresponding EG (erase gate) of the address being erased can be correctly selected and set to high voltage, while other unselected EGs remain 0.
[0066] In this embodiment, by dividing the address into a first address and a second address, and traversing these addresses separately, the decoding logic for read, write, and erase operations can be accurately verified. By checking the state of selected and unselected signals under read, write, and erase operations respectively, the decoding logic is ensured to work correctly in various operation modes. Comprehensive checks of the decoding logic for the three operation modes (read, write, and erase) are supported, ensuring the comprehensiveness of the verification. Through systematic address traversal and signal state checks, errors that may be missed during the verification process are reduced.
[0067] Optionally, the address width to be traversed for read / write / erase decoding is determined as follows: Define the total address width of the FLASH memory, the address width in the X direction, the address width in the Y direction, and the number of FLASH memory arrays; based on the defined data, traverse the address decoding in the X and Y directions to obtain the address number to be generated; determine the address width to be traversed based on the address number.
[0068] In this embodiment, by defining the total address width, X-axis address width, Y-axis address width, and the number of memory arrays, the address width of different FLASH memory specifications can be flexibly configured. Based on the defined address width data, the address numbers to be traversed are automatically generated, reducing the workload of manual configuration and improving verification efficiency. Determining the address width to be traversed through the address numbers ensures that the traversed address range accurately covers all addresses requiring verification, thus improving verification accuracy.
[0069] In a specific embodiment, the address width required for read / write / erase decoding can be automatically calculated based on the set address parameters. When performing decoding checks on Flash memory of different capacities, the above function can be achieved simply by modifying the address parameters. Taking read mode as an example, three tasks are defined to traverse the address decoding in the X and Y directions and verify the decoding logic. First, the key parameters of the FLASH memory need to be defined, including the total address width, the X-direction address width, the Y-direction address width, and the number of memory arrays. For example: Awidth, the total address width, represents the total address length of the FLASH memory; XAwidth, the X-direction address width, represents the number of bits used for X-direction addressing; YAwidth, the Y-direction address width, represents the number of bits used for Y-direction addressing; midnum, the number of memory arrays, represents the number of memory arrays contained in the FLASH memory. Then, a task `sweep_read_xaddr` is defined to traverse the addresses in the X direction. This task calculates the total number of addresses in the X direction through a binary left shift operation, generates a random address, and assigns it to the X-direction part of the input signal A. It concurrently performs address assignment and reset operations, ensuring that the operation is completed within a specified time interval. Address setup and hold times are defined to ensure address signal stability. The time interval for each read operation is defined, conforming to the requirements of the FLASH operation manual. Next, a task `sweep_read_yaddr` is defined to traverse the addresses in the Y direction. This task first calculates the number of memory arrays to be traversed, calculates the total number of addresses in the Y direction through a binary left shift operation, generates the Y-direction address and the address of the control high-order bits respectively, and assigns them to the corresponding parts of the input signal A. It concurrently performs address assignment and reset operations, ensuring that the operation is completed within a specified time interval. Address setup and hold times are defined to ensure address signal stability. The time interval for each read operation is defined, conforming to the requirements of the FLASH operation manual. Finally, define the address generation task randomaddr, which takes an integer as input, representing the address number to be generated, and outputs a binary address with the same bit width as the FLASH address. The input integer is converted into a binary address for subsequent address assignment operations.
[0070] In this embodiment, by parameterizing the address width and the number of storage arrays, the address width of FLASH memory of different specifications can be flexibly configured. Through loop and concurrent structures, the address numbers to be traversed are automatically generated, reducing the workload of manual configuration and improving verification efficiency. Through binary left shift operations and loop control, the address range to be traversed is accurately calculated, ensuring the accuracy of verification.
[0071] Optionally, whether WL (Word Line), CG (Control Gate), EG (Erase Gate), SL (Source Line), and BL (Bit Line) are charged with high voltage depends on the actual operating voltage under different read, write, and erase states of the current FLASH memory. The results of the decoding logic check can be processed automatically by a script. Taking read decoding check as an example, the selected BLs can be sequentially output to specified files, such as addresses 0000, 0001, 0002, etc., and the selected BLs can be processed sequentially. <0> BL <1> BL <2> ...If discontinuous BL values are found in the output file, it indicates an error in the read / decode logic, and the circuit design needs to be checked for problems.
[0072] Optionally, the simulation netlist used in the read / write / erase decoding logic check process can be adjusted as follows: the target functional modules in the simulation netlist whose simulation time exceeds the preset time are designed using a hardware description language, and the target functional modules in the original simulation netlist are replaced with hardware description language modules; wherein, designing the target functional modules includes defining the enable signals, supply voltages and output voltages corresponding to the target functional modules in the form of hardware description language; the target functional modules include pump modules.
[0073] In this embodiment, by redesigning and implementing the target functional module (such as the pump module) with a long simulation time using a hardware description language, the simulation time can be significantly shortened. The optimized simulation netlist improves simulation efficiency, making the verification process more efficient. The functional module redesigned using a hardware description language has better versatility and maintainability, facilitating subsequent modifications and expansions. Defining enable signals, supply voltages, and output voltages using a hardware description language allows for more precise control of simulation conditions, ensuring the accuracy of simulation results.
[0074] In one specific embodiment, the pump module can be rewritten using Verilog-AMS to replace the original pump module inside the FLASH memory. Defining the enable signal, supply voltage, and output voltage of the pump module using Verilog allows for more precise control over its behavior, thereby shortening the high-voltage setup time. First, a module named `ideal_pump` is defined, containing three ports: enable signal (en), supply voltage (vdd), and output voltage (vout). The enable signal controls whether the module operates, the supply voltage provides the input voltage, and the output voltage is the module's output voltage. Electrical ports can also be defined using the keyword `electrical` to accommodate analog signals. Then, key parameters of the `ideal_pump` module are defined, such as: the specified high-voltage value `hv` to be reached; the module's threshold voltage `pump` to determine if the high-voltage condition has been met; the enable signal's threshold voltage `threshold` to determine if the enable signal is valid; the module's delay time `t_delay`, representing the delay from the change in the input signal to the change in the output signal; and the module's rise time `t_rise`, representing the transition time of the output voltage from low to high. Next, define electrical signals as variables to store input signal voltage values, such as `en_voltage`, which stores the enable signal voltage value, and `vdd_voltage`, which stores the supply voltage value. Finally, define the simulation behavior of the `ideal_pump` module, such as `V(en)` and `V(vdd)`, used to obtain the current values of the enable signal and supply voltage; an `if` condition is used: if the enable signal voltage is below a threshold and the supply voltage is above the threshold, the module's operation is executed; if the supply voltage is above the module's threshold (`pump`), a high voltage (`hv`) is output; otherwise, the supply voltage (`vdd_voltage`) is output; a `transition` function is used to define the output voltage change process, including delay time and rise time; if the condition is not met, the output voltage is set to 0.
[0075] In this embodiment, defining the pump behavior using Verilog allows for more precise control of the high-pressure build-up time, thereby shortening the high-pressure build-up time in the simulation. Replacing the traditional pump module with Verilog reduces the complexity of the simulation and improves simulation efficiency.
[0076] Optionally, the test mode check is performed as follows: confirm the test mode associated data to be written to the simulation file; the test mode associated data includes the test mode code, the applied voltage parameters and applied current parameters required for the test mode to run; establish the parameter mapping relationship between the test mode associated data and the simulation file, determine the target writing position and data format requirements of each test mode associated data in the simulation file; and write the identified test mode code, applied voltage parameters and applied current parameters to the corresponding target writing position in the simulation file according to the data format requirements.
[0077] In this embodiment, the test mode-related data (including test mode code, applied voltage parameters, and applied current parameters) is automatically written into the simulation file, reducing the workload of manual configuration. By establishing a parameter mapping relationship between the test mode-related data and the simulation file, the accuracy of the test mode configuration is ensured, improving the accuracy and consistency of the verification.
[0078] Combination Figure 4As shown, this disclosure provides a general verification platform 500, which stores program instructions. When executed, these instructions cause the general verification platform 500 to perform the verification method for FLASH memory described above, realizing read / write / erase function checks, read / write / erase decoding logic checks, or test mode checks of the FLASH memory. The file structure of the general verification platform 500 includes a netlist file, a measure file, a probe file, an option file, a parameter file, a task file, a template file, a configuration file, and a core script. The netlist file includes a netlist of the FLASH circuit, describing the interconnections between various components in the FLASH circuit. The measure file includes measurements of key AC and DC parameters in the operation manual for FLASH read / write / erase modes and low-power modes, as well as measurements of key analog quantities related to read / write / erase. The probe file includes measurements of the FLASH... The key voltages and currents to be checked in read / write / erase modes and test modes; the option file includes key options to be set for various FLASH operations; the parameter file contains parameter values based on the specific values for read timing, erase / write timing, power-on / off timing, and test mode timing determined in the FLASH operation manual; the task file writes the various input signals used for FLASH decoding logic timing, read timing, write timing, erase timing, and test mode timing into task syntax according to the corresponding timing requirements; the template file defines the modules, PVT, measure path, probe path, and option path to be called for FLASH simulation; the core script defines the functional options supported by the script, including the generation of simulation files and folders for read / write / erase function checks, read / write / erase decoding logic checks, and test mode checks.
[0079] In a specific embodiment, the probe file can contain certain specific signals or all signals under a certain module. The option file can contain settings for FLASH simulation or specific settings for a particular function, determined according to the actual needs of FLASH simulation. The parameters already present in the parameter file can cover various parameters in different FLASH operation manuals, ensuring universality. During corresponding read, write, erase, or test mode simulations, the script executes task statements, automatically generating FLASH decoding logic timings, read timings, write timings, erase timings, and test mode timings. For example, the read task mentioned in the above embodiment. The template file is a comprehensive file for configuring the FLASH simulation environment.
[0080] In a specific embodiment, the template file inc.sp can define information such as modules, processes, measurement paths, probe paths, and option paths required for simulation. In the template file inc.sp, the simulation command ".lib" is used to load module library files. `module_path` defines the path to the module library files, thereby loading module libraries such as tt, dio_tt, res_tt, mom_tt, and hv_tt. The types of module libraries include typical processes, digital I / O, resistors, metal oxides, and high-voltage modules. These module library files contain the device models and parameters required for simulation. Then, the process conditions required for simulation are defined, such as: `.temp 25c`, which sets the simulation temperature to 25°C; `.param vpower=1.2v`, which defines a parameter `vpower`, representing a power supply voltage of 1.2V; `VVDD VDD 0 pwl 0 0 0.5u vpower`, which defines a power supply voltage source VVDD connected to node VDD, using a piecewise linear (pwl) waveform to rise from 0V to vpower (1.2V) within 0.5 microseconds. It also needs to include other necessary path files, such as: .include, which represents the simulation instructions used to include other files; netlist_path, which contains the netlist file path for the FLASH memory; probe_path, which contains the probe file path used to define the signals to be monitored; measure_path, which contains the measurement file path used to define the parameters to be measured; and option_path, which contains the option file path used to define simulation options.
[0081] In this embodiment, the template file inc.sp integrates information such as the module library, process conditions, measurement paths, probe paths, and option paths required for simulation, ensuring the integrity and consistency of the simulation environment. After running the simulation command along with the template file inc.sp, various FLASH functions can be simulated.
[0082] Optionally, when performing test mode checks, add the required external voltage parameters for the test mode to the template file inc.sp. For example, in the template file inc.sp, define an external voltage value: .param vhvxver=10V, indicating that the external voltage value is 10V for the test mode. Then define an external voltage source: VVPP VPP 0 pwl 0 0 0.5uvhvxver, connected to node VPP, using a piecewise linear (pwl) waveform, rising from 0V to vhvxver (10V) in 0.5 microseconds.
[0083] In this embodiment, by defining the applied voltage value, the voltage conditions required for the test mode can be flexibly configured. However, during simulation test mode checks, there are usually about 50 test modes that need to be simulated. Different test modes require different applied voltages and currents, necessitating manual modification of inc.sp approximately 50 times. In this case, by simply defining the applied voltage required for all test modes in the file, the verification script can automatically write the voltage or current into the inc.cp file, greatly saving work efficiency. Specifically, different applied voltages or currents are defined according to different test modes. Running the script automatically selects the VPP voltage corresponding to the currently simulated test mode and adds it to the inc.cp file.
[0084] In one specific implementation, the first step is to set the corresponding applied voltage (VPP_in) based on the test mode. For example, using `switch -exact -- $mode`, the corresponding applied voltage value can be selected based on the test mode name. Then, `Return [list $VPP_in]` returns a list containing the applied voltage values. Next, the specified `inc.sp` file is updated, writing the applied voltage required for the test mode into the file. The target file is opened and read line by line. Each line is traversed, and when a keyword (such as "temp") is matched, the applied voltage definition is inserted into the next line. After closing the file, it is reopened in write mode to write the updated content.
[0085] Optionally, after the core script runs, you can choose from three options. For example, executing the option -function will enable the read, write, erase function to check the generation of simulation files and folders; executing -decode will enable the read, write, erase, decode logic to check the generation of simulation files and folders; and executing -testmode will enable the test mode to check the generation of simulation files and folders.
[0086] In one specific embodiment, to implement the core script's functionality, it is necessary to select the corresponding simulation list and PVT conditions based on user-input options ($function, $decode, $testmode). Commented lines in the list (lines starting with #) are ignored, and the final simulation list and PVT condition list are generated. Based on the final simulation list and PVT condition list, corresponding simulation files and folders are generated. By traversing the simulation list and PVT condition list, corresponding folders are created, PVT condition strings are parsed using regular expressions to extract process, voltage, and temperature information, VDD voltage and temperature parameters are defined, and the tb.v and inc.sp files are opened and read, with their contents written to a file in the target path.
[0087] In this embodiment, simulation files and folders are automatically generated via scripts, reducing the workload of manual configuration. It supports read / write / erase function checks, decoding checks, and test mode checks, and can select the appropriate simulation task based on user input.
[0088] The functions supported by the general verification platform provided in this disclosure are shown in Table 2, which includes the timing components of each function, such as read decode, program decode, erase decode, normal read, program (write), erase, block erase, chip erase, and testmode. All timing sequences are written in task modular form for easy calling between different functions. Taking read decode as an example, its corresponding timing includes: "power on + Y decode + power off" and "power on + main array X decode + NVR X decode + NVR_CFG X decode + ARRDN X decode + power off". The former represents "power on + Y direction decode + power off", and the latter represents "power on + main array X direction decode + non-volatile register X direction decode + non-volatile register configuration X direction decode + read-only register X direction decode + power off". The timing sequences corresponding to other functions can be referred to Table 2, and will not be repeated here. In addition, there are more than 20 different stress combinations in the test mode timing, which will not be described in detail here.
[0089] Table 2
[0090] Combination Figure 5 As shown, this disclosure provides a verification device 600 for FLASH memory, including a processor 601 and a memory 602. Optionally, the device may further include a communication interface 603 and a bus 604. The processor 601, communication interface 603, and memory 602 can communicate with each other via the bus 604. The communication interface 603 can be used for information transmission. The processor 601 can invoke logical instructions in the memory 602 to execute the verification method for FLASH memory described in the above embodiment.
[0091] Furthermore, the logic instructions in the aforementioned memory 602 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.
[0092] The memory 602, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 601 executes functional applications and data processing by running the program instructions / modules stored in the memory 602, thereby implementing the verification method for FLASH memory in the above embodiments.
[0093] The memory 602 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 602 may include high-speed random access memory and may also include non-volatile memory.
[0094] This disclosure provides a verification device, including: a verification device body, and the aforementioned verification apparatus or universal verification platform for FLASH memory. The verification apparatus or universal verification platform for FLASH memory is installed on the verification device body. The installation relationship described herein is not limited to placement inside the verification device, but also includes installation connections with other components of the verification device, including but not limited to physical connections, electrical connections, or signal transmission connections. Those skilled in the art will understand that the verification apparatus or universal verification platform for FLASH memory can be adapted to feasible verification device bodies to achieve other feasible embodiments.
[0095] This disclosure provides a computer-readable storage medium storing computer-executable instructions configured to perform the verification method for FLASH memory described above.
[0096] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this disclosure. The aforementioned storage medium can be a non-transitory storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code.
[0097] The foregoing description and accompanying drawings fully illustrate embodiments of this disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the terminology used in this application is for describing embodiments only and is not intended to limit the technical solutions described herein. As used in the technical solutions described herein, the singular forms “a,” “an,” and “the” are intended to equally include the plural forms unless the context clearly indicates otherwise. Similarly, the term “and / or” as used herein refers to any and all possible combinations of one or more of the associated listed elements. Additionally, when used in this application, the term "comprise" and its variations "comprises" and / or "comprising" refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.
[0098] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0099] The methods and products disclosed in the embodiments herein (including but not limited to devices and equipment) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0100] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
Claims
1. A verification method for FLASH memory, characterized in that, include: Based on the timing requirements of the target FLASH memory's operation manual, the signal timing is modeled in the form of executable tasks in a hardware description language, and the key time intervals between signals are defined as configurable parameters. Configure the executable tasks and key time intervals based on the parameter values entered by the user to adapt to the target FLASH memory; Based on the configured executable tasks and key time intervals, simulation data is generated, and the design under test of the target FLASH memory model is simulated based on the simulation data; the design under test includes read / write / erase function checks, read / write / erase decoding logic checks, or test mode checks; During the simulation, the timing signals, voltage signals, and decoding logic signals in the design under test are checked according to the parameterized timing requirements.
2. The verification method according to claim 1, characterized in that, Modeling signal timing in the form of executable tasks using a hardware description language includes: Determine the basic timing sequence in the signal timing sequence; Based on the basic timing sequence, other timing sequences in the signal timing sequence are determined according to the time interval parameter.
3. The verification method according to claim 2, characterized in that, In the read mode signal timing, the basic timing is the RECALL signal; and / or, In the write mode signal timing, the basic timing is the PROG signal.
4. The verification method according to claim 1, characterized in that, Implement the address input in the signal timing as follows: All addresses to be verified are collected and stored in the same address file; The addresses in the address file are classified and identified based on address keywords to determine the type of each address and obtain the identification results. Based on the identification results, timing signals of different address types are generated according to the specified timing requirements.
5. The verification method according to claim 1, characterized in that, Implement read / write / erase decoding logic checks as follows: The address to be checked is divided into a first address and a second address; the address controlling the Y direction is defined as the first address, and the address controlling the X direction is defined as the second address; Traverse the first address and check if the selected BL is set to high voltage during a read operation, while other unselected BLs remain 0; check if the selected BL is set to a low-level voltage below the first voltage threshold during a write operation, while other unselected BLs remain the power supply voltage. Traverse the second address, checking whether the WL corresponding to the address read in this operation can be selected and set to high voltage, and other unselected WLs remain 0; check whether the WL corresponding to the address written in this operation can be selected and set to high voltage, and other unselected WLs remain 0; check whether the CG corresponding to the address written in this operation can be selected and set to high voltage, and other unselected CGs remain 0; check whether the EG corresponding to the address erased in this operation can be selected and set to high voltage, and other unselected EGs remain 0.
6. The verification method according to claim 5, characterized in that, The address width that needs to be traversed for read / write / erase decoding is determined as follows: Define the total address width of the FLASH memory, the address width in the X direction, the address width in the Y direction, and the number of FLASH memory arrays; Based on the defined data, the address decoding in the X and Y directions is traversed to obtain the address number that needs to be generated. The address width to be traversed is determined based on the address number.
7. The verification method according to claim 1, characterized in that, Implement test mode checks as follows: Confirm the test mode association data to be written to the simulation file; the test mode association data includes the test mode code, the applied voltage parameters and applied current parameters required for the test mode to run; Establish a mapping relationship between test mode associated data and simulation file parameters, and determine the target writing location and data format requirements of each test mode associated data in the simulation file; According to the data format requirements, the identified test mode code, applied voltage parameters, and applied current parameters are written to the corresponding target write location in the simulation file.
8. The verification method according to any one of claims 1 to 7, characterized in that, Use Verilog tasks to model signal timing.
9. A verification device for FLASH memory, comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to execute, when running the program instructions, the verification method for FLASH memory as described in any one of claims 1 to 8.
10. A universal verification platform, storing program instructions, characterized in that, When the program instructions are executed, they cause the general verification platform to perform the simulation verification method for FLASH memory as described in any one of claims 1 to 8, thereby realizing the read-write-erase function check, read-write-erase decoding logic check, or test mode check of the FLASH memory. The file structure of the general verification platform includes netlist files, measure files, probe files, option files, parameter files, task files, template files, configuration files, and core scripts. Netlist files include netlists of FLASH circuits, which are used to describe the interconnections between various components in the FLASH circuit. The measurement file includes measurements of key AC and DC parameters involved in the operation manual under FLASH read / write / erase modes and low power mode, as well as measurements of key analog quantities related to read / write / erase. The probe file includes the key voltages and currents that need to be checked in FLASH read / write / erase mode and test mode; The option file contains the key options that need to be set for various FLASH operations; The values of each parameter in the parameter file are determined based on the specific values of the read timing, erase timing, power-on / off timing, and test mode timing in the FLASH operation manual. The task file writes the various input signals used for FLASH decoding logic timing, read timing, write timing, erase timing, and test mode timing into task syntax according to the corresponding timing requirements. The template file defines the modules, PVT, measure path, probe path, and option path that the FLASH simulation needs to call; The core script defines the functional options supported by the script, including generating simulation files and folders for read-write-erase function checks, generating simulation files and folders for read-write-erase decoding logic checks, and generating simulation files and folders for test mode checks.