A verification method, device, medium and equipment for accelerating convergence of function coverage

Abstract

This invention discloses a verification method, apparatus, medium, and device for accelerating functional coverage convergence. The method is applied to a verification platform, which includes a directed stimulus generator, a functional coverage model, and a design under test (DUT), and is equipped with a simulation switch. The method includes: parsing the code file of the functional coverage model using a preset cross-use case script file to extract coverage repository information corresponding to cross-functional coverage points; configuring the simulation switch according to the coverage repository information to generate boundary use case files; using the directed stimulus generator to read the switch configuration information in the boundary use case files; generating a directed stimulus flow based on a directed instruction sequence according to the switch configuration information; and sending the directed stimulus flow to the DUT to perform the verification work. The technical solution of this invention can automatically generate boundary use cases for cross-functional coverage points, thereby effectively reducing the convergence time of functional coverage and improving the convergence rate of functional coverage.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a verification method, apparatus, computer-readable storage medium, computer program product, and terminal device for accelerating functional coverage convergence. Background Technology

[0002] Functional coverage is a quantitative metric for measuring the quality of chip verification. It measures the completeness of the verification process; reaching the target functional coverage value indicates complete verification. Functional coverage convergence refers to the process during verification where the functional coverage gradually increases from low to high, eventually approaching and stabilizing at the target value. This is a key signal for determining whether the verification process can be terminated. Existing methods for functional coverage convergence mainly include: S01, converging most of the functional coverage through a large number of constraint-based regression tests; S02, converging the remaining functional coverage by adjusting the constraints during testing; and S03, converging the final remaining boundary functional coverage by manually writing boundary test cases.

[0003] In existing methods for achieving functional coverage convergence, there is a severe imbalance between the time spent on writing functional coverage test cases and the time spent on convergence. Convergence takes up a significant amount of time and has a low convergence rate. This is because: although conducting a large number of constraint-based regression tests and adjusting the constraints in the early stages can quickly improve functional coverage, the huge stimulus space results in minimal improvement for boundary scenarios, leading to diminishing marginal returns in the convergence effect. Furthermore, while manually writing boundary test cases can compensate for this diminishing marginal returns, when faced with a large number of discrete cross-functional coverage points, especially those dominated by boundary values, the workload of manually writing test cases is enormous, tedious, and difficult to verify, resulting in even longer convergence time and a lower convergence rate. Summary of the Invention

[0004] The purpose of this invention is to provide a verification method, apparatus, computer-readable storage medium, computer program product, and terminal device for accelerating functional coverage convergence, which can automatically generate boundary test cases for cross-functional coverage points, thereby effectively reducing the convergence time of functional coverage and improving the convergence rate of functional coverage.

[0005] To achieve the above objectives, embodiments of the present invention provide a verification method for accelerating functional coverage convergence, applied to a verification platform. The verification platform includes a directed stimulus generator, a functional coverage model, and a design under test, and is equipped with a simulation switch. The method includes:

[0006] The code file of the functional coverage model is parsed using a preset cross-use case script file to extract the coverage compartment information corresponding to the cross-functional coverage points. The simulation switch is then configured based on the coverage compartment information to generate boundary use case files.

[0007] The directional stimulus generator reads the switch configuration information in the boundary use case file, generates a directional stimulus flow based on the directional instruction sequence according to the switch configuration information, and sends the directional stimulus flow to the design under test to perform verification work.

[0008] Furthermore, the step of parsing the code file of the functional coverage model using a preset cross-use case script file to extract coverage repository information corresponding to cross-functional coverage points specifically includes:

[0009] The code file of the functional coverage model is parsed using a pre-defined cross-test case script file to extract all functional coverage groups of the functional coverage model;

[0010] Identify all cross-functional coverage points contained in each functional coverage group, and obtain the coverage bin information corresponding to each cross-functional coverage point; wherein, the coverage bin information includes the number of coverage bins corresponding to each functional coverage point involved in the cross-functional coverage point and the boundary value corresponding to each coverage bin.

[0011] Furthermore, identifying all cross-functional coverage points contained in each functional coverage group specifically includes:

[0012] Based on the preset naming pattern characters, each function coverage group is searched to determine whether it contains function coverage points named based on the naming pattern characters.

[0013] If so, the function coverage point named based on the naming pattern characters will be identified as an intersecting function coverage point.

[0014] Furthermore, configuring the simulation switch based on the coverage information and generating boundary use case files specifically includes:

[0015] For each cross-functional coverage point, the coverage modules corresponding to the different functional coverage points involved in the same cross-functional coverage point are cross-combined.

[0016] The simulation switch is configured differently according to different cross-combination methods, and boundary use case files of switch configuration form are generated.

[0017] Furthermore, the method also includes:

[0018] The code for searching the intersection function coverage points based on the preset annotation pattern characters contains annotation information based on the annotation pattern characters.

[0019] If so, the annotation information is obtained; wherein the annotation information is used to represent the mapping relationship between the cross-functional coverage point and the simulation switch;

[0020] Then, configuring the simulation switch according to the coverage information and generating boundary use case files specifically involves:

[0021] Configure the simulation switch based on the coverage information and the annotation information to generate a boundary use case file.

[0022] Furthermore, the verification platform also includes a constraint stimulus generator, and the method further includes:

[0023] The constraint stimulus generator is used to randomly generate a constraint stimulus flow that meets the preset constraint conditions, and the constraint stimulus flow is sent to the design under test to perform verification work.

[0024] To achieve the above objectives, embodiments of the present invention also provide a verification device for accelerating functional coverage convergence, applied to a verification platform. The verification platform includes a directed stimulus generator, a functional coverage model, and a design under test, and is equipped with a simulation switch. The device includes:

[0025] The code file parsing module is used to parse the code file of the functional coverage model using a preset cross-use case script file, so as to extract the coverage compartment information corresponding to the cross-functional coverage points, configure the simulation switch according to the coverage compartment information, and generate boundary use case files;

[0026] The targeted stimulus verification module is used to read the switch configuration information in the boundary use case file using the targeted stimulus generator, generate a targeted stimulus flow based on the targeted instruction sequence according to the switch configuration information, and send the targeted stimulus flow to the design under test to perform verification work.

[0027] This invention also provides a computer-readable storage medium including a stored computer program, which, when running, controls the device where the computer-readable storage medium is located to execute the verification method for accelerating function coverage convergence described above.

[0028] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the verification method for accelerating function coverage convergence as described above.

[0029] This invention also provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the verification method for accelerating function coverage convergence as described above.

[0030] Compared with existing technologies, embodiments of the present invention provide a verification method, apparatus, computer-readable storage medium, computer program product, and terminal device for accelerating functional coverage convergence. The method is applied to a verification platform, which includes a directed stimulus generator, a functional coverage model, and a design under test (DUT), and is equipped with a simulation switch. The method includes: parsing the code file of the functional coverage model using a preset cross-use case script file to extract coverage repository information corresponding to cross-functional coverage points; configuring the simulation switch according to the coverage repository information corresponding to the cross-functional coverage points to generate boundary use case files; using the directed stimulus generator to read the switch configuration information in the boundary use case files; generating a directed stimulus flow based on a directed instruction sequence according to the switch configuration information; and sending the directed stimulus flow to the DUT to perform the verification work. Embodiments of the present invention can automatically generate boundary use cases for cross-functional coverage points, thereby effectively reducing the convergence time of functional coverage and improving the convergence rate of functional coverage. Attached Figure Description

[0031] Figure 1 This is a flowchart of a verification method for accelerating functional coverage convergence provided in an embodiment of the present invention;

[0032] Figure 2 This is a structural block diagram of a verification platform provided in an embodiment of the present invention;

[0033] Figure 3 This is a structural block diagram of a verification platform provided in another embodiment of the present invention;

[0034] Figure 4 This is a structural block diagram of a verification device for accelerating functional coverage convergence according to an embodiment of the present invention;

[0035] Figure 5 This is a structural block diagram of a terminal device provided in an embodiment of the present invention. Detailed Implementation

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

[0037] This invention provides a verification method to accelerate functional coverage convergence. See [link to relevant documentation]. Figure 1 and Figure 2 As shown, Figure 1 This is a flowchart of a verification method for accelerating functional coverage convergence according to an embodiment of the present invention. Figure 2 This is a structural block diagram of a verification platform provided in an embodiment of the present invention. The method is applied to the verification platform, which includes a directional stimulus generator, a functional coverage model, and a design under test (DUT), and is equipped with a simulation switch. The method includes steps S11 to S12:

[0038] Step S11: Use a preset cross-use case script file to parse the code file of the functional coverage model to extract the coverage compartment information corresponding to the cross-functional coverage points, configure the simulation switch according to the coverage compartment information, and generate boundary use case files;

[0039] Step S12: Use the directional stimulus generator to read the switch configuration information in the boundary use case file, generate a directional stimulus flow based on the directional instruction sequence according to the switch configuration information, and send the directional stimulus flow to the design under test to perform verification work.

[0040] like Figure 2 As shown, the verification environment of the verification platform includes a directed stimulus generator and a functional coverage model. The directed stimulus generator generates a directed stimulus flow and feeds it into the DUT. The functional coverage model is described based on a defined functional coverage plan (which can be described using SV (System Verilog) or other programming languages). Furthermore, the verification platform also includes a number of simulation switches related to instructions or services. By configuring these simulation switches, the random range of constraints can be dynamically changed, thereby enabling the reading of directed instruction sequences or partial directed instruction sequences to generate a specified stimulus flow (i.e., a directed stimulus flow based on a directed instruction sequence generated by the directed stimulus generator in a directed generation mode based on switch configuration). This allows the verification environment to support the use of directed instruction flows as input stimuli for the DUT.

[0041] In specific implementation of this invention, before performing dynamic simulation verification, a pre-set cross-test case script file (which can be pre-built using Python or other programming languages ​​based on business needs; for example, if built using Python, the cross-test case script file can be named "bach.py") can be used to parse the code file corresponding to the functional coverage model (which can be pre-built using SV or other programming languages ​​based on business needs; for example, if built using SV, the code file corresponding to the functional coverage model can be named "fcov.sv"), in order to extract the cross-test cases described in the functional coverage model. The system obtains coverage information corresponding to cross-functional coverage points and inter-functional coverage points. Based on the coverage information corresponding to inter-functional coverage points, it configures the simulation switches associated with the inter-functional coverage points in the verification platform to map the expected stimuli of the inter-functional coverage points to boundary use case files based on switch configurations. Then, during dynamic simulation verification, the system uses a directional stimulus generator to parse the boundary use case files to read the switch configuration information in the boundary use case files. Based on the switch configuration information in the boundary use case files, it generates a directional stimulus flow based on a directional instruction sequence and sends the generated directional stimulus flow based on the directional instruction sequence to the DUT to perform the verification work.

[0042] Among them, cross-functional coverage points refer to functional coverage points that have intersections or interactions. Coverage bins are the smallest elements that describe functional coverage and are also the specific signal values ​​that functional coverage needs to collect. For example, assuming that there is an interaction scenario between functional coverage point A and functional coverage point B, the coverage bin information corresponding to the cross-functional coverage point formed by functional coverage point A and functional coverage point B is the coverage bin information of functional coverage point A and the coverage bin information of functional coverage point B.

[0043] It's important to note that the configuration of the simulation switch corresponds to the random range of the constraint. Suppose we need to verify an instruction that corresponds to many instruction fields, and each instruction field has its own random range (which can be a specific value or a range of values). Then, we can configure the value of the simulation switch to correspond to the random range of the instruction field. For example, we can associate a simulation switch with a specific instruction field and name the simulation switch after the instruction field. If we configure the value of this simulation switch to 3, then during test case generation, it means that the value of the instruction field associated with this simulation switch is equal to 3. Alternatively, we can predefine that a simulation switch value of 0 indicates a corresponding random range less than 0, and a simulation switch value of 1 indicates a corresponding random range less than 0. The random range of the simulation switch is greater than 0. If the value of this simulation switch is configured to 0, it means that the random range of the instruction domain associated with this simulation switch is less than 0 during the test case generation process. If the value of this simulation switch is configured to 1, it means that the random range of the instruction domain associated with this simulation switch is greater than 0 during the test case generation process. The mapping relationship between the simulation switch and the instruction domain depends on the user's needs and business needs, and can be defined by the user. Therefore, the mapping relationship between the value of each simulation switch and the random range of the directional boundary test cases that the user wants to implement can be pre-configured. When a simulation switch is turned on, the random range corresponding to the value of this simulation switch is restricted to the pre-configured fixed range.

[0044] It should be noted that the verification platform in the embodiments of the present invention can be a UVM (Universal Verification Methodology) verification platform and the verification environment can be built using the SV language. Alternatively, other suitable verification platforms and programming languages ​​can be used to build the verification environment. The embodiments of the present invention do not make specific limitations. The applicable requirements of the embodiments of the present invention on other non-UVM verification platforms are as follows: (1) There are functional coverage acquisition requirements and their corresponding description methods (compatible with the SV language); (2) It is necessary to support the reading method of converting the external boundary use cases of the directional stimulus generator into directional stimulus streams.

[0045] The present invention provides a verification method for accelerating functional coverage convergence. This method utilizes the bach.py ​​script file to perform text analysis and information extraction on the fcov.sv code file to extract coverage modules for cross-functional coverage points. Based on the cross-information and business logic, it generates boundary test case files in the form of switch configurations. The verification platform then reads and runs these boundary test case files. This method can complement constraint-based random verification schemes (such as the verification schemes corresponding to S01 and S02 in the background technology), rapidly improving functional coverage. It is particularly effective for cross-functional coverage points that are difficult to encounter in random verification, especially those based on boundary values. It can automatically generate boundary test cases for these cross-functional coverage points, eliminating the need for manual writing of boundary test cases (equivalent to optimizing the verification scheme corresponding to S03 in the background technology). This effectively reduces the convergence time of functional coverage and significantly improves the convergence rate, especially for the convergence of cross-functional coverage based on boundary values.

[0046] It should be noted that, as described in the background section, in order to improve functional coverage by covering cross-functional coverage points during verification, a large number of boundary test cases need to be manually written. However, many parameters in these boundary test cases are the same as those in the fcov.sv code file, which is repetitive work. Manual writing is prone to errors and difficult to locate. In contrast, the embodiments of the present invention only require parsing the fcov.sv code file and adjusting the bach.py ​​script file in conjunction with the functional coverage design to automatically generate boundary test cases for each cross-functional coverage point. It is compatible with various verification tasks and instruction sets, effectively reduces repetitive work, and has the advantages of good versatility and strong portability. Furthermore, it can solve the problems of easy error and difficulty in locating errors caused by manual writing, thereby greatly improving verification efficiency and reducing the possibility of errors.

[0047] It's important to note that a piece of program code needs to be compiled before it can be run. This process converts the source code, written in a programming language, into machine code that the computer hardware can directly execute (i.e., an executable file). However, compilation is typically time-consuming, and the larger the codebase, the more time it takes. Therefore, compiling the code every time it's run is extremely wasteful. For example, in the verification schemes corresponding to S01 and S02 in the background, it's impossible to compile all test cases every time a regression test is performed. If there are 10,000 test cases to run, compiling them 10,000 times would be very time-consuming and impact verification efficiency. Therefore, in actual verification work, compilation should be avoided as much as possible. For example, all 10,000 test cases can be compiled together to generate a single executable file, which can then be run 10,000 times. This significantly reduces compilation time and greatly improves verification efficiency.

[0048] As mentioned above, only code needs to be compiled. However, in this embodiment of the invention, the entire verification environment consists of code involved in the verification work. After the verification environment framework is built, the code files of the entire verification environment only need to be compiled once. Even if there are modifications during the verification process (such as modifying the random range of some constraints), there is no need to recompile the verification environment. This is because the verification environment supports parsing test case files, extracting keywords such as instruction type, instruction domain, control switch, and configuration value from the directed instruction sequence, and passing them to the simulation switch in the verification environment. Therefore, there is no need to recompile, and different test case files can be read as needed to carry out the verification work. In other words, this embodiment of the invention can transfer the work of modifying the code from the entire code file and transfer it to modifying the configuration file (text file) of the simulation switch. Since only the text file needs to be modified, and the text file is not a code file, there is no need to recompile the code file. Therefore, this embodiment of the invention only needs to compile the code files of the entire verification environment once, without repeating the compilation after each modification of the switch configuration, thereby improving the verification efficiency.

[0049] In one optional embodiment, the step of parsing the code file of the functional coverage model using a preset cross-use case script file to extract coverage repository information corresponding to the cross-functional coverage points specifically includes:

[0050] The code file of the functional coverage model is parsed using a pre-defined cross-test case script file to extract all functional coverage groups of the functional coverage model;

[0051] Identify all cross-functional coverage points contained in each functional coverage group, and obtain the coverage bin information corresponding to each cross-functional coverage point; wherein, the coverage bin information includes the number of coverage bins corresponding to each functional coverage point involved in the cross-functional coverage point and the boundary value corresponding to each coverage bin.

[0052] Specifically, in conjunction with the above embodiments, when using cross-use case script files to parse the code file of the functional coverage model to extract the coverage repository information corresponding to the cross-functional coverage points, the present invention can first parse the code file of the functional coverage model to extract all functional coverage groups described in the functional coverage model, and then analyze the functional coverage points based on the business logic of different functional coverage groups. For each functional coverage group, it is necessary to identify all the cross-functional coverage points contained in the same functional coverage group and obtain the coverage repository information corresponding to each cross-functional coverage point. The coverage repository information corresponding to the cross-functional coverage point includes the number of coverage repositories corresponding to each functional coverage point involved in the cross-functional coverage point and the boundary values ​​corresponding to each coverage repositories (for example, the number of coverage repositories corresponding to functional coverage point A and the boundary values ​​corresponding to each coverage repositories in the above embodiments, the number of coverage repositories corresponding to functional coverage point B and the boundary values ​​corresponding to each coverage repositories).

[0053] It should be noted that the number of coverage modules corresponding to all functional coverage points described in the functional coverage model, as well as the boundary values ​​corresponding to each coverage module (the boundary values ​​of range-type coverage modules can be any value within their range), can be predefined in the code file of the functional coverage model. The cross-test script file can obtain this information by parsing the code file of the functional coverage model. For example, within each functional coverage group, the cross-test script file can analyze each functional coverage point as an item and extract the number of coverage modules under each functional coverage point and the boundary values ​​corresponding to each coverage module.

[0054] It should be noted that when pre-building the fcov.sv code file corresponding to the functional coverage model, multiple covergroups (functional coverage groups, which are descriptive components of functional coverage) can be written within the fcov.sv code file, categorized by type. Taking any covergroup as an example, multiple coverpoints (functional coverage points, which are components of the functional coverage group) can be written within this covergroup. A coverpoint represents the functional coverage point to be collected. A functional coverage point can be a specific signal value to be collected, assuming that the value of this signal value is 0, 1, ... In cases 2 and 3, each of the following is required to occur once. Therefore, the coverage bins of this functional coverage point can be defined as the values ​​of the signal. Each value represents a coverage bin. Thus, this functional coverage point has four coverage bins, with boundary values ​​corresponding to 0, 1, 2, and 3 respectively. If the boundary values ​​corresponding to these four coverage bins all occur during the verification process, then the functional coverage of this functional coverage point can reach 100%. Accordingly, if the functional coverage of all cover points corresponding to the functional coverage model is collected, then ideally, the functional coverage of the entire functional coverage model can reach 100%.

[0055] In one optional embodiment, identifying all cross-functional coverage points contained in each functional coverage group specifically includes:

[0056] Based on the preset naming pattern characters, each function coverage group is searched to determine whether it contains function coverage points named based on the naming pattern characters.

[0057] If so, the function coverage point named based on the naming pattern characters will be identified as an intersecting function coverage point.

[0058] Specifically, in conjunction with the above embodiments, when identifying all cross-functional coverage points contained in each functional coverage group, the present invention can retrieve the names of all functional coverage points contained in each functional coverage group according to a predefined naming pattern character to determine whether there are functional coverage points named based on the naming pattern character. If there are, the functional coverage points named based on the naming pattern character can be identified as cross-functional coverage points. Through this retrieval method, all cross-functional coverage points contained in each functional coverage group can be identified.

[0059] It should be noted that when pre-building the fcov.sv code file corresponding to the functional coverage model, in addition to writing multiple coverpoints within the covergroup, some Crosscoverpoints are also defined. To distinguish coverpoints from Crosscoverpoints, predefined naming pattern characters can be used as suffixes for Crosscoverpoints. For example, the suffix "_auto" can be used to name them, forming something like " The naming pattern character "_auto: cross" will be used when the cross-test case script file retrieves the code file containing the functional coverage model. By naming a function coverage point "_auto: cross", you can identify that the function coverage point is a cross function coverage point.

[0060] In one optional embodiment, configuring the simulation switch based on the coverage information and generating boundary use case files specifically includes:

[0061] For each cross-functional coverage point, the coverage modules corresponding to the different functional coverage points involved in the same cross-functional coverage point are cross-combined.

[0062] The simulation switch is configured differently according to different cross-combination methods, and boundary use case files of switch configuration form are generated.

[0063] Specifically, in conjunction with the above embodiments, when configuring simulation switches and generating boundary test case files based on the coverage bin information corresponding to the cross-functional coverage points, the test case generation method is the same for each cross-functional coverage point. Here, we take any cross-functional coverage point as an example for explanation: First, determine the number of coverage bins corresponding to each functional coverage point involved in the cross-functional coverage point and the boundary values ​​corresponding to each coverage bin. Then, cross-combine each coverage bin corresponding to the different functional coverage points involved in the cross-functional coverage point. For example, assuming that the functional coverage points involved in the cross-functional coverage point are functional coverage point A and functional coverage point B, then the boundary values ​​of each coverage bin corresponding to functional coverage point A and the boundary values ​​of each coverage bin corresponding to functional coverage point B need to be cross-combined sequentially. After that, based on different cross-combination methods, different switch configurations are performed on the simulation switches in the verification platform that are associated with the cross-functional coverage points, and boundary test case files in the form of switch configurations are generated accordingly.

[0064] Understandably, a cross coverpoint includes at least one cross-combination method, and each cross-combination method corresponds to a switch configuration information, that is, a direction instruction or a use case. Collecting the use cases corresponding to all cross-combination methods of the same cross coverpoint constitutes a boundary use case file. Correspondingly, a cover group may include more than one cross coverpoint. Within each cover group, the cross use case script file retrieves entries starting with " When a Cross coverpoint is named "_auto: cross", the coverpoint items involved will be extracted, the coverage bins described in each of the various coverpoints will be cross-combined, and corresponding boundary use case files will be generated. By collecting all the boundary use case files corresponding to the Cross coverpoints and combining them with the business requirements corresponding to the current covergroup, a huge pool of use cases can be generated for subsequent targeted incentive generators to read.

[0065] It should be noted that in actual verification work, for a Cross coverpoint, it is required that every possible cross combination has occurred. However, compared to the probability of the boundary value of a single coverpoint's coverage bin, the probability of such a cross combination occurs is greatly reduced because it involves the boundary values ​​of the coverage bins of more than one coverpoint. This increases the complexity of collecting functional coverage data, making it more difficult to collect functional coverage data. It is clear that the existence of Cross cases is the bottleneck in reducing "improving functional coverage". So how do we collect the functional coverage data of Cross coverpoints? As mentioned above, we can obtain the number of coverage modules corresponding to each coverpoint and the boundary values ​​corresponding to each coverage module by parsing the fcov.sv code file. When the fcov.sv code file also defines a Cross coverpoint, we can determine how to achieve 100% functional coverage for the Cross coverpoint by cross-combining the coverage modules described in each of the involved coverpoints. That is, we cross-combine the boundary values ​​of the coverage modules described by each coverpoint where the Cross occurs. If all these cross-combinations have occurred, then the functional coverage of the Cross coverpoint will reach 100%. For example, assuming functional coverage point A includes 4 coverage modules and functional coverage point B includes 5 coverage modules, then there are 4 × 5 = 20 cross-combination ways to create the Cross functional coverage point between functional coverage points A and B, corresponding to 20 test cases. Execution verification based on these 20 test cases can ensure that all 20 cross-combination cases have occurred.

[0066] In one alternative embodiment, the method further includes:

[0067] The code for searching the intersection function coverage points based on the preset annotation pattern characters contains annotation information based on the annotation pattern characters.

[0068] If so, the annotation information is obtained; wherein the annotation information is used to represent the mapping relationship between the cross-functional coverage point and the simulation switch;

[0069] Then, configuring the simulation switch according to the coverage information and generating boundary use case files specifically involves:

[0070] Configure the simulation switch based on the coverage information and the annotation information to generate a boundary use case file.

[0071] Specifically, in conjunction with the above embodiments, when pre-constructing the fcov.sv code file corresponding to the functional coverage model, in addition to naming the cross-functional coverage points based on predefined naming pattern characters, customized annotations can also be performed on the cross-functional coverage points at the end of the code lines corresponding to the cross-functional coverage points using predefined annotation pattern characters. For example, annotation pattern characters in the form of " / / @" can be used, followed by annotation information. The annotation information can be pre-set and modified according to actual needs. Accordingly, the embodiments of the present invention can retrieve the code corresponding to each cross-functional coverage point based on the predefined annotation pattern characters to determine whether there is annotation information based on the annotation pattern characters. If so, the annotation information corresponding to the cross-functional coverage point can be obtained. In subsequent use case generation, the simulation switches associated with the cross-functional coverage points in the verification platform are configured according to the coverage bin information and annotation information corresponding to the cross-functional coverage points, so as to map the expected stimuli of the cross-functional coverage points to boundary use case files based on the switch configuration.

[0072] It should be noted that once the cross-use test case script file is in the format of " Customized annotations (e.g., " / / @") are identified at the end of the code line of the cross function coverage point named "_auto: cross". Different script preprocessing behaviors can be performed according to different annotation information to facilitate the control of the directed instruction flow during the use case transformation process.

[0073] It's important to note that annotation information can be used to represent the mapping relationship between cross-functional coverage points and simulation switches. For example, when parsing the code file of a functional coverage model using cross-use case scripts, only a few lines of code corresponding to the cross-functional coverage points can be extracted, but it's impossible to determine which specific simulation switch corresponds to each cross-functional coverage point. In this case, annotation information can be added to the cross-functional coverage points to indicate which simulation switch values ​​need to be modified. This eliminates the need to directly know which simulation switch the cross-functional coverage point depends on; the annotation information suffices to determine which switch value should be modified, facilitating flexible modification of the simulation switch values ​​associated with the cross-functional coverage points later. Furthermore, annotation information can also be used to represent value mappings. For instance, when defining a functional coverage model, the boundary values ​​of the coverage bins at functional coverage points may not directly correspond to the simulation switches; annotation information can be used to add details in such cases.

[0074] It should be noted that the purpose of this embodiment of the invention is to transform the cross-functional coverage points into switch configurations that can fully cover them, or a pool of use cases in the form of switch configurations. Therefore, the script preprocessing in the transformation process is all for the convenience of transformation, and the final processing result is just the transformation into the required use case pool. If the transformation can be performed directly, there is no need for additional annotation information. Why add annotation information? This is because defining the functional coverage model and writing the cross-test case script file are two independent tasks. When performing either part separately, such as describing the functional coverage points in the functional coverage model, one will certainly write it in whatever way is convenient. However, when using the cross-test case script file to parse the code file of the functional coverage model, if some modifications are made to the functional coverage model, then all the previously collected functional coverage will be invalidated, and functional coverage will need to be collected again for the modified functional coverage model. This process is very troublesome. Therefore, once the functional coverage model is defined, one certainly does not want to modify it. At this point, adding annotation information can facilitate the parsing of the cross-test case script file. In other words, adding annotation information is to facilitate subsequent script preprocessing, so that the cross-test case script file can perform different parsing and different preprocessing behaviors based on different annotation information.

[0075] It should be noted that the specific implementation of this embodiment of the invention requires the completion of three parts:

[0076] The first part requires verifying that the environment configuration has enough simulation switches to provide environmental support. This way, when the directional stimulus generator parses a large number of boundary test case files, it can directly convert these boundary test case files into different switch items and dynamically generate different directional instruction streams.

[0077] The second part, to improve the convergence performance of feature coverage, requires clearly defining what exactly the feature coverage to be collected is. This is a pre-defined part, and this work will be written in code within the fcov.sv file. Therefore, the fcov.sv file defines what feature coverage is, which feature coverages need to be collected, and so on. By using all the information defined in the fcov.sv file, we can assess which feature coverages have been collected and which have not. Dividing the number of uncollected feature coverages by the total number of feature coverages to be collected gives the percentage of feature coverage. Therefore, to facilitate the subsequent retrieval and scanning of the fcov.sv file by the bach.py ​​script, when constructing the fcov.sv file, we can set some special forms for the objects that the bach.py ​​script needs to scan, for example, by using a fixed suffix "". The cross-feature coverage points are named "_auto:cross". Additionally, if extra control information or information that the bach.py ​​script file needs to parse independently can be added, annotations can be used. For example, " / / @" can represent a fixed annotation pattern to indicate that this string of information needs to be understood and addressed by the bach.py ​​script file. With this annotation, the bach.py ​​script file knows how to handle user-defined behaviors. Through this process, the bach.py ​​script file, after parsing the fcov.sv code file, can determine which feature coverage needs to be collected.

[0078] The third part consists of two independently created files: the fcov.sv code file and the bach.py ​​script file. The bach.py ​​script file needs to have the ability to parse the fcov.sv code file (for example, by adding some customized annotations to the fcov.sv code file to facilitate parsing by the bach.py ​​script file) to generate a large number of test cases. The fcov.sv code file is parsed by the bach.py ​​script file in the form of data. The bach.py ​​script file will transform the parsed information into a large number of boundary test case files. Then, the boundary test case files are parsed by the verification environment (focusing on parsing the various switch items in the boundary test case files). Since the verification environment supports switch configuration, it can read these switch items during test case parsing and generate specific directional stimulus streams to send to the DUT.

[0079] In one optional embodiment, the verification platform further includes a constraint stimulus generator, and the method further includes:

[0080] The constraint stimulus generator is used to randomly generate a constraint stimulus flow that meets the preset constraint conditions, and the constraint stimulus flow is sent to the design under test to perform verification work.

[0081] like Figure 2 As shown, the verification environment of the verification platform also includes a constraint stimulus generator. The constraint stimulus generator is used to generate constraint stimulus streams and flow into the DUT. Accordingly, in specific implementation of this embodiment, the constraint stimulus generator can be used to randomly generate constraint stimulus streams that meet the pre-set constraint conditions, and send the generated constraint stimulus streams to the DUT to perform verification work.

[0082] It should be noted that, regarding the existing functional coverage convergence methods mentioned in the background section, the verification schemes corresponding to S01 and S02 can be derived from... Figure 2The verification process corresponding to the constraint excitation generator shown is implemented, and the verification process corresponding to S03 can be implemented by... Figure 2 The verification process corresponding to the directional excitation generator shown is optimized. In implementing the verification scheme of S02, the constraint content needs to be adjusted. When implementing the verification scheme of S03 using the embodiment of the present invention, the random range of the constraint also needs to be dynamically changed through the configuration of the simulation switch. Both involve the adjustment of the constraint range, and the underlying technical implementation is based on the same syntax. For example, both can adjust the constraint range by configuring the simulation switch. The simulation switch itself is not a switch with only two states in the physical sense, but can be configured to represent a certain value range or a certain value. For example, when a simulation switch is turned on, the corresponding generated constraint range will become larger or become a specific precise value. The specific configuration depends on the actual needs and can be defined by the user. Furthermore, in order to distinguish the constraint range in S02 and S03, the constraint range involved in S02 can be set to a relatively broad value range (for example, it can be constrained to be greater than a certain value or less than a certain value, which is a spatial range concept), while the constraint range involved in S03 can be set to a more precise value range (for example, it can be constrained to a specific boundary value or with a very small value range as the boundary).

[0083] It should be noted that since the constraint range involved in S02 is a relatively wide range of values, a large number of regression tests can be completed during code execution. Therefore, it can achieve the effect of "converging most of the functional coverage" corresponding to S01. After the verification scheme corresponding to S01 is completed, if the convergence effect of functional coverage is limited, the constraint content can be adjusted by executing the verification scheme corresponding to S02, and a large number of regression tests can be carried out again to converge the remaining functional coverage as much as possible. If the functional coverage is still not up to standard after the verification schemes corresponding to S01 and S02 are completed, the verification scheme of S03 can be optimized and implemented using the embodiment of the present invention to converge the last remaining boundary functional coverage.

[0084] Theoretically, the verification schemes corresponding to S01, S02, and S03 are all mainstream ideas. However, S01 and S02 have already improved the functional coverage to a bottleneck. Therefore, S03 is needed to further improve the final functional coverage value. However, implementing the verification scheme corresponding to S03 using existing methods often requires a lot of time, manually writing boundary test cases one by one, which is very inefficient. For example, assuming the functional coverage value is reduced to 10%, writing a boundary test case may only improve the functional coverage value by 0.01%, resulting in the need to manually write a large number of boundary test cases to achieve the remaining 10% functional coverage. Therefore, this embodiment of the invention uses script files to optimize the implementation of S03, which can automatically generate a large number of boundary test cases that originally needed to be written manually. This reduces some repetitive work during the convergence process of the remaining 10% functional coverage and also reduces some manual verification costs.

[0085] It should be noted that although adjusting the constraints is necessary when implementing the verification scheme corresponding to S02, it is generally not recommended to do so during actual verification. This is because: adjusting the constraints requires manual debugging and involves changes to the verification environment. Random constraints may be coupled with the environment, and constraints may be related and nested with each other, resulting in high costs for manual debugging and making the generated test cases difficult to reproduce. At the same time, since the code corresponding to S02 has already been written, if the constraints are adjusted, it is necessary to consider not only how to modify the code, but also how to restore it after the modification. Therefore, it is best to avoid modifying the code to avoid complicated modification work. In addition, after modifying the constraints (which is equivalent to modifying the code), recompiling is required, and the compilation process is time-consuming, which will have a certain impact on verification efficiency.

[0086] See Figure 3 The diagram shown is a structural block diagram of a verification platform provided in another embodiment of the present invention. Obviously, by comparison... Figure 2 and Figure 3 It can be seen that, Figure 3 The verification platform shown includes, in addition to Figure 2 In addition to the various modules shown, the verification platform also includes a reference model, driver monitor, and scoreboard, based on Figure 3The verification platform shown has a constraint stimulus generator that generates constraint stimulus streams in a constraint-based mode and a directional stimulus generator that generates directional stimulus streams in a switch-control-based mode. On one hand, the constraint stimulus streams and directional stimulus streams flow into the DUT through a driver. A monitor is used to monitor the actual behavior of the DUT and send it to the scoreboard. On the other hand, the constraint stimulus streams and directional stimulus streams flow directly into the reference model to calculate the expected behavior and send it to the scoreboard. The scoreboard is used to compare the actual behavior of the DUT with the expected behavior of the reference model to determine whether the DUT meets the design requirements.

[0087] For example, the DUT can be a computation module based on instruction stream, supporting the execution of various types of instruction operations, including data move instruction 1, data move instruction 2, data move instruction 3, addition operation instruction, subtraction operation instruction, multiplication operation instruction, division operation instruction, and other operation instructions.

[0088] For example, in terms of verification environment support, a directional excitation generator based on simulation switches needs to be established in the verification environment based on the instruction formats and DUT specifications. This ensures a one-to-one mapping between the directional generation of a single instruction (each key control information) and the configuration of the simulation switches. For instance, different instruction type fields, data movement mode fields, multiple data movement start and destination address fields, data format fields, data carry flag fields, and data rounding fields all have corresponding simulation switch support configurations. Within a single instruction, dependent variables not specified in the form of simulation switches will be generated freely and randomly.

[0089] For example, the actual verification work may include: (1) Based on the DUT's preset functional coverage plan, construct a complete functional coverage model, including functional coverage points, cross-functional coverage points, and boundary value cross-functional coverage points, etc. Among them, typical direct functional coverage points involve different instruction types and whether the address range, data range, control information, etc. of each instruction type are completely cross-covered. Boundary value sampling of such functional coverage points does not require additional annotation information because the instruction domain involved is the same as the simulation switch. Typical indirect functional coverage points involve the DUT's internal signal switching, credit mechanism analysis, arbitration. The statistics of logic and performance counters can be based on the mapping relationship with the external instruction stream. It is necessary to perform auxiliary annotation of annotation information in the functional coverage model so that the script can be mapped to use cases later; (2) Based on the DUT and functional coverage model, construct cross use case script files, automatically analyze and extract all use cases required for the cross functional coverage points of the functional coverage model. A single instruction will be represented as a switch configuration string, and multiple instructions will be stored in multiple boundary use case files in the form of switch configuration streams; (3) Start the verification simulation program and regression test, automatically read the boundary use case files, and complete the efficient improvement of functional coverage.

[0090] This invention also provides a verification apparatus for accelerating function coverage convergence, used to implement the verification method for accelerating function coverage convergence described in any of the above embodiments. See [link to relevant documentation]. Figure 4 The diagram shown is a structural block diagram of a verification device for accelerating functional coverage convergence according to an embodiment of the present invention. The device is applied to a verification platform, which includes a directional stimulus generator, a functional coverage model, and a design under test, and is equipped with a simulation switch. The device includes:

[0091] The code file parsing module 11 is used to parse the code file of the functional coverage model using a preset cross-use case script file, so as to extract the coverage compartment information corresponding to the cross-functional coverage points, configure the simulation switch according to the coverage compartment information, and generate boundary use case files.

[0092] The directional stimulus verification module 12 is used to read the switch configuration information in the boundary use case file using the directional stimulus generator, generate a directional stimulus flow based on the directional instruction sequence according to the switch configuration information, and send the directional stimulus flow to the design under test to perform verification work.

[0093] Preferably, the code file parsing module 11 specifically includes:

[0094] The function coverage group extraction unit is used to parse the code file of the function coverage model using a preset cross-test case script file in order to extract all function coverage groups of the function coverage model.

[0095] The cross-functional coverage point extraction unit is used to identify all cross-functional coverage points contained in each functional coverage group and obtain the coverage bin information corresponding to each cross-functional coverage point; wherein, the coverage bin information includes the number of coverage bins corresponding to each functional coverage point involved in the cross-functional coverage point and the boundary value corresponding to each coverage bin.

[0096] Preferably, the cross-functional coverage point extraction unit identifies all cross-functional coverage points contained in each functional coverage group, specifically including:

[0097] Based on the preset naming pattern characters, each function coverage group is searched to determine whether it contains function coverage points named based on the naming pattern characters.

[0098] If so, the function coverage point named based on the naming pattern characters will be identified as an intersecting function coverage point.

[0099] Preferably, the code file parsing module 11 further includes:

[0100] The coverage compartment cross-combination unit is used to cross-combine the coverage compartments corresponding to different functional coverage points involved in the same cross-functional coverage point for each cross-functional coverage point.

[0101] The boundary use case generation unit is used to configure the simulation switch differently according to different cross-combination methods, and generate boundary use case files in the form of switch configuration.

[0102] Preferably, the device further includes a labeling information acquisition module, used for:

[0103] The code for searching the intersection function coverage points based on the preset annotation pattern characters contains annotation information based on the annotation pattern characters.

[0104] If so, the annotation information is obtained; wherein the annotation information is used to represent the mapping relationship between the cross-functional coverage point and the simulation switch;

[0105] Then, the code file parsing module 11 configures the simulation switch according to the coverage information and generates boundary use case files, specifically:

[0106] Configure the simulation switch based on the coverage information and the annotation information to generate a boundary use case file.

[0107] Preferably, the verification platform further includes a constraint stimulus generator, and the device further includes:

[0108] The constraint stimulus verification module is used to randomly generate a constraint stimulus flow that meets the preset constraint conditions using the constraint stimulus generator, and send the constraint stimulus flow to the design under test to perform verification work.

[0109] It should be noted that the verification device for accelerating functional coverage convergence provided in the embodiments of the present invention can realize all the processes of the verification method for accelerating functional coverage convergence described in any of the above embodiments. The functions and technical effects of each module and unit in the device are the same as the functions and technical effects of the verification method for accelerating functional coverage convergence described in the above embodiments, and will not be repeated here.

[0110] This invention also provides a computer-readable storage medium including a stored computer program, which, when running, controls the device where the computer-readable storage medium is located to execute the verification method for accelerating function coverage convergence as described in any of the above embodiments.

[0111] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the verification method for accelerating function coverage convergence as described in any of the above embodiments.

[0112] This invention also provides a terminal device, see [link to relevant documentation]. Figure 5 The diagram shown is a structural block diagram of a terminal device according to an embodiment of the present invention. The terminal device includes a processor 10, a memory 20, and a computer program stored in the memory 20 and configured to be executed by the processor 10. When the processor 10 executes the computer program, it implements the verification method for accelerating function coverage convergence as described in any of the above embodiments.

[0113] Preferably, the computer program can be divided into one or more modules / units (such as computer program 1, computer program 2, ...), and the one or more modules / units are stored in the memory 20 and executed by the processor 10 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the terminal device.

[0114] The processor 10 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or the processor 10 may be any conventional processor. The processor 10 is the control center of the terminal device, connecting various parts of the terminal device through various interfaces and lines.

[0115] The memory 20 mainly includes a program storage area and a data storage area. The program storage area can store the operating system, applications required for at least one function, etc., while the data storage area can store related data, etc. Furthermore, the memory 20 can be a high-speed random access memory, or a non-volatile memory, such as a plug-in hard drive, a smart media card (SMC), a secure digital card (SD), and a flash card, or other volatile solid-state storage devices.

[0116] It should be noted that the aforementioned terminal devices may include, but are not limited to, processors and memory, as will be understood by those skilled in the art. Figure 5 The structural block diagram shown is merely a structural example of the terminal device described above and does not constitute a limitation on the structure of the terminal device. The terminal device may include more or fewer components than shown, or combine certain components, or use different components.

[0117] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A verification method for accelerating functional coverage convergence, characterized in that, The method, applied to a verification platform including a directed stimulus generator, a functional coverage model, and a design under test, and equipped with a simulation switch, comprises: The code file of the functional coverage model is parsed using a preset cross-use case script file to extract the coverage bin information corresponding to the cross-functional coverage points. The simulation switch is configured according to the coverage bin information to generate a boundary use case file. The random range of the constraints is changed by configuring the value of the simulation switch. The directional stimulus generator reads the switch configuration information in the boundary use case file, generates a directional stimulus flow based on the directional instruction sequence according to the switch configuration information, and sends the directional stimulus flow to the design under test to perform verification work.

2. The verification method for accelerating functional coverage convergence as described in claim 1, characterized in that, The step of parsing the code file of the functional coverage model using a preset cross-use case script file to extract coverage repository information corresponding to cross-functional coverage points specifically includes: The code file of the functional coverage model is parsed using a pre-defined cross-test case script file to extract all functional coverage groups of the functional coverage model; Identify all cross-functional coverage points contained in each functional coverage group, and obtain the coverage bin information corresponding to each cross-functional coverage point; wherein, the coverage bin information includes the number of coverage bins corresponding to each functional coverage point involved in the cross-functional coverage point and the boundary value corresponding to each coverage bin.

3. The verification method for accelerating functional coverage convergence as described in claim 2, characterized in that, The identification of all intersecting function coverage points contained in each function coverage group specifically includes: Based on the preset naming pattern characters, each function coverage group is searched to determine whether it contains function coverage points named based on the naming pattern characters. If so, the function coverage point named based on the naming pattern characters will be identified as an intersecting function coverage point.

4. The verification method for accelerating functional coverage convergence as described in claim 2, characterized in that, The step of configuring the simulation switch based on the coverage information and generating boundary use case files specifically includes: For each cross-functional coverage point, the coverage modules corresponding to the different functional coverage points involved in the same cross-functional coverage point are cross-combined. The simulation switch is configured differently according to different cross-combination methods, and boundary use case files of switch configuration form are generated.

5. The verification method for accelerating functional coverage convergence as described in claim 1, characterized in that, The method further includes: The code for searching the intersection function coverage points based on the preset annotation pattern characters contains annotation information based on the annotation pattern characters. If so, the annotation information is obtained; wherein the annotation information is used to represent the mapping relationship between the cross-functional coverage point and the simulation switch; Then, configuring the simulation switch according to the coverage information and generating boundary use case files specifically involves: Configure the simulation switch based on the coverage information and the annotation information to generate a boundary use case file.

6. The verification method for accelerating functional coverage convergence as described in claim 1, characterized in that, The verification platform also includes a constraint stimulus generator, and the method further includes: The constraint stimulus generator is used to randomly generate a constraint stimulus flow that meets the preset constraint conditions, and the constraint stimulus flow is sent to the design under test to perform verification work.

7. A verification device for accelerating functional coverage convergence, characterized in that, An apparatus for use in a verification platform, comprising a directed stimulus generator, a functional coverage model, and a design under test, and equipped with a simulation switch, the apparatus comprising: The code file parsing module is used to parse the code file of the functional coverage model using a preset cross-use case script file to extract the coverage bin information corresponding to the cross-functional coverage points, configure the simulation switch according to the coverage bin information, and generate boundary use case files; wherein, the random range of the constraints is changed by configuring the value of the simulation switch. The targeted stimulus verification module is used to read the switch configuration information in the boundary use case file using the targeted stimulus generator, generate a targeted stimulus flow based on the targeted instruction sequence according to the switch configuration information, and send the targeted stimulus flow to the design under test to perform verification work.

8. A computer-readable storage medium, characterized in that, The device includes a stored computer program that, when executed, controls the device containing the computer-readable storage medium to perform a verification method for accelerating function coverage convergence as described in any one of claims 1 to 6.

9. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the verification method for accelerating functional coverage convergence as described in any one of claims 1 to 6.

10. A terminal device, characterized in that, The system includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the verification method for accelerating functional coverage convergence as described in any one of claims 1 to 6.

Images