Automated extraction and injection error correction verification method and apparatus

Abstract

The application relates to an automatic extraction and error injection ECC verification method and device, a module integrated with an ECC function and a bus interface signal in a chip to be verified are acquired 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 in each module is realized. The extraction process of signal information is simplified by using a built-in script tool of verdi and a python script, the efficiency of verification is improved, and the reusability and sufficiency of verification are improved.

Description

TECHNICAL FIELD

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

[0002] Error Correcting Code (ECC) technology can detect errors in the data transmission process by adding additional check information to the data, thereby improving the reliability of data transmission. With the increasing complexity of the interaction mode of modules in a system chip, integrating ECC on the bus interface of a module can improve the integrity of data transmission between modules to some extent and reduce faults caused by errors. In the design architecture of a system chip, ECC is instantiated by multiple modules (such as host modules such as processor cores, DMA controllers, and slave modules such as peripherals and memories). 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 errors generated in the data transmission process. Therefore, the slave modules such as peripherals and memories that instantiate the ECC function are the target modules to be injected with errors. 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

[0003] In view of the problems in the above-mentioned traditional test method, the application provides an ECC verification method and device for automatic extraction and error injection, which can 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.

[0004] To achieve the above-mentioned purpose, the embodiments of the application adopt the following technical solutions:

[0005] On the one hand, an ECC verification method for automatic extraction and error injection is provided, comprising the following steps:

[0006] The position information and interface signals of all modules in the design architecture of the chip to be verified are obtained by using the built-in Tcl script getModIO.tcl of verdi, and a getModIO.log file is outputted;

[0007] The position information of the target module is obtained by using a python script to parse the getModIO.log file;

[0008] The design code text file of the module definition name and the storage position of all modules in the design architecture are obtained by using the built-in Tcl script listModFiles.tcl of verdi, and a listModFiles.log file is outputted;

[0009] The listModFiles.log file is parsed using a python script to obtain the ECC interface signal of the target module;

[0010] The ECC interface signal obtained in the target module is spliced with the position information of the module using a python script to obtain the hierarchical path of the ECC interface signal of the target module;

[0011] The ECC interface signal obtained is matched with the signal of the target module in the getModIO.log file using a python script 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;

[0012] A test case file is created using a python script, and the hierarchical path and error injection range of all the ECC interface signals of the target module obtained are written into the test case file;

[0013] The ECC function verification of each target module integration is carried out using the test case file, and the ECC function verification result is output.

[0014] On the other hand, an ECC verification device for automatic extraction and error injection is also provided, comprising:

[0015] A module information acquisition module is used to obtain the position information and interface signal of all modules in the design architecture of the chip to be verified using the built-in Tcl script getModIO.tcl of the verdi, and output the getModIO.log file;

[0016] A target position acquisition module is used to parse the getModIO.log file using a python script to obtain the position information of the target module;

[0017] A module position acquisition module is used to obtain the design code text file stored in the design architecture of all module definition names and module positions using the built-in Tcl script listModFiles.tcl of the verdi, and output the listModFiles.log file;

[0018] 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;

[0019] An interface path acquisition module is used to splice the ECC interface signal obtained in the target module with the position information of the module using a python script to obtain the hierarchical path of the ECC interface signal of the target module;

[0020] The signal bit width acquisition module is configured to use a python script to match the acquired ECC interface signal with the signal of the target module in the getModIO.log file, and acquire 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.

[0021] The use case creation module is configured to use a python script to create a test case file, and write the hierarchical path and error injection range of the ECC interface signal of all the target modules acquired.

[0022] The function verification module is configured to use the test case file to carry out ECC function verification of the integrated target modules, and output the ECC function verification result.

[0023] One of the above technical solutions has the following advantages and beneficial effects:

[0024] The above-described ECC verification method and device for automatic extraction and error injection have the following advantages and beneficial effects: BRIEF DESCRIPTION OF DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0026] Figure 1 The flowchart of the ECC verification method for automatic extraction and error injection in one embodiment;

[0027] Figure 2 The overall work flowchart of the ECC verification method for automatic extraction and error injection in one embodiment;

[0028] Figure 3 The ECC function verification flowchart of each target module in one embodiment;

[0029] Figure 4 The module framework diagram of the ECC verification device for automatic extraction and error injection in one embodiment. DETAILED DESCRIPTION

[0030] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not intended to limit the present application. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used in the specification of the present application are only for the purpose of describing the specific embodiments and are not intended to limit the present application.

[0031] It should be noted that the reference to "embodiments" herein means that the specific features, structures or characteristics described in conjunction with the embodiments can be included in at least one embodiment of the present application. The phrase is shown at various places in the specification does not necessarily refer to the same embodiment, nor is it mutually exclusive or alternative to 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 the appended claims means one or more of the associated listed items in any combination and all possible combinations, and includes these combinations.

[0032] The embodiments of the present application will be described in detail below in conjunction with the drawings of the embodiments of the present application.

[0033] In order to verify the ECC function of the target module by error injection, the parameters to be obtained include: the position information of the target module (i.e. the hierarchical path of the module in the design architecture relative to the top module), the ECC interface signal of the target module (i.e. the input and output signal of the module interacting with the ECC function, including the control signal, the address signal, the data signal and the ECC encoding signal) and the bit width of the ECC interface signal (based on the bit width information, the range of signal error injection can be obtained). Relying on manual search of the position information of all target modules and positioning of the ECC interface information in the module, not only the work is huge, but also the omission problem is easy to occur 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 them in the bus ECC test case as monitoring data transmission and random error injection verification parameters, so as to improve the verification efficiency and reduce the potential risks caused by human operation.

[0034] In one embodiment, as shown in Figure 1 An automatic extraction and error injection ECC verification method can be provided, which can include the following steps S10 to S24:

[0035] S10, use the built-in Tcl script getModIO.tcl of verdi to obtain the position information and interface signal of all modules in the design architecture of the chip to be verified, and output getModIO.log file.

[0036] It can be understood that first, the position information and interface signals of all modules in the design architecture of the chip to be verified are acquired, and a getModIO.log file is output. The Tcl script "getModIO.tcl" built in Verdi can be used to acquire the hierarchical path and signal properties (width, input / output) of the port of all module instances, and output the getModIO.log file (a log file). In Verdi (a debugging tool of Synopsys), "getModIO.tcl" is a built-in Tcl script for acquiring the module input / output information (Module Input / Output, abbreviated 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, and is used for automation tasks and debugging.

[0037] S12, the position information of the target module is acquired by using a python script to parse the getModIO.log file.

[0038] Then, the position information of the target module is acquired from the getModIO.log file. A python script can be used to parse the getModIO.log file to screen the instances of the ECC module and the hierarchical paths thereof. The name and hierarchical path of the upper module of the ECC module instance are acquired according to the hierarchical path of the ECC module instance. The upper module is the module instantiating the ECC, that is, the target module to be searched, and the hierarchical path thereof is the position information of the target module.

[0039] S14, the Tcl script listModFiles.tcl built in Verdi is used to acquire the design architecture all module definition names and the positions where the design code text files of the modules are stored, and output a listModFiles.log file.

[0040] Then, the location of the design code file corresponding to each module in the design architecture is obtained. The Tcl script "listModFiles.tcl" built in Verdi can be used to obtain the location where the design code text file corresponding to each module definition name is stored, and output the listModFiles.log file. The Tcl script "listModFiles.tcl" is used to list the files related to the design module, such as the source code file (e.g. Verilog and VHDL file) of the module, the configuration file or constraint file of the module, and the simulation or synthesis script of the module. The listModFiles.log file is the log file of the Tcl script "listModFiles.tcl", which records the output result of the script, and the content includes the module name and the corresponding file path, the version and timestamp information of the file.

[0041] S16, the ECC interface signal of the target module is obtained by parsing the listModFiles.log file using a python script.

[0042] Then, the ECC interface signal of the target module is obtained from the listModFiles.log file. The name of the target module obtained from the getModIO.log file can be matched with the module name in the file content of the listModFiles.log file using a python script to obtain the storage location of the design code file of the target module. The input and output signals used for interaction with the integrated ECC function in the target module can be obtained by opening and parsing the design code file using a python script, which are the ECC interface signals of the target module.

[0043] S18, the ECC interface signal of the target module obtained is spliced with the location information of the module using a python script to obtain the hierarchical path of the ECC interface signal of the target module.

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

[0045] Further, the hierarchical path and error injection range of the ECC interface signal in the target module are acquired. The acquired ECC interface signal in the target module and the position information of the module can be spliced using a python script to obtain the hierarchical path of the ECC interface signal of the target module. The acquired ECC interface signal is matched with the signal of the target module in the getModIO.log file using a python script to acquire the bit width information of the ECC interface signal so as to configure the error injection number of the ECC interface signal.

[0046] In S22, a test case file is created using a python script, and the acquired hierarchical path and error injection range of the ECC interface signal of all target modules are written.

[0047] In S24, the ECC function verification of the integration of each target module is carried out using the test case file, and the ECC function verification result is output.

[0048] Finally, the test case is created and the ECC function of the integration of each target module is verified. The test case file can be created using a python script, the ECC interface signal (address signal path, read and write data signal path, and ECC check code path) and bit width information of all target modules are written, the ECC function verification of the integration of each target module is carried out using the test case file, and the ECC function verification result is whether the host and slave ECC modules correctly generate check information and decode the check information. The overall workflow is as shown in Figure 2

[0049] The above-mentioned ECC verification method for automatic extraction and error injection can acquire the module and bus interface signal of the chip integrated with the ECC function to be verified, obtain the signal path that can monitor the transmission and error injection, generate the verification parameter of the test case file, and realize the verification of the ECC function of each module. The extraction process of the signal information is simplified by using the built-in script tool of the verdi and the python script written, which not only improves the verification efficiency, but also improves the reusability and sufficiency of the verification.

[0050] In one embodiment, in relation to the above-mentioned step S20, the further processing step can be included:

[0051] The random constraint condition of the error injection of the ECC interface signal is generated by using the bit width information of the ECC interface signal. The random constraint condition includes the number and injection position of the error injection bit of the signal, and the number of the error injection bit of the signal in a single transmission ranges from 0 to 2.

[0052] ​It can be understood that in the embodiment, the bit width information of the ECC interface signal is used to further generate a random constraint condition of error injection of the ECC interface signal. The random constraint condition can include the number and the injection position of the error injection bits of the signal, and the number of error injection bits of the signal in a single transmission can range from 0 to 2, so as to achieve more efficient verification through relatively random error injection positions. The random constraint condition is written into the created test case file together with the ECC interface signal, so as to be used in verification.

[0053] In one embodiment, in the process of carrying out the ECC function verification of the integrated target modules by using the test case file, the following processing steps can be included with respect to the above step S24:

[0054] The host is used as a data receiving end to read the register data of the target module, and the target module is used as a data sending end to transmit the read data.

[0055] When the monitoring and error injection module monitors the valid transmission of the control signal of the target module, the error injection bits of the address, the read data or the ECC check code output by the port of the target module are randomly inverted through the backdoor access.

[0056] 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.

[0057] It can be understood that the ECC function verification process of the integrated target modules can be specifically as shown in Figure 3 The host is used as a data receiving end to read the register data of the target module, and the target module is used as a data sending end to transmit the read data. When the monitoring and error injection module monitors the valid transmission of the control signal of the target module, the error injection bits of the address, the read data or the ECC check code output by the port of the target module are randomly inverted through the 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. The ECC module of the host can be verified whether it correctly decodes the check information, and the ECC module of the slave can be verified whether it correctly generates the check information. If the number of error injection bits is 0, it is checked whether the data is correctly transmitted and whether the error alarm is triggered.

[0058] In one embodiment, in the process of carrying out the ECC function verification of the integrated target modules by using the test case file, the following processing steps can be included with respect to the above step S24:

[0059] The host is used as a data sending end to write data into the register of the target module, and the target module is used as a data receiving end.

[0060] When the monitoring and error injection module monitors the control signal of the target module to generate valid transmission, the error injection bits of the address, write data or ECC check code of the input port of the target module are randomly inverted through backdoor access;

[0061] If the number of error injection bits is not 0, it is checked whether the target module triggers a slave check error alarm after receiving the data.

[0062] As shown in Figure 3 , specifically, the host as the data sending end writes data to the target module register, and the target module is the data receiving end. When the monitoring and error injection module monitors the control signal of the target module to generate valid transmission, the error injection bits of the address, write data or ECC check code of the input port of the target module are randomly inverted through backdoor access. If the number of error injection bits is not 0, it is checked whether the target module triggers a slave check error alarm after receiving the data. It can be verified 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 error injection bits is 0, it is checked whether the data is correctly transmitted and whether the error alarm is triggered.

[0063] It should be understood that, although Figures 1 to 3 each step is shown in sequence according to the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other orders. Moreover Figures 1 to 3 at least part of the steps of may include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily sequential, but can be executed in rotation or alternation with other steps or sub-steps or stages of other steps.

[0064] In one embodiment, as shown in Figure 4As shown, the automatic extraction and error injection ECC verification device 100 can 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 bit width acquisition module 21, a use case creation module 23, and a function verification module 25. The module information acquisition module 11 is configured to use the built-in Tcl script getModIO.tcl of the verdi to acquire the position information and interface signals of all modules in the design architecture of the chip to be verified, and output a getModIO.log file. The target position acquisition module 13 is configured to use a python script to parse the getModIO.log file to acquire the position information of the target module. The module position acquisition module 15 is configured to use the built-in Tcl script listModFiles.tcl of the verdi to acquire the design code text file storage location of the module definition name of all modules in the design architecture, and output a listModFiles.log file. The interface signal acquisition module 17 is configured to use a python script to parse the listModFiles.log file to acquire the ECC interface signals of the target module. The interface path acquisition module 19 is configured to use a python script to splice the acquired ECC interface signals in the target module with the position information of the module to obtain the hierarchical path of the ECC interface signals of the target module. The signal bit width acquisition module 21 is configured to use a python script to match the acquired ECC interface signals with the signal of the target module in the getModIO.log file to acquire the bit width information of the ECC interface signals, and the bit width information is used to determine the error injection range of the ECC interface signals. The use case creation module 23 is configured to use a python script to create a test case file, and write the acquired hierarchical path and error injection range of the ECC interface signals of all target modules. The function verification module 25 is configured to use the test case file to carry out ECC function verification of each target module integration, and output the ECC function verification result.

[0065] The automatic extraction and error injection ECC verification device 100 described above uses scripts to acquire the modules integrated with ECC functions and bus interface signals in the chip to be verified, obtains signal paths that can monitor transmission and error injection, generates verification parameters of a test case file, and realizes verification of the ECC functions of each module. The use of built-in script tools of the verdi and the written python scripts simplifies the extraction process of signal information, improves the efficiency of verification, and improves the reusability and sufficiency of verification.

[0066] In one embodiment, the signal bit width acquisition module 21 is further configured to use the bit width information of the ECC interface signals to generate random constraint conditions for error injection of the ECC interface signals, and the random constraint conditions include the number of error injection bits of the signals and the injection positions, and the number of error injection bits of the signals in a single transmission ranges from 0 to 2.

[0067] In one embodiment, the function verification module 25, in the process of carrying out the ECC function verification of each target module integration with the test case file, is further configured to read the register data of the target module as a data receiving end of the host, transmit the read data as a data sending end of the target module, and when the monitoring and error injection module monitors the valid transmission of the control signal of the target module, access the address, read data or error injection bit of the ECC check code output by the port of the target module through the backdoor to invert, if the number of error injection bits is not 0, then check whether the host triggers a host check error alarm after receiving the data.

[0068] In one embodiment, the function verification module 25, in the process of carrying out the ECC function verification of each target module integration with the test case file, is further configured to read the register data of the target module as a data receiving end of the host, transmit the read data as a data sending end of the target module, and when the monitoring and error injection module monitors the valid transmission of the control signal of the target module, access the address, read data or error injection bit of the ECC check code output by the port of the target module through the backdoor to invert, if the number of error injection bits is not 0, then check whether the host triggers a host check error alarm after receiving the data.

[0069] It can be understood that the above explanation of the features of the ECC verification device 100 for automatic extraction and error injection can be understood in the same way as the corresponding explanation of the above-mentioned embodiments of the ECC verification method for automatic extraction and error injection. Each module in the above-mentioned ECC verification device 100 for automatic extraction and error injection can be realized by software, hardware and their combination. The above-mentioned components can be embedded in or independent of a device with data processing function in hardware form, or stored in the memory of the above-mentioned device in software form, so as to be called and executed by the processor to perform the operation corresponding to each module. The above-mentioned device can be, but is not limited to, various chip verification computers in the prior art.

[0070] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when the computer program is executed, the processes of the above-mentioned embodiment methods can be included. Any reference to memory, storage, database or other medium used in the embodiments provided by the present application 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 but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus dynamic random access memory (Rambus DRAM, RDRAM for short) and interface dynamic random access memory (DRDRAM).

[0071] Any combination of the technical features of the above embodiments can be made. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described, however, as long as the combination of the technical features does not exist, it should be considered as the scope of the present application.

[0072] The above embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the protection scope of the present application. It should be pointed out that for those skilled in the art, without departing from the concept of the present application, some modifications and improvements can be made, which all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. An automated method of extracting and injecting ECC verification of errors, characterized by, The method comprises the steps of: acquiring the position information and interface signals of all modules in the design architecture of the chip to be verified by using a built-in Tcl script getModIO.tcl of the verdi, and outputting a getModIO.log file; acquiring the position information of the target module by parsing the getModIO.log file by using a python script; acquiring the design code text file of the module definition name and the storage position of the module by using a built-in Tcl script listModFiles.tcl of the verdi, and outputting a listModFiles.log file; acquiring the ECC interface signals of the target module by parsing the listModFiles.log file by using a python script; splicing the ECC interface signals of the target module and the position information of the module to obtain the hierarchical path of the ECC interface signals of the target module by using a python script; matching the ECC interface signals and the signals of the target module in the getModIO.log file to obtain the bit width information of the ECC interface signals by using a python script; the bit width information is used to determine the error injection range of the ECC interface signals; creating a test case file by using a python script, and writing the hierarchical path and the error injection range of the ECC interface signals of all the target modules; carrying out the ECC function verification of each target module by using the test case file, and outputting the ECC function verification result.

2. The automated extraction and injected ECC verification method of claim 1, wherein, The step of matching the ECC interface signals and the signals of the target module in the getModIO.log file to obtain the bit width information of the ECC interface signals further comprises the steps of: generating a random constraint condition of the ECC interface signal error injection by using the bit width information of the ECC interface signals; the random constraint condition comprises the number and the injection position of the error injection bits, and the number of the error injection bits in a single transmission ranges from 0 to 2.

3. The automated extraction and injected ECC verification method of claim 1 or 2, wherein, In the process of carrying out the ECC function verification of each target module by using the test case file, the steps of: reading the register data of the target module by taking the host as a data receiving end, and transmitting the read data by taking the target module as a data sending end; when the monitoring and error injection module monitors the valid transmission of the control signals of the target module, randomly inverting the error injection bits of the address, the read data or the ECC check code output from the port of the target module through a backdoor; if the number of the error injection bits is not 0, checking whether the host check error alarm is triggered after the host receives the data.

4. The automated extraction and injected ECC verification method of claim 3, wherein, In the process of carrying out the ECC function verification of each target module by using the test case file, the steps of: writing data into the register of the target module by taking the host as a data sending end, and taking the target module as a data receiving end; when the monitoring and error injection module monitors the valid transmission of the control signals of the target module, randomly inverting the error injection bits of the address, the write data or the ECC check code input into the port of the target module through a backdoor; if the number of the error injection bits is not 0, checking whether the slave check error alarm is triggered after the target module receives the data.

5. An automated extraction and injection error ECC verification apparatus, characterized by, The method comprises the steps of: A module information acquisition module is configured to acquire position information and interface signals of all modules in a design architecture of a chip to be verified by using a built-in Tcl script getModIO.tcl of the verdi, and output a getModIO.log file; A target position acquisition module is configured to acquire position information of a target module by using a python script to parse the getModIO.log file; A module position acquisition module is configured to acquire a module definition name and a storage position of a design code text file of a module by using a built-in Tcl script listModFiles.tcl of the verdi, and output a listModFiles.log file; An interface signal acquisition module is configured to acquire ECC interface signals of the target module by using a python script to parse the listModFiles.log file; An interface path acquisition module is configured to splice the ECC interface signals of the target module and the position information of the module to obtain a hierarchical path of the ECC interface signals of the target module by using a python script; A signal bit width acquisition module is configured to match the ECC interface signals and the signal of the target module in the getModIO.log file to acquire bit width information of the ECC interface signals by using a python script; the bit width information is used to determine a fault injection range of the ECC interface signals; A use case creation module is configured to create a test case file by using a python script, and write the hierarchical path and the fault injection range of the ECC interface signals of all the target modules into the test case file; A function verification module is configured to perform ECC function verification of integration of each target module by using the test case file, and output an ECC function verification result.

6. The automated extraction and injected ECC verification apparatus of claim 5, wherein, The signal bit width acquisition module is further configured to generate a random constraint condition of fault injection of the ECC interface signals by using the bit width information of the ECC interface signals; the random constraint condition includes a number of fault injection bits and an injection position, and the number of fault injection bits in a single transmission ranges from 0 to 2.

7. The automated extraction and injected ECC verification apparatus of claim 5 or 6, wherein, In the process of performing the ECC function verification of integration of each target module by using the test case file, the function verification module is further configured to read register data of the target module as a data receiving end of a host, and transmit the read data as a data sending end of the target module, and when a control signal of the target module is monitored and an effective transmission is generated, the error injection bits of an address, read data or an ECC check code output from a port of the target module are inverted through a backdoor, and if the number of the error injection bits is not 0, whether a host check error alarm is triggered after the data is received by the host is checked.

8. The automated extraction and injected ECC verification apparatus of claim 7, wherein, In the process of carrying out the ECC function verification of the integration of each target module by using the test case file, the function verification module is further configured to write data into the target module register by taking the host as a data sending end, take the target module as a data receiving end, take the backdoor to invert the error injection bits of the address, write data or ECC check code of the input port of the target module when monitoring and error injection module monitor that the control signal of the target module produces effective transmission, and if the number of error injection bits is not 0, check whether the target module triggers the slave check error alarm after receiving the data.

Images