CN112580282A - Method, apparatus, device and storage medium for integrated circuit design verification - Google Patents

Method, apparatus, device and storage medium for integrated circuit design verification Download PDF

Info

Publication number
CN112580282A
CN112580282A CN202011532364.6A CN202011532364A CN112580282A CN 112580282 A CN112580282 A CN 112580282A CN 202011532364 A CN202011532364 A CN 202011532364A CN 112580282 A CN112580282 A CN 112580282A
Authority
CN
China
Prior art keywords
verification
integrated circuit
function point
file
design
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202011532364.6A
Other languages
Chinese (zh)
Other versions
CN112580282B (en
Inventor
鄢传钦
王斌
张剑峰
陈俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Haiguang Information Technology Co Ltd
Original Assignee
Haiguang Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Haiguang Information Technology Co Ltd filed Critical Haiguang Information Technology Co Ltd
Priority to CN202011532364.6A priority Critical patent/CN112580282B/en
Publication of CN112580282A publication Critical patent/CN112580282A/en
Application granted granted Critical
Publication of CN112580282B publication Critical patent/CN112580282B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/33Design verification, e.g. functional simulation or model checking

Abstract

A method, apparatus, device, and storage medium for integrated circuit design verification. The method for integrated circuit design verification includes: acquiring a first function point in a register transmission level file, wherein a function set defined by the register transmission level file comprises the first function point and at least one second function point, the first function point is a function point needing to be verified, and the at least one second function point is a function point not needing to be verified; and carrying out error injection verification on the first functional point. The method for integrated circuit design verification can save the time of the whole error injection verification.

Description

Method, apparatus, device and storage medium for integrated circuit design verification
Technical Field
Embodiments of the present disclosure relate to a method, apparatus, device, and storage medium for integrated circuit design verification.
Background
As the complexity and scale of integrated circuit (e.g., system on chip) designs has increased, the complexity and importance of integrated circuit design verification has also increased. For example, throughout the cycle of an integrated circuit design, the verification effort takes much more time than the integrated circuit design. The ultimate goal of verification is to ensure that the design file or design code of the integrated circuit design is free from any error or bug (bug), i.e., the completeness of verification is achieved. Code coverage and functional coverage are commonly used as means for checking the quality of verification, but these coverage only check whether the test stimulus is sufficient, but do not guarantee that errors in the design are all detectable by the verification environment. If there are some vulnerabilities in the verification environment, even if the code coverage and the function coverage etc. reach the ideal values, there is no guarantee that there are no errors in the design code, which are usually fatal. The error injection method is used for judging whether the verification environment has a bug or not based on the passing condition of the test case by adding the error into the design code, checking whether the test case which can pass (pass) originally becomes fail (fail) or not and judging whether the verification environment has the bug or not.
Disclosure of Invention
Embodiments of the present disclosure provide a method, apparatus, device, and storage medium for integrated circuit design verification. The method for integrated circuit design verification can save the time of the whole error injection verification.
At least one embodiment of the present disclosure provides a method for integrated circuit design verification, the method comprising: acquiring a first function point in a register transmission level file, wherein a function set defined by the register transmission level file comprises the first function point and at least one second function point, the first function point is a function point needing to be verified, and the at least one second function point is a function point not needing to be verified; and carrying out error injection verification on the first functional point.
For example, in at least one embodiment of the present disclosure, a method for verifying an integrated circuit design is provided, where the register transfer level file includes design codes corresponding to the first function point in an implementation batch format, and performing error injection verification on the first function point includes: based on the first function point, performing error injection on the design code corresponding to the first function point and realizing the batch processing format; and verifying the first functional point by using the design codes and the test case files which are injected with errors and realize the batch processing format.
For example, in a method for integrated circuit design verification provided in at least one embodiment of the present disclosure, obtaining the first function point in the register transfer level file includes: and searching the design code for realizing the batch processing format in the register transmission level file to obtain the design code for realizing the batch processing format corresponding to the first function point.
For example, in the method for verifying an integrated circuit design provided in at least one embodiment of the present disclosure, the first functional point is an added functional point based on a register transfer level file of an existing design target, and the at least one second functional point is a functional point verified in the register transfer level file of the existing design target.
For example, in a method for verifying an integrated circuit design provided in at least one embodiment of the present disclosure, before performing error injection verification on the first functional point, the method includes: calling the test case file, wherein the test case file comprises test cases, and the test cases corresponding to the first functional points in the test cases are marked; and performing coverage analysis on the test cases of the test case file based on the register transfer level file.
For example, in a method for verifying an integrated circuit design provided in at least one embodiment of the present disclosure, verifying the first function point using the design code in the implementation batch format and the test case file with error injection includes: searching the marked test case corresponding to the first function point in the test case file; and performing regression testing on the error-injected design code in the batch processing realization format by using a testing tool based on the marked test case.
For example, in the method for verifying an integrated circuit design provided in at least one embodiment of the present disclosure, the result of the regression test is analyzed, and when errors injected in the design code implementing the batch processing format can be tested, the verification of the first functional point is ended.
For example, in the method for verifying an integrated circuit design provided in at least one embodiment of the present disclosure, when at least one of errors injected in the design code implementing the batch processing format is not tested, the test cases in the test case file are added, the design code implementing the batch processing format corresponding to the errors that are not tested is modified, and the coverage analysis is performed on the added test cases again.
For example, in the method for verifying an integrated circuit design provided in at least one embodiment of the present disclosure, based on a test case file after adding a test case, error injection verification is performed on the first function point again until injected errors can be tested.
For example, in a method for integrated circuit design verification provided in at least one embodiment of the present disclosure, performing, by using the test tool, the regression test on the design code in the implementation batch format for error injection based on the marked test cases includes: and generating an input file of the testing tool according to the design code for realizing the batch processing format and the marked test case, and performing the regression test on the design code for realizing the batch processing format injected by the error by using the testing tool according to the input file.
For example, in a method for integrated circuit design verification provided in at least one embodiment of the present disclosure, the generating an input file of the test tool according to the design code implementing the batch format and the marked test cases includes: the design code achieving the batch processing format and the marked test case are subjected to parameter processing to obtain a function point name needing error injection and a type needing error injection, a path corresponding to the function point needing error injection is obtained according to the function point name needing error injection, the macro definition of the design code achieving the batch processing format is written into a first input file, and the path defined by the macro in the first input file is updated to be the path corresponding to the function point needing error injection.
For example, in a method for integrated circuit design verification provided in at least one embodiment of the present disclosure, generating an input file of the test tool according to the design code in the implementation batch format and the marked test case, further includes: and according to the marked test case, obtaining the test case related to the functional point name needing error injection through the functional point name needing error injection, and generating a second input file according to the test case related to the functional point name needing error injection.
At least one embodiment of the present disclosure also provides an apparatus for integrated circuit design verification, the apparatus comprising: the device comprises a function point acquisition module and a verification module. The function point obtaining module is configured to obtain a first function point in a register transfer level file, where a function set defined by the register transfer level file includes the first function point and at least one second function point, the first function point is a function point that needs to be verified, and the at least one second function point is a function point that does not need to be verified. The verification module is configured to perform error injection verification on the first function point.
At least one embodiment of the present disclosure also provides an apparatus for integrated circuit design verification, the apparatus comprising a memory and a processor, wherein the memory has stored therein executable code that, when executed by the processor, causes the processor to perform a method for integrated circuit design verification as set forth in any of the preceding.
At least one embodiment of the present disclosure also provides a computer-readable storage medium having stored thereon executable code that, when executed by a processor, causes the processor to perform a method for integrated circuit design verification as described in any of the preceding.
According to the method for verifying the integrated circuit design, the first function point, namely the function point needing to be verified, is subjected to error injection verification, so that the error injection of the integrated circuit design verification is more targeted, design codes of the register transmission level file which are not concerned are eliminated, unnecessary error injection can be omitted, the time of the whole error injection verification is saved, and the verification completeness of the key path of the design codes of the register transmission level file is ensured while the verification period is shortened.
Drawings
To more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings of the embodiments will be briefly introduced below, and it is apparent that the drawings in the following description relate only to some embodiments of the present disclosure and are not limiting to the present disclosure.
Fig. 1 is a schematic flow chart of a method for integrated circuit design verification according to at least one embodiment of the present disclosure;
FIG. 2 is a flow chart illustrating a method for integrated circuit design verification according to at least one embodiment of the present disclosure;
FIG. 3 is a flow chart illustrating a method for integrated circuit design verification according to at least one further embodiment of the present disclosure;
FIG. 4 is a schematic diagram of an apparatus for integrated circuit design verification according to at least one embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of an apparatus for integrated circuit design verification according to at least one embodiment of the present disclosure; and
fig. 6 is a schematic diagram of a storage medium according to at least one embodiment of the present disclosure.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present disclosure more apparent, the technical solutions of the embodiments of the present disclosure will be described clearly and completely with reference to the drawings of the embodiments of the present disclosure. It is to be understood that the described embodiments are only a few embodiments of the present disclosure, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the described embodiments of the disclosure without any inventive step, are within the scope of protection of the disclosure.
Unless otherwise defined, technical or scientific terms used herein shall have the ordinary meaning as understood by one of ordinary skill in the art to which this disclosure belongs. The use of "first," "second," and similar terms in this disclosure is not intended to indicate any order, quantity, or importance, but rather is used to distinguish one element from another. Also, the use of the terms "a," "an," or "the" and similar referents do not denote a limitation of quantity, but rather denote the presence of at least one. The word "comprising" or "comprises", and the like, means that the element or item listed before the word covers the element or item listed after the word and its equivalents, but does not exclude other elements or items.
How well the verification environment of an integrated circuit design is to be tested by error injection. A test tool (e.g., Certitude) is an Electronic Design Automation (EDA) tool that helps to inject errors and report whether the errors can be detected by existing verification environments. The test tool uses test cases to perform error injection on the currently tested design code and performs regression testing on each injected error, if the test case fails, the injected error is marked as tested (detected), and if the test case injected with errors still passes (pass), the injected error is marked as untestable error (non-detected error).
After the integrated circuit design is completed in the first generation of products, subsequent generations of products are usually developed based on the architecture of the first generation of products, such as adding new functional points or further optimizing and improving on certain aspects of the products. Therefore, after the verification work of the first generation product is completed, most of the verification work in the subsequent products is to update the verification environment according to the new function point, add a new test case, and ensure the completeness of the verification of the new function point.
A test tool may be used to perform error injection on the design code of an integrated circuit design and check through regression testing whether each error is detectable by the verification environment. Before using the test tool, it is necessary (manually edited) to prepare an input file (or called a configuration file, which may include, for example, a certude _ hdl _ files. cer file, certude _ testcase. cer file, certude _ config. ce file, certude _ execute file, certude _ composition file, etc.) for the test tool to perform error injection verification based on the design code, test case, etc. of the integrated circuit design. The test tool performs error injection verification on the integrated circuit design based on the input file.
Injected errors can be significant if all code of an integrated circuit design is injected with errors, for example, a register-transfer level (RTL) file of an integrated circuit design may include 5000 lines (including many annotations) or more lines of design code, and injected errors may exceed 5000. The time cost is very large since a regression test needs to be performed for each error. This is a relatively blind practice, wasting a lot of time on the codes of the register transfer level files of less concern. For example, the design codes of register transfer level files that have been very mature or verified in the design files of previous generation products are verified for many iterations and verified on various systems, so to speak, without errors or bugs (bug free).
In addition, because the test tool needs to use the input files to perform error injection verification on the integrated circuit design, and the contents of the input files are different for each different integrated circuit design, the input files must be edited manually for different integrated circuit designs, and complete automation cannot be achieved.
At least one embodiment of the present disclosure provides a method for integrated circuit design verification, comprising: acquiring a first function point in a register transmission level file, wherein a function set defined by the register transmission level file comprises the first function point and at least one second function point, the first function point is a function point needing to be verified, and the at least one second function point is a function point not needing to be verified; and performing error injection verification on the first function point.
According to the method for verifying the design of the integrated circuit, provided by the embodiment of the disclosure, the error injection verification is performed on the first function point, namely the function point needing to be verified, so that the error injection of the design verification of the integrated circuit is more targeted, for example, the design codes of the register transmission level file which are not concerned at present are excluded, thereby saving unnecessary error injection, saving the time of the whole error injection verification, and further ensuring the verification completeness of the key path of the design codes of the register transmission level file while shortening the verification period.
Embodiments of the present disclosure and examples thereof are described in detail below with reference to the accompanying drawings.
Fig. 1 is a schematic flow chart of a method for integrated circuit design verification according to at least one embodiment of the present disclosure; the method for integrated circuit design verification provided by the embodiment of the present disclosure shown in fig. 1 includes steps S110 to S120.
Step S110: the method comprises the steps of obtaining a first function point in a register transmission level file, wherein a function set defined by the register transmission level file comprises the first function point and at least one second function point, the first function point is a function point needing verification, and the at least one second function point is a function point not needing verification.
For example, in the process of designing an integrated circuit (including a system-on-chip), an architecture definition including a system description and a Behavioral level (Behavioral) description and an architecture document are first written. The architecture documentation typically models the entire System in a high-level computer language (e.g., C or System C language specific to the design of an integrated circuit System), where the description of the functionality of each module is considered to reflect the behavioral functionality of that module. The design of the register transfer level file (i.e., RTL design) is then made based on the architecture definition. RTL designs use a hardware description language (a language capable of describing logic devices, such as Verilog HDL language or system Verilog language) to describe the functions of combinational logic devices and sequential logic devices, etc. based on the transfer between registers. For example, based on the above-mentioned functional description, a corresponding function set is defined in the register transfer level file, and the function set may include a plurality of function points, for example, the plurality of function points may include one or more first function points and one or more second function points, and may further include other function points.
For example, in some embodiments, the first function point is an added function point based on a register transfer level file of existing design goals. The second functional point is a functional point that has been verified in a register transfer level file of an existing design target. For example, the first function points are added function points on the basis of a previous version of the integrated circuit design or previous other integrated circuit designs, which require error injection verification. And the second function point is a function point in the set of functions of the register transfer stage file that was verified in the register transfer stage file of a previous version of the integrated circuit design or a previous other integrated circuit design, except the first function point. That is, the second function point is a mature function point, and the design code corresponding to the second function point has been verified and confirmed to have no error or bug (bug). The method for verifying the integrated circuit design provided by the embodiment of the disclosure does not perform error injection verification on the second function point any more, so as to avoid unnecessary work and further reduce verification time.
It should be noted that the function set defined by the register transfer level file may be a function point that converts the function, parameter, and performance of a logic device of an integrated circuit design from natural language splitting into individual functions that can be verified individually, and the disclosed embodiments are not limited to a specific function of each function point.
Step S120: and carrying out error injection verification on the first functional point. For example, the error injection verification is performed on the functional points needing to be verified in the register transmission level file in a targeted manner, so that the whole error injection verification time is saved, the verification period is shortened, and the verification completeness of the key path of the design code of the register transmission level file is ensured.
For example, in some embodiments, the register transfer level file includes design code corresponding to a first functional point that implements a batch format. The design code corresponding to the first function point is designed to realize a batch processing format to be distinguished from the design code of the second function point, so that the design code corresponding to the first function point is searched, and then error injection is performed on the design code corresponding to the first function point. For example, the design code implementing the batch format includes design code defined using macros. For example, in the process of a designer writing design code of a register transfer level file, a certain code style is followed, that is, the design code corresponding to a first function point (for example, the design code of a newly added function point) needs to be included in the macro definition. For example, assuming that the name of a first function point (e.g., a newly added function point) is "a," the following format should be written in the register transfer level file.
`ifdef A
<RTL logics>
`endif
It should be noted that other batch processing implementation formats may also be used to define the design code of the first function point, and the embodiment of the present disclosure is not limited thereto.
Fig. 2 is a flow chart illustrating a method for integrated circuit design verification according to at least another embodiment of the present disclosure. The method for integrated circuit design verification provided by the embodiment of the present disclosure shown in fig. 2 includes steps S210 to S240.
For example, before the error injection verification is performed on the first functional point, step S210 and step S220 shown in fig. 2 need to be performed.
Step S210: and calling the test case file, wherein the test case file comprises a test case, and the test case corresponding to the first functional point in the test case is marked. For example, the test case file is written by a verifier according to the architecture document, the verification environment, and the like. The test cases in the test case file are used for testing the set of functions defined by the register transfer level file. In order to test the first function point defined by the register transfer level file in a subsequent targeted manner, the test case corresponding to the first function point in the test case file needs to be marked, so that the marked test case can be found out.
Step S220: and performing coverage rate analysis on the test cases of the test case file based on the register transmission level file. For example, coverage is a means for measuring test integrity, and if coverage analysis is not performed on test cases, the test cases themselves are problematic, and other verification of the integrated circuit design using the test cases is meaningless. Through the result of the coverage rate analysis, whether the test is sufficient or not and what aspects the tested weak points are can be known, and further, how to design the test case capable of increasing the coverage rate can be known. For example, the coverage mainly includes code coverage, function coverage, and the like.
For example, step S120 shown in fig. 1 may be implemented as step S230 and step S240 in fig. 2.
Step S230: based on the first function point, error injection is performed on design code corresponding to the first function point that implements the batch processing format.
For example, in some embodiments, obtaining a first function point in a register transfer level file comprises: and searching the design code for realizing the batch processing format in the register transmission level file to obtain the design code for realizing the batch processing format corresponding to the first function point. For example, the design codes corresponding to the function points of the register transfer level file are searched one by one, and the design codes corresponding to the first function point (newly added function point) and having the format for realizing batch processing are found. Error injection is performed on the design code corresponding to the first function point in the implementation batch format, so that the number of error injections can be reduced.
Step S240: and verifying the first functional point by using the design codes which are injected by errors and realize the batch processing format and the test case file.
For example, in some embodiments, verifying the first functional point using the design code and the test case file implementing the batch format for error injection includes: searching a marked test case corresponding to the first function point in the test case file; and performing regression testing on the design codes which are injected by errors and realize the batch processing format by utilizing a testing tool based on the marked test cases.
For example, according to the foregoing, when the test case file is prepared, the test case for the first function point test is already marked, so that only the marked test case in the test case file needs to be searched. And performing regression testing on the design codes (corresponding to the first functional points) which are injected by the errors and realize the batch processing format based on the marked test cases by utilizing a testing tool (such as a certitude tool). The whole process of verifying the first functional point will be described in detail later with reference to fig. 3.
Fig. 3 is a flow chart illustrating a method for integrated circuit design verification according to at least one further embodiment of the present disclosure. The method for integrated circuit design verification provided by the embodiment of the present disclosure shown in fig. 3 includes steps S301 to S319.
Step S301: and defining the newly added function points in the architecture document. For example, a designer or integrated circuit design architect defines new functional points. That is, the architect proposes a function point that needs to be added, and writes a related document (e.g., an architecture document).
Step S302: and updating the verification environment according to the architecture document and compiling the test cases, wherein the test cases corresponding to the addition of the newly added function points are marked. For example, the verifier needs to add a mark of a function point in the added test case to associate the added test case with the newly added function point. For example, the pseudo code for the added test case may be as follows.
Figure BDA0002852423820000091
Figure BDA0002852423820000101
Step S303: the register transfer level file is written according to an architecture document, wherein a first functional point (i.e., an added functional point) in the register transfer level file uses macro-defined design code. Design code defined using macros is written, for example, in the following format.
`ifdef XXX
YYY
`endif
Where XXX is the name of a defined function point, YYY is the macro definition of the design code of the register transfer level file corresponding to the XXX function point, and the design code corresponding to the XXX function point is found by YYY.
Step S304: and finishing the design of the register level transmission file. For example, an integrated circuit design engineer and a verification engineer respectively modify the design codes of the register transfer level file according to the architecture document, for example, the newly added function point uses the design codes defined by the macro to complete the register transfer file.
Step S305: and completing the writing and updating of the test case and the verification environment, taking the new version of the register transmission level file, and starting debugging the test case. For example, after the design codes of the test case file and the register transfer file are written, the test case is subjected to coverage analysis in combination with the subsequent steps S306 to S310. For example, the test cases are debugged first until all the test cases are debugged, and coverage analysis such as code coverage and function coverage is started. When the ideal code coverage and function coverage are obtained, the coverage analysis is completed.
Step S306: and judging whether the test case fails to be debugged. When there is a test case in which the debugging does not pass, the flow proceeds to step S305. The verification environment (e.g., design code in test cases or register transfer level design files) is then amended and updated. For example, according to the reason that the test case fails to be debugged, the test case which does not pass the test case is written and updated. For example, the description of the design code of the register transfer level design file on the input parameters or output parameters of the logic device, etc. is modified. And debugging the updated test case again. When there is no test case debug failure, the flow proceeds to step S307.
Step S307: and debugging all test cases, and analyzing the code coverage rate and the function coverage rate. For example, analysis of code coverage and functional coverage may use a coverage analysis tool or write a coverage detection script, and embodiments of the present disclosure are not limited to the particular manner in which coverage analysis is employed.
Step S308: and judging whether the coverage rate reaches an ideal value. For example, according to the design requirements of the integrated circuit design, the designer sets a specific ideal value of the coverage rate, and the step S310 may be proceeded to (the coverage rate analysis is completed) only after the coverage rate reaches the ideal value. When the coverage does not reach the ideal value, the process proceeds to step S309.
Step S309: adding test cases, updating the test environment and debugging the added test cases. For example, after debugging the added test case, the process proceeds to step S307 again, analyzes the code coverage and the function coverage of the added test case, and then proceeds to step S308 to determine whether the coverage reaches an ideal value. Until the coverage reaches the desired value, the process proceeds to step S310 to complete the coverage analysis.
Then, the process proceeds to step S311: error injection verification is initiated. On the basis that the code coverage rate and the function coverage rate meet the requirements, whether a vulnerability exists in the verification environment is further checked, and the verification completeness of the key path of the design code corresponding to the first function point (such as a newly added function point) is guaranteed. The verification of the error injection to the first function point (e.g., the newly added function point) includes, for example, at least steps S311 to S319 in fig. 3.
Step S312: and searching the design code in the macro definition format in the register transfer level file to obtain the design code of the macro definition corresponding to the first function point. For example, design codes in the macro definition format in the register transfer level file are searched one by one, and the design codes corresponding to the macro definition of the first function point are found out for subsequent error injection verification.
Step S313: design code in a macro definition format in a register transfer level file is analyzed. For example, some macro definitions in the register transfer level file are analyzed to find design code that needs to be made with error injection. That is, the design code corresponding to the first functional point that requires error injection is found. For example, the error injection may be performed on the design code that needs to be subjected to the error injection, and then the regression test may be performed on the design code after the error injection based on the marked test case.
For example, in some embodiments, regression testing of error injected design code implementing a batch format based on flagged test cases using a test tool includes: generating an input file of a test tool according to the design code for realizing the batch processing format and the marked test case; and performing regression testing on the error-injected design codes in the batch processing format according to the input file by using a testing tool.
For example, as shown in fig. 3, the input files required by the testing tool are automatically generated by using an input file generation tool (e.g., a parse _ gen _ cer _ files tool) through steps S314 to S316, for example, the input files include a first input file, a second input file, a third input file, a fourth input file, and a fifth input file. The step S314 generates a first input file, the step S315 generates a second input file, and the step S316 generates third to fifth input files. The input file required by the test tool for the first function point is automatically generated by analyzing the design code and the test case file defined by the macro, so that the time for manually inputting the file can be saved, and the errors caused by manually editing the input file and the time required by manually editing the input file can be saved.
It should be noted that the input file generation tool (e.g., parse _ gen _ cer _ files tool) is implemented using python language, for example.
Step S314: the input file generation tool generates a first input file of the test tool and a compiling file list of the test functions according to the design codes of the macro definition format.
For example, in some embodiments, generating an input file for a test tool from design code implementing a batch format and labeled test cases includes: and carrying out parameter processing on the design codes for realizing the batch processing format and the marked test cases to obtain the names of the functional points needing to be subjected to error injection and the types of the errors needing to be injected. And according to the name of the functional point needing error injection, obtaining a path corresponding to the functional point needing error injection, writing the macro definition of the design code realizing the batch processing format into a first input file, and updating the path defined by the macro in the first input file into the path corresponding to the functional point needing error injection.
For example, the Get _ options function of the input file generation tool (e.g., parse _ gen _ cer _ files tool) performs parameter processing on the design code in the macro definition format and the marked test case, and obtains the name of the function point (or the name of the module where the function point is located) that needs to be injected with the error and the type of the error that needs to be injected. The type of error that needs to be injected is used to determine the type of error that is injected into the design code of the macro definition format. The pars _ rtl _ files function of the input file generation tool (such as pars _ gen _ cer _ files tool) obtains relevant design codes of the input file generation tool in a register transmission level file according to function point names and analyzes the design codes one by one, the design codes relevant to the function point names are added into a compiling list file (such as cer _ fileist), and if the design codes relevant to the function point names contain macro definitions of the function points, the macro definitions are written into a first input file (such as certude _ hdl _ files). For the initial compiling list of the register transfer level file, the path of the first functional point needs to be updated for the compiling of the subsequent testing tool. And searching whether the design code contained by the macro definition of the first function point (such as a newly added function point) exists by using an input file generation tool (such as a parse _ gen _ cer _ files tool), if so, modifying a path corresponding to the first function point in the compiling file list, and replacing the path corresponding to the function point needing error injection with the path corresponding to the function point needing error injection, so as to be used for injecting errors into the design code of the first function point subsequently. And adding the register transfer level file and the design code corresponding to the first functional point to a first input file (e.g., a certitude _ hdl _ files. Illustratively, the format of the first input file is as follows.
addsystemverilog–library=work–includepaths=<includepath>–file=<RTL file>–qualify–ignore=(0..100,200..)
Step S315: and the input file generation tool generates a second input file of the test tool according to the test case corresponding to the first function point.
For example, in some embodiments, generating an input file for a test tool from design code implementing a batch format and a marked test case further comprises: according to the marked test case, obtaining the test case related to the functional point name needing error injection through the functional point name needing error injection; and generating a second input file according to the test case related to the name of the functional point needing error injection.
For example, the Parse _ test _ files function of the input file generation tool (e.g., Parse _ gen _ cer _ files tool) gets all test cases related to the function point by searching for the name of the function point that needs to be error injected, and writes into a second input file (e.g., certitude _ testcases. That is, using an input file generation tool (e.g., parse _ gen _ cer _ files tool), all corresponding test cases are found according to the function point name matching that requires error injection, and the test cases are added to a second input file (e.g., certude _ testcases. Illustratively, the contents of the second input file are as follows.
addtestcase–testcase=<test_name>
Step S316: the input file generation tool generates a third input file, a fourth input file and a fifth input file of the test tool.
For example, the Gen _ cer _ config function of the input file generation tool (e.g., the parse _ Gen _ cer _ files tool) configures a third input file (e.g., the certude _ config. cer file) according to the type of errors that need to be injected. The Gen _ cer _ complex function of the input file generation tool (e.g., parse _ Gen _ cer _ files tool) writes a compile (complex) command into a fourth input file (e.g., certitude _ complex file), uses a compile list file (e.g., cer _ file) as its compile list, and adds a test tool-dependent PLI (Programming Language Interface, a mechanism for Verilog code to call C/C + + functions) library to compile options. The Gen _ cer _ execute function of the input file generation tool (e.g., parse _ Gen _ cer _ files tool) combines with the existing verification environment to write the command of running the test case and the script for judging whether the test case does not pass (fail) into the fifth input file (e.g., certitude _ execute file). The process proceeds to step S317 after the input file required by the test tool is generated.
Step S317: the test tool is started. For example, the error injected design code implementing the batch format is regression tested from the input file using a testing tool. The results of the regression tests are then analyzed.
Step S318: it is determined whether an error injected in the design code implementing the batch format can be tested.
For example, in some embodiments, the results of the regression testing are analyzed, and verification of the first function point is concluded when errors injected in the design code implementing the batch format can all be tested. For example, when the errors injected in the design code implementing the batch format can be tested, the process proceeds to step S319: the verification of the first function point (i.e., the newly added function point) is ended.
For example, if there is an error that cannot be tested out of the errors injected in the design code implementing the batch format, the process proceeds to step S309. For example, in some embodiments, when at least one of the errors injected in the design code implementing the batch processing format is not tested, the test cases in the test case file are added, the design code implementing the batch processing format corresponding to the errors that are not tested is modified, and the coverage analysis is performed again on the added test cases.
For example, in some embodiments, based on the test case file after the test case is added, the error injection verification is performed on the first functional point again until the injected error can be tested. For example, based on the test case file after the test case is added, step S314 to step S315 are performed to obtain an input file of a new test tool, and the test tool is used to perform error input verification based on the input file until the injected error can be tested.
For example, the method for verifying the design of the integrated circuit provided by the embodiment of the disclosure and the method for directly using the test tool are used for performing error injection verification on the same register transfer level file. And comparing the number of errors required to be injected and the number of test cases required to be subjected to regression testing under the two methods.
For example, a register transfer level file was tested, and the results of the two methods show: the number of injection errors by directly using the test tool is 5304, and the number of test cases is 60; the method for verifying the integrated circuit design provided by the embodiment of the disclosure has 1794 injection errors and 6 test cases.
The greater the number of injection errors, the greater the number of regression tests that need to be performed. The greater the number of test cases, the longer the test time that may need to be run for each return test. It can be seen that the method for verifying an integrated circuit design provided by the embodiment of the disclosure can reduce the number of injection errors and the number of test cases requiring regression testing, save the time for injecting the whole error for verification, and further ensure the verification completeness of the key path of the design code of the register transfer level file while shortening the verification period.
For example, at least one embodiment of the present disclosure also provides an apparatus for integrated circuit design verification. Fig. 4 is a schematic diagram of an apparatus for integrated circuit design verification according to at least one embodiment of the present disclosure.
For example, in some embodiments, the apparatus 300 for integrated circuit design verification includes a function point acquisition module 310 and a verification module 320.
For example, the function point obtaining module 310 is configured to obtain a first function point in the register transfer level file, where the function set defined by the register transfer level file includes the first function point and at least one second function point, the first function point is a function point that needs to be verified, and the second function point is a function point that does not need to be verified.
For example, in some embodiments, the first function point is an added function point based on a register transfer level file of existing design goals. The second functional point is a functional point that has been verified in a register transfer level file of an existing design target. The first function points are new function points based on a previous version of the integrated circuit design or other previous integrated circuit designs that require error injection verification. And the second function point is a function point in the register transfer stage file that was verified in the register transfer stage file of a previous version of the integrated circuit design or other integrated circuit design prior to the first function point in the set of functions in the register transfer stage file. That is, the second functional point is a mature functional point whose corresponding design code has been confirmed to be free of errors or bugs (bugs). The method for verifying the integrated circuit design provided by the embodiment of the disclosure does not perform error injection verification on the second function point any more, so as to avoid unnecessary work and further reduce verification time.
For example, the verification module 320 is configured to perform error injection verification on the first function point. For example, the error injection verification is performed on the functional points needing to be verified in the register transmission level file in a targeted manner, so that the whole error injection verification time is saved, the verification period is shortened, and the verification completeness of the key path of the design code of the register transmission level file is ensured.
In the embodiment of the present disclosure, for example, any one of the function point obtaining module 310 and the verifying module 320 may be implemented by using software, firmware or hardware, which is not limited by the present disclosure.
Fig. 5 is a schematic structural diagram of an apparatus for integrated circuit design verification according to at least one embodiment of the present disclosure.
The apparatus 400 for integrated circuit design verification shown in fig. 5 is, for example, suitable for use in implementing the methods for integrated circuit design verification provided by embodiments of the present disclosure. The device 400 for integrated circuit design verification may be a terminal device such as a personal computer, a notebook computer, a tablet computer, a mobile phone, etc., or may be a workstation, a server, a cloud service, etc. It should be noted that the apparatus 400 for integrated circuit design verification shown in fig. 5 is only an example and does not impose any limitation on the scope of use or functionality of embodiments of the present disclosure.
As shown in fig. 5, an apparatus 400 for integrated circuit design verification may include a processing device (e.g., central processing unit, graphics processor, etc.) 410 that may perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)420 or a program loaded from a storage device 480 into a Random Access Memory (RAM) 430. In the RAM 430, various programs and data necessary for the operation of the apparatus 400 for integrated circuit design verification are also stored. The processing device 410, the ROM 420, and the RAM 430 are connected to each other by a bus 440. An input/output (I/O) interface 450 is also connected to bus 440.
Generally, the following devices may be connected to the I/O interface 450: input devices 460 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 470 including, for example, a Liquid Crystal Display (LCD), speakers, vibrators, or the like; storage 480 including, for example, magnetic tape, hard disk, etc.; and a communication device 490. The communication device 490 may allow the apparatus 400 for integrated circuit design verification to communicate wirelessly or wiredly with other electronic devices to exchange data. While FIG. 5 illustrates an apparatus 400 for integrated circuit design verification including various means, it is to be understood that not all illustrated means are required to be implemented or provided and that the apparatus 400 for integrated circuit design verification may alternatively be implemented or provided with more or fewer means.
For example, the above-described method for integrated circuit design verification may be implemented as a computer software program according to an embodiment of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a non-transitory computer readable medium, the computer program comprising program code for performing the above-described method for integrated circuit design verification. In such embodiments, the computer program may be downloaded and installed from a network through communication device 490, or installed from storage device 480, or installed from ROM 420. The computer program, when executed by the processing device 410, may perform the functions defined in the method for integrated circuit design verification provided by the embodiments of the present disclosure.
At least one embodiment of the present disclosure also provides a storage medium for storing non-transitory computer program executable code (e.g., computer executable instructions) that, when executed by a computer, may implement the method for integrated circuit design verification described in any of the embodiments of the present disclosure; alternatively, the non-transitory computer program executable code may implement the method for integrated circuit design verification described in any of the embodiments of the present disclosure when executed by a computer.
Fig. 6 is a schematic diagram of a storage medium according to at least one embodiment of the present disclosure. As shown in fig. 6, the storage medium 500 non-temporarily stores computer program executable code 501. For example, the computer program executable code 501, when executed by a computer, may perform one or more steps in a method for integrated circuit design verification according to the above.
For example, the storage medium 500 may be applied to the apparatus 400 for integrated circuit design verification described above. For example, the storage medium 500 may be the memory 420 in the apparatus 400 for integrated circuit design verification shown in fig. 6. For example, the relevant description about the storage medium 500 may refer to the corresponding description of the memory 420 in the apparatus 400 for integrated circuit design verification shown in fig. 6, and will not be repeated here.
In addition to the above description, there are the following points to be explained:
(1) the drawings of the embodiments of the disclosure only relate to the structures related to the embodiments of the disclosure, and other structures can refer to the common design.
(2) Without conflict, embodiments of the present disclosure and features of the embodiments may be combined with each other to arrive at new embodiments.
The above is only a specific embodiment of the present disclosure, but the scope of the present disclosure is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the present disclosure, and shall be covered by the scope of the present disclosure. Therefore, the protection scope of the present disclosure shall be subject to the protection scope of the claims.

Claims (15)

1. A method for integrated circuit design verification, comprising:
acquiring a first function point in a register transmission level file, wherein a function set defined by the register transmission level file comprises the first function point and at least one second function point, the first function point is a function point needing to be verified, and the at least one second function point is a function point not needing to be verified; and
and carrying out error injection verification on the first functional point.
2. The method for integrated circuit design verification according to claim 1, wherein the register transfer level file includes design code corresponding to the first function point that implements a batch format,
performing error injection verification on the first functional point, including:
based on the first function point, performing error injection on the design code corresponding to the first function point and realizing the batch processing format; and
and verifying the first functional point by using the design codes and the test case files which are injected with errors and realize the batch processing format.
3. The method for integrated circuit design verification of claim 2, wherein obtaining the first function point in the register transfer level file comprises:
and searching the design code for realizing the batch processing format in the register transmission level file to obtain the design code for realizing the batch processing format corresponding to the first function point.
4. A method for integrated circuit design verification as claimed in claim 3, wherein the first function point is an added function point on the basis of a register transfer level file of existing design targets,
the at least one second functional point is the functional point that was verified in the register transfer level file for the existing design target.
5. A method for integrated circuit design verification as claimed in any of claims 2-4, wherein prior to performing error injection verification on the first functional point, comprising:
calling the test case file, wherein the test case file comprises test cases, and the test cases corresponding to the first functional points in the test cases are marked; and
and performing coverage analysis on the test cases of the test case file based on the register transfer level file.
6. The method for integrated circuit design verification as claimed in claim 5, wherein verifying the first functional point using the design code implementing a batch format and a test case file for error injection comprises:
searching the marked test case corresponding to the first function point in the test case file; and
and performing regression testing on the design codes which are injected by errors and realize the batch processing format by utilizing a testing tool based on the marked test cases.
7. A method for integrated circuit design verification as claimed in claim 6, wherein the results of the regression testing are analyzed to end verification of the first functional point when errors injected in the design code implementing a batch format can all be tested.
8. The method for integrated circuit design verification as defined in claim 6,
when at least one of the errors injected in the design codes for realizing the batch processing format is not tested, adding the test cases in the test case file and modifying the design codes for realizing the batch processing format corresponding to the errors which are not tested,
and performing coverage rate analysis on the added test cases again.
9. The method for integrated circuit design verification according to claim 8, wherein the error injection verification is performed again on the first functional point based on the test case file after the test case is added until the injected errors can be tested.
10. The method for integrated circuit design verification as claimed in claim 6, wherein performing the regression test on the error injected design code in the implemented batch format based on the flagged test cases with the test tool comprises:
generating an input file of the test tool according to the design code for realizing the batch processing format and the marked test case,
and performing the regression test on the design codes which are injected with the errors and realize the batch processing format according to the input file by utilizing the test tool.
11. The method for integrated circuit design verification as claimed in claim 10, wherein the design code implementing a batch format includes design code defined using macros,
generating an input file of the test tool according to the design code for realizing the batch processing format and the marked test case, wherein the input file comprises:
performing parameter processing on the design code for realizing the batch processing format and the marked test case to obtain the name of the functional point needing error injection and the type of the error needing to be injected,
obtaining a path corresponding to the functional point needing error injection according to the functional point name needing error injection,
writing the macro definition of the design code implementing the batch format into a first input file,
and updating the path defined by the macro in the first input file into a path corresponding to the functional point which needs to be subjected to error injection.
12. The method for integrated circuit design verification as claimed in claim 11, wherein generating the input file for the test tool from the design code in the implementation batch format and the marked test cases further comprises:
according to the marked test case, obtaining the test case related to the functional point name needing error injection through the functional point name needing error injection,
and generating a second input file according to the test case related to the name of the functional point needing error injection.
13. An apparatus for integrated circuit design verification, comprising:
a function point obtaining module configured to obtain a first function point in a register transfer level file, wherein a function set defined by the register transfer level file includes the first function point and at least one second function point, the first function point is a function point requiring verification, and the at least one second function point is a function point requiring no verification,
a verification module configured to perform error injection verification on the first function point.
14. An apparatus for integrated circuit design verification, comprising:
a processor; and
memory having stored therein computer executable code which when executed by a processor performs the method for integrated circuit design verification of any one of claims 1-12.
15. A computer readable storage medium having stored thereon executable code which, when executed by a processor, causes the processor to perform the method for integrated circuit design verification of any of claims 1-12.
CN202011532364.6A 2020-12-23 2020-12-23 Method, apparatus, device and storage medium for integrated circuit design verification Active CN112580282B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011532364.6A CN112580282B (en) 2020-12-23 2020-12-23 Method, apparatus, device and storage medium for integrated circuit design verification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011532364.6A CN112580282B (en) 2020-12-23 2020-12-23 Method, apparatus, device and storage medium for integrated circuit design verification

Publications (2)

Publication Number Publication Date
CN112580282A true CN112580282A (en) 2021-03-30
CN112580282B CN112580282B (en) 2023-04-07

Family

ID=75138960

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011532364.6A Active CN112580282B (en) 2020-12-23 2020-12-23 Method, apparatus, device and storage medium for integrated circuit design verification

Country Status (1)

Country Link
CN (1) CN112580282B (en)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0519363D0 (en) * 2005-09-22 2005-11-02 Advanced Risc Mach Ltd Error propagation in integrated circuits
CN101510234A (en) * 2009-03-18 2009-08-19 中国科学院计算技术研究所 Instruction combination filtration method and system for instruction grade stochastic verification
WO2009110615A1 (en) * 2008-03-07 2009-09-11 日本電気株式会社 Device for designing semiconductor integrated circuit, method for designing semiconductor integrated circuit, and computer program for designing semiconductor integrated circuit
US20100058259A1 (en) * 2008-08-27 2010-03-04 Tal Erlich Optimization of verification of chip design
CN102122265A (en) * 2011-03-03 2011-07-13 中国工商银行股份有限公司 System and method for verifying computer software test results
CN102156784A (en) * 2011-04-18 2011-08-17 烽火通信科技股份有限公司 Verifying environment patterned chip verifying method and device
US20120317533A1 (en) * 2011-06-08 2012-12-13 Cadence Design Systems, Inc. System and method for dynamically injecting errors to a user design
CN104123253A (en) * 2014-07-28 2014-10-29 浪潮(北京)电子信息产业有限公司 Method and device for interconnecting chips to be verified
CN106383303A (en) * 2016-08-26 2017-02-08 哈尔滨工业大学 Observation point and concurrence based fault injection simulation method and device

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0519363D0 (en) * 2005-09-22 2005-11-02 Advanced Risc Mach Ltd Error propagation in integrated circuits
WO2009110615A1 (en) * 2008-03-07 2009-09-11 日本電気株式会社 Device for designing semiconductor integrated circuit, method for designing semiconductor integrated circuit, and computer program for designing semiconductor integrated circuit
US20100058259A1 (en) * 2008-08-27 2010-03-04 Tal Erlich Optimization of verification of chip design
CN101510234A (en) * 2009-03-18 2009-08-19 中国科学院计算技术研究所 Instruction combination filtration method and system for instruction grade stochastic verification
CN102122265A (en) * 2011-03-03 2011-07-13 中国工商银行股份有限公司 System and method for verifying computer software test results
CN102156784A (en) * 2011-04-18 2011-08-17 烽火通信科技股份有限公司 Verifying environment patterned chip verifying method and device
US20120317533A1 (en) * 2011-06-08 2012-12-13 Cadence Design Systems, Inc. System and method for dynamically injecting errors to a user design
CN104123253A (en) * 2014-07-28 2014-10-29 浪潮(北京)电子信息产业有限公司 Method and device for interconnecting chips to be verified
CN106383303A (en) * 2016-08-26 2017-02-08 哈尔滨工业大学 Observation point and concurrence based fault injection simulation method and device

Also Published As

Publication number Publication date
CN112580282B (en) 2023-04-07

Similar Documents

Publication Publication Date Title
US10445225B2 (en) Command coverage analyzer
US20070061641A1 (en) Apparatus and method for generating test driver
US10073933B2 (en) Automatic generation of properties to assist hardware emulation
US7606695B1 (en) Self-checking simulations using dynamic data loading
US6691078B1 (en) Target design model behavior explorer
US8140315B2 (en) Test bench, method, and computer program product for performing a test case on an integrated circuit
US9092567B2 (en) Systems and methods for analyzing transactions in a computer system
US10839124B1 (en) Interactive compilation of software to a hardware language to satisfy formal verification constraints
CN114564394A (en) Test case determination method, system and related components
KR101042979B1 (en) Simulation Kernel-based Simulation Fault Injection Apparatus for the Evaluation of the Dependability of Embedded Systems
CN117094269B (en) Verification method, verification device, electronic equipment and readable storage medium
US10929584B1 (en) Environmental modification testing for design correctness with formal verification
US20020055829A1 (en) High level verification of software and hardware description and sharing resources among concurrent processes
JP2016031622A (en) Software verification system and control device
CN112580282B (en) Method, apparatus, device and storage medium for integrated circuit design verification
KR100777103B1 (en) Apparatus and method for generation of test driver
US11023357B1 (en) Method and system for sequential equivalence checking
US7447621B1 (en) PLI-less co-simulation of ISS-based verification systems in hardware simulators
US20140173539A1 (en) Method and Apparatus for Isolating and/or Debugging Defects in Integrated Circuit Designs
Lohmann et al. A Domain-specific language for automated fault injection in SystemC models
US11062069B1 (en) Bounded deadlock check
US20220300690A1 (en) Incremental compilation for fpga-based systems
US10853546B1 (en) Method and system for sequential equivalence checking
US8996435B2 (en) Determining invariants in a model
US20230186004A1 (en) Integrated circuit design vertfication

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant