ECC verification method and device for automatic extraction and error injection

Abstract

The invention relates to an ECC (Error Correction Code) verification method and device for automatic extraction and error injection. A module integrated with an ECC function in a to-be-verified chip and a bus interface signal are obtained through a script, a signal path capable of monitoring transmission and error injection is obtained, verification parameters of a test case file are generated, and verification of the ECC function integrated by each module is realized. The verdei built-in script tool and the compiled python script are utilized to simplify the extraction process of the signal information, so that the verification efficiency is improved, and the reusability and sufficiency of verification can also be improved.

Description

Technical Field

[0001] The invention belongs to the technical field of chip verification, and relates to an ECC verification method and device for automatic extraction and error injection. Background Art

[0002] Error Correcting Code (ECC) technology can detect errors during data transmission by adding additional checksum information to the data, thereby improving the reliability of data transmission. As the interaction between modules in the system chip becomes more and more complex, integrating ECC on the bus interface of the module can improve the integrity of data transmission between modules to a certain extent and reduce the failure caused by errors. In the design architecture of the system chip, ECC will be instantiated by multiple modules (such as hosts such as processor cores and DMA controllers, and slaves such as peripherals and storage). By injecting errors into the interface signals of the slave modules, it can be verified whether the ECC integrated by the host and the slave can correctly handle the errors generated during data transmission. Therefore, the slave modules such as peripherals and storage that instantiate the ECC function are the target modules for error injection. However, how to quickly and accurately identify and extract the target module and its bus interface information to improve the efficiency of ECC verification integrated by the host and the slave is still one of the technical problems to be solved. Summary of the invention

[0003] In response to the problems existing in the above-mentioned traditional testing methods, the present invention proposes an ECC verification method with automated extraction and error injection and an ECC verification device with automated extraction and error injection, which can quickly and accurately identify and extract the target module and its bus interface information, thereby improving the efficiency of ECC verification of host and slave integration.

[0004] In order to achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: On the one hand, there is provided an ECC verification method for automated extraction and error injection, comprising the steps of: Use the built-in Tcl script getModIO.tcl of verdi to obtain the location information and interface signals of all modules in the design architecture of the chip to be verified, and output the getModIO.log file; Use the python script to parse the getModIO.log file and obtain the location information of the target module; Use the built-in Tcl script listModFiles.tcl of Verdi to obtain the names of all module definitions in the design architecture and the locations where the design code text files of the modules are stored, and output the listModFiles.log file; Use Python script to parse the listModFiles.log file and obtain the ECC interface signal of the target module; Use the python script to splice the ECC interface signal in the target module with the module location information to obtain the hierarchical path of the ECC interface signal of the target module; Use the python script to match the obtained ECC interface signal with the signal of the target module in the getModIO.log file to obtain the bit width information of the ECC interface signal; the bit width information is used to determine the error range of the ECC interface signal; Use Python script to create a test case file and write the hierarchical path and error range of the ECC interface signals of all target modules; Use the test case file to carry out ECC function verification of each target module integration and output the ECC function verification results.

[0005] On the other hand, an ECC verification device for automatic extraction and error injection is also provided, comprising: The module information acquisition module is used to use the built-in Tcl script getModIO.tcl of verdi to obtain the location information and interface signals of all modules in the design architecture of the chip to be verified, and output the getModIO.log file; The target location acquisition module is used to parse the getModIO.log file using a python script to obtain the location information of the target module; The module location acquisition module is used to use the built-in Tcl script listModFiles.tcl of Verdi to obtain the names of all module definitions in the design architecture and the storage locations of the module design code text files, and output the listModFiles.log file; The interface signal acquisition module is used to parse the listModFiles.log file using a python script to obtain the ECC interface signal of the target module; The interface path acquisition module is used to use a python script to splice the ECC interface signal in the target module with the module's location information to obtain the hierarchical path of the ECC interface signal of the target module; The signal bit width acquisition module is used to use a python script to match the acquired ECC interface signal with the signal of the target module in the getModIO.log file to obtain the bit width information of the ECC interface signal; the bit width information is used to determine the error range of the ECC interface signal; The test case creation module is used to create a test case file using a Python script and write the hierarchical path and error range of the ECC interface signals of all target modules. The functional verification module is used to carry out ECC functional verification of each target module integration using the test case file and output the ECC functional verification results.

[0006] One of the above technical solutions has the following advantages and beneficial effects: The above-mentioned ECC verification method and device for automatic extraction and error injection obtains the module and bus interface signals of the chip to be verified with integrated ECC functions by using scripts, obtains the signal path that can monitor transmission and error injection, generates verification parameters of the test case file, and realizes the verification of the integrated ECC function of each module. The signal information extraction process is simplified by using the built-in script tool of Verdi and the written Python script, which not only improves the efficiency of verification, but also improves the reusability and sufficiency of verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the conventional technology, the drawings required for use in the embodiments or the conventional technology descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0008] Figure 1 A schematic diagram of a flow chart of an ECC verification method for automated extraction and error injection in one embodiment; Figure 2 A schematic diagram of the overall workflow of an ECC verification method for automated extraction and error injection in one embodiment; Figure 3 A schematic diagram of an ECC function verification process integrated into each target module in an embodiment; Figure 4 A schematic diagram of a module framework of an ECC verification device for automated extraction and error injection in one embodiment. DETAILED DESCRIPTION

[0009] In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention is further described in detail below in conjunction with the accompanying drawings and Examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those generally understood by those skilled in the art of the present invention. The terms used in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0010] It should be noted that referring to "embodiment" in this document means that the specific features, structures, or characteristics described in connection with the embodiment may be included in at least one embodiment of the present invention. The phrase shown at various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art can understand that the embodiments described herein can be combined with other embodiments. The term "and / or" used in the specification and appended claims of the present invention refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0011] The following will describe in detail the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention.

[0012] To verify the ECC function of the target module using the error injection method, the parameters to be obtained include: the location information of the target module (i.e., the hierarchical path of the module relative to the top-level module in the design architecture), the ECC interface signals of the target module (i.e., the input and output signals for the module to interact with the ECC function, including control signals, address signals, data signals, and ECC encoding signals), and the bit width of the ECC interface signals (the signal error injection range can be obtained based on the bit width information). Relying on manual search for the location information of all target modules and positioning the ECC interface information within the module not only involves a huge workload but also easily leads to omissions due to human negligence. In view of this, an innovative optimization method is needed, which can automatically and quickly and accurately identify and extract the target module and its bus interface information and store it in the bus ECC test case as verification parameters for monitoring data transmission and random error injection, so as to improve the verification efficiency and reduce the potential risks brought by manual operations.

[0013] In one embodiment, as Figure 1 shown, an ECC verification method for automatic extraction and error injection is provided, which may include the following steps S10 to S24: S10, use the built-in Tcl script getModIO.tcl in verdi to obtain the location information and interface signals of all modules in the design architecture of the chip to be verified, and output the getModIO.log file.

[0014] It can be understood that first, the location information and interface signals of all modules in the design architecture of the chip to be verified are obtained, and the getModIO.log file is output. The built-in Tcl script "getModIO.tcl" of Verdi can be used to obtain the signal properties (width, input / output) of the hierarchical paths and ports of all module instances, and output the getModIO.log file (a log file). Among them, in Verdi (that is, Synopsys's debugging tool), "getModIO.tcl" is a built-in Tcl script used to obtain the module input / output information (Module Input / Output, referred to as ModIO) in the design. Tcl (Tool Command Language) is a commonly used scripting language in EDA (Electronic Design Automation) tools such as VCS and Verdi, which is used for automated tasks and debugging.

[0015] S12, use the python script to parse the getModIO.log file and obtain the location information of the target module.

[0016] Then, get the location information of the target module from the getModIO.log file. You can use a python script to parse the getModIO.log file and filter the instances of the ECC module and their hierarchical paths. Get the name and hierarchical path of the upper module according to the hierarchical path of the ECC module instance. The upper module is the module of the instantiated ECC, that is, the target module to be found, and its hierarchical path is the location information of the target module.

[0017] S14, use the built-in Tcl script listModFiles.tcl of Verdi to obtain the names of all module definitions in the design architecture and the locations where the design code text files of the modules are stored, and output the listModFiles.log file.

[0018] Next, get the location of the design code files corresponding to all modules in the design architecture. You can use the built-in Tcl script "listModFiles.tcl" in verdi to get the location where all module definition names and their corresponding design code text files are stored, and output the listModFiles.log file. Among them, the Tcl script "listModFiles.tcl" is used to list files related to the design module, such as: module source code files (such as Verilog and VHDL files), module configuration files or constraint files, module simulation or synthesis scripts. The listModFiles.log file is a log file of the Tcl script "listModFiles.tcl", which records the output results of the script, including: module name and its corresponding file path, file version and timestamp information.

[0019] S16, use the python script to parse the listModFiles.log file and obtain the ECC interface signal of the target module.

[0020] Then, obtain the ECC interface signal of the target module from the listModFiles.log file. You can use a python script to parse the listModFiles.log file, and match the name of the target module obtained from the getModIO.log file with the module name in the file content of the listModFiles.log file in turn to obtain the storage location of the design code file of the target module. You can use a python script to open and parse the design code file to obtain the input and output signals used in the target module to interact with the internally integrated ECC function, which is the ECC interface signal of the target module.

[0021] S18, using a python script to splice the acquired ECC interface signal in the target module with the module position information to obtain a hierarchical path of the ECC interface signal of the target module.

[0022] S20, using a python script to match the obtained ECC interface signal with the signal of the target module in the getModIO.log file, and obtain the bit width information of the ECC interface signal; the bit width information is used to determine the error range of the ECC interface signal.

[0023] Then, the hierarchical path and error range of the ECC interface signal in the target module are obtained. The obtained ECC interface signal in the target module can be spliced ​​with the module location information using a python script to obtain the hierarchical path of the ECC interface signal of the target module. Use a python script to match the obtained ECC interface signal with the signal of the target module in the getModIO.log file to obtain the bit width information of the ECC interface signal in order to configure the number of error injections of the ECC interface signal.

[0024] S22, use the python script to create a test case file, and write the hierarchical path and error annotation range of the ECC interface signals of all the target modules obtained.

[0025] S24, using the test case file to carry out ECC function verification of each target module integration, and outputting the ECC function verification result.

[0026] Finally, create test cases and verify the ECC function integrated in each target module. You can use Python scripts to create test case files, write the ECC interface signals (address signal path, read and write data signal path, ECC check code path) and bit width information of all target modules, and use the test case files to verify the ECC function integrated in each target module. The ECC function verification result is whether the ECC modules of the host and slave correctly generate and decode the check information. The overall workflow is as follows: Figure 2 shown.

[0027] The above-mentioned ECC verification method of automated extraction and error injection uses scripts to obtain the module and bus interface signals of the chip to be verified that integrates the ECC function, obtains the signal path that can monitor transmission and error injection, generates verification parameters for test case files, and realizes the verification of the ECC function integrated in each module. Using the built-in scripting tool of Verdi and the written Python script to simplify the extraction process of signal information not only improves the efficiency of verification, but also improves the reusability and adequacy of verification.

[0028] In one embodiment, regarding the above step S20, further processing steps may be included: The random constraint conditions of ECC interface signal injection errors are generated by using the bit width information of the ECC interface signal; the random constraint conditions include the number and injection positions of the signal injection errors, and the number of signal injection errors in a single transmission ranges from 0 to 2.

[0029] It can be understood that in this embodiment, the bit width information of the ECC interface signal is used to further generate random constraints for ECC interface signal injection errors. The random constraints may include the number and injection positions of the signal injection errors, and the number of signal injection errors in a single transmission may range from 0 to 2, so as to achieve more efficient verification through relatively random injection error positions. The random constraints are written into the created test case file together with the ECC interface signal for use during verification.

[0030] In one embodiment, regarding the above step S24, the process of using the test case file to carry out the ECC function verification of each target module integration may specifically include the following processing steps: The host is used as the data receiving end to read the register data of the target module, and the target module is used as the data sending end to transmit the read data; When the monitoring and error injection module detects that the control signal of the target module generates a valid transmission, the error injection bit of the address, read data or ECC check code output by the port of the target module is randomly inverted through backdoor access; If the number of misaligned bits is not 0, check whether the host verification error alarm is triggered after the host receives the data.

[0031] It can be understood that the ECC function verification process integrated into each target module can be specifically as follows Figure 3 As shown, specifically, the host reads the register data of the target module as the data receiving end, and the target module transmits the read data as the data sending end. When the monitoring and error injection module instantiated in the test case detects that the control signal of the target module generates a valid transmission, the error injection bit of the address, read data or ECC check code output by the port of the target module is randomly inverted through backdoor access. If the number of injection errors is not 0, then check whether the host verification error alarm is triggered after the host receives the data, and verify whether the ECC module of the host correctly decodes the verification information and whether the ECC module of the slave correctly generates the verification information. If the number of injection errors is 0, then check that the data is transmitted correctly and no error alarm is triggered.

[0032] In one embodiment, regarding the above step S24, the process of using the test case file to carry out the ECC function verification of each target module integration may further include the following processing steps: The host is used as the data transmitter to write data to the target module register, and the target module is used as the data receiver; When the monitoring and error injection module detects that the control signal of the target module generates a valid transmission, the error injection bit of the address, write data or ECC check code of the port input to the target module is randomly inverted through backdoor access; If the number of misaligned bits is not 0, check whether the target module triggers a slave check error alarm after receiving the data.

[0033] like Figure 3 As shown, specifically, the host acts as a data transmitter to write data to the register of the target module, and the target module acts as a data receiver. When the monitoring and error injection module detects that the control signal of the target module generates a valid transmission, the error injection bit of the address, write data or ECC check code of the port input to the target module is randomly inverted through backdoor access. If the number of injection errors is not 0, then check whether the slave check error alarm is triggered after the target module receives the data, and verify whether the ECC module of the host correctly decodes the check information and whether the ECC module of the slave correctly generates the check information. If the number of injection errors is 0, then check that the data is transmitted correctly and no error alarm is triggered.

[0034] It should be understood that although Figures 1 to 3 The steps in the method are shown in sequence as indicated by the arrows, but the steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of the steps, and the steps can be executed in other orders. Figures 1 to 3 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequentially, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0035] In one embodiment, Figure 4As shown, an ECC verification device 100 for automatic extraction and error annotation is provided, which may include a module information acquisition module 11, a target position acquisition module 13, a module position acquisition module 15, an interface signal acquisition module 17, an interface path acquisition module 19, a signal width acquisition module 21, a use case creation module 23 and a function verification module 25. Among them, the module information acquisition module 11 is used to use the built-in Tcl script getModIO.tcl of verdi to obtain the location information and interface signals of all modules in the design architecture of the chip to be verified, and output the getModIO.log file. The target position acquisition module 13 is used to use the python script to parse the getModIO.log file to obtain the location information of the target module. The module position acquisition module 15 is used to use the built-in Tcl script listModFiles.tcl of verdi to obtain the location where all module definition names and the design code text files of the modules are stored in the design architecture, and output the listModFiles.log file. The interface signal acquisition module 17 is used to use the python script to parse the listModFiles.log file to obtain the ECC interface signal of the target module. The interface path acquisition module 19 is used to use a python script to splice the ECC interface signal in the target module with the module's location information to obtain the hierarchical path of the ECC interface signal of the target module. The signal bit width acquisition module 21 is used to use a python script to match the acquired ECC interface signal with the signal of the target module in the getModIO.log file to obtain the bit width information of the ECC interface signal; the bit width information is used to determine the error range of the ECC interface signal. The use case creation module 23 is used to create a test case file using a python script, and write the hierarchical path and error range of the ECC interface signals of all the target modules obtained. The function verification module 25 is used to use the test case file to carry out the ECC function verification of each target module integration, and output the ECC function verification result.

[0036] The above-mentioned automatic extraction and error injection ECC verification device 100 obtains the module and bus interface signals of the ECC function integrated in the chip to be verified by using scripts, obtains the signal path that can monitor transmission and error injection, generates verification parameters of the test case file, and realizes the verification of the ECC function integrated in each module. The signal information extraction process is simplified by using the built-in script tool of Verdi and the written Python script, which not only improves the efficiency of verification, but also improves the reusability and sufficiency of verification.

[0037] In one embodiment, the signal bit width acquisition module 21 is also used to generate random constraints on ECC interface signal injection errors using the bit width information of the ECC interface signal; the random constraints include the number and injection positions of the signal injection errors, and the number of signal injection errors in a single transmission ranges from 0 to 2.

[0038] In one embodiment, in the process of the functional verification module 25 using the test case file to carry out the ECC functional verification of each target module integration, it is also used to use the host as the data receiving end to read the target module register data and use the target module as the data sending end to transmit the read data. When the monitoring and error injection module detects that the control signal of the target module generates a valid transmission, the error injection bit of the address, read data or ECC check code output by the port of the target module is randomly inverted through the backdoor access. If the number of error injection bits is not 0, then check whether the host verification error alarm is triggered after the host receives the data.

[0039] In one embodiment, the function verification module 25 uses the test case file to carry out the ECC function verification of each target module integration, and is also used to use the host as the data sending end to write data to the target module register, and the target module as the data receiving end. When the monitoring and error injection module detects that the control signal of the target module generates a valid transmission, the address of the port input to the target module, the write data or the error injection bit of the ECC check code is randomly inverted through the backdoor access. If the number of injection error bits is not 0, then check whether the slave check error alarm is triggered after the target module receives the data.

[0040] It can be understood that the explanation of each feature in the above-mentioned automatic extraction and error injection ECC verification device 100 can be understood in the same way as the corresponding explanations in each embodiment of the above-mentioned automatic extraction and error injection ECC verification method. Each module in the above-mentioned automatic extraction and error injection ECC verification device 100 can be fully or partially implemented by software, hardware and a combination thereof. The above-mentioned components can be embedded in or independent of a device with data processing functions in the form of hardware, or can be stored in the memory of the aforementioned device in the form of software, so that the processor can call and execute the operations corresponding to the above modules. The aforementioned device can be, but is not limited to, various types of chip verification computers already available in the art.

[0041] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided by the present invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus dynamic random access memory (RambusDRAM, referred to as RDRAM) and interface dynamic random access memory (DRDRAM).

[0042] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0043] The above embodiments only express several implementation methods of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of protection of the invention. It should be pointed out that, for those of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present invention, which all belong to the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the attached claims.

Claims

1. An automated extraction and error injection ECC verification method, characterized in that: Includes steps: Use the built-in Tcl script getModIO.tcl of verdi to obtain the location information and interface signals of all modules in the design architecture of the chip to be verified, and output the getModIO.log file; Use the python script to parse the getModIO.log file to obtain the location information of the target module; Use the built-in Tcl script listModFiles.tcl of Verdi to obtain the names of all module definitions in the design architecture and the locations where the design code text files of the modules are stored, and output the listModFiles.log file; Use a python script to parse the listModFiles.log file to obtain the ECC interface signal of the target module; Use the python script to splice the ECC interface signal in the target module with the module location information to obtain the hierarchical path of the ECC interface signal of the target module; Use a python script to match the acquired ECC interface signal with the signal of the target module in the getModIO.log file to obtain the bit width information of the ECC interface signal; the bit width information is used to determine the error range of the ECC interface signal; Use Python script to create a test case file and write the hierarchical path and error range of the ECC interface signals of all target modules; The test case file is used to carry out ECC function verification of each target module integration, and the ECC function verification result is output.

2. The ECC verification method of automated extraction and error injection according to claim 1, characterized in that: The step of using a python script to match the acquired ECC interface signal with the signal of the target module in the getModIO.log file to obtain the bit width information of the ECC interface signal also includes: The random constraint conditions of ECC interface signal injection errors are generated by using the bit width information of the ECC interface signal; the random constraint conditions include the number and injection positions of the signal injection errors, and the number of signal injection errors in a single transmission ranges from 0 to 2.

3. The ECC verification method of automated extraction and error injection according to claim 1 or 2, characterized in that: The process of using the test case file to carry out the ECC function verification of each target module integration includes the following steps: The host is used as the data receiving end to read the register data of the target module, and the target module is used as the data sending end to transmit the read data; When the monitoring and error injection module detects that the control signal of the target module generates a valid transmission, the error injection bit of the address, read data or ECC check code output by the port of the target module is randomly inverted through backdoor access; If the number of misaligned bits is not 0, check whether the host verification error alarm is triggered after the host receives the data.

4. The ECC verification method of automated extraction and error injection according to claim 3, characterized in that: The process of using the test case file to carry out the ECC function verification of each target module integration also includes the steps of: The host is used as the data transmitter to write data to the target module register, and the target module is used as the data receiver; When the monitoring and error injection module detects that the control signal of the target module generates a valid transmission, the error injection bit of the address, write data or ECC check code of the port input to the target module is randomly inverted through backdoor access; If the number of misaligned bits is not 0, check whether the target module triggers a slave check error alarm after receiving the data.

5. An ECC verification device for automatic extraction and error injection, characterized in that: include: The module information acquisition module is used to use the built-in Tcl script getModIO.tcl of verdi to obtain the location information and interface signals of all modules in the design architecture of the chip to be verified, and output the getModIO.log file; A target location acquisition module is used to parse the getModIO.log file using a python script to obtain the location information of the target module; The module location acquisition module is used to use the built-in Tcl script listModFiles.tcl of Verdi to obtain the names of all module definitions in the design architecture and the storage locations of the module design code text files, and output the listModFiles.log file; An interface signal acquisition module is used to parse the listModFiles.log file using a python script to obtain the ECC interface signal of the target module; The interface path acquisition module is used to use a python script to splice the ECC interface signal in the target module with the module's location information to obtain the hierarchical path of the ECC interface signal of the target module; A signal bit width acquisition module is used to use a python script to match the acquired ECC interface signal with the signal of the target module in the getModIO.log file to obtain the bit width information of the ECC interface signal; the bit width information is used to determine the error injection range of the ECC interface signal; The test case creation module is used to create a test case file using a Python script and write the hierarchical path and error range of the ECC interface signals of all target modules. The function verification module is used to carry out the ECC function verification of each target module integration using the test case file and output the ECC function verification result.

6. The ECC verification device for automatic extraction and error injection according to claim 5, characterized in that: The signal bit width acquisition module is also used to generate random constraints for ECC interface signal injection errors using the bit width information of the ECC interface signal; the random constraints include the number and injection position of the signal injection errors, and the number of signal injection errors in a single transmission ranges from 0 to 2.

7. The ECC verification device for automatic extraction and error injection according to claim 5 or 6, characterized in that: In the process of the functional verification module using the test case file to carry out the ECC functional verification of each target module integration, the functional verification module is also used to read the target module register data using the host as the data receiving end and transmit the read data using the target module as the data sending end. When the monitoring and error injection module detects that the control signal of the target module generates a valid transmission, the error injection bit of the address, read data or ECC check code output by the port of the target module is randomly inverted through backdoor access. If the number of error injection bits is not 0, it is checked whether the host check error alarm is triggered after the host receives the data.

8. The ECC verification device for automatic extraction and error injection according to claim 7, characterized in that: In the process of the functional verification module using the test case file to carry out the ECC functional verification of each target module integration, the functional verification module is also used to write data to the target module register using the host as the data sending end, and the target module as the data receiving end. When the monitoring and error injection module detects that the control signal of the target module generates effective transmission, the address of the port input to the target module, the write data or the error injection bit of the ECC check code are randomly inverted through the backdoor access. If the number of the error injection bits is not 0, then it is checked whether the slave check error alarm is triggered after the target module receives the data.

Images