Method for Converting Functional Coverage Code, Computer Device and Medium

Abstract

The present application relates to the field of computer technology and provides a method for converting functional coverage code, a computer device, and a medium. The conversion method includes: obtaining a first verification plan; parsing the first verification plan to obtain a plurality of coverage groups corresponding to a combination of multiple verification scenarios; generating functional coverage statistical results of the plurality of coverage groups, and then, based on the functional coverage statistical results of the plurality of coverage groups, generating simulation test cases, where the simulation test cases are used to supplement the functional coverage code associated with the first verification plan. In this way, the automatic conversion of functional coverage code and the rapid convergence of functional coverage are achieved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a method for converting functional coverage code, a computer device, and a medium. Background Art

[0002] In application fields such as chip design and verification, due to the need for project management, the verification plans (vplans) of some projects are often sorted out. The verification plan describes the content that needs to be tested during pre-silicon verification. For example, the verification plan defines the usage characteristics of the product, and the use of the verification plan will run through the entire project cycle. In the prior art, based on the verification plan, verification personnel need to manually convert the functional coverage code. And when the project reaches the convergence (coverage) stage, it is very difficult to cover some functional coverage through random simulation. At this time, it is necessary to manually add directed simulation test cases to converge the functional coverage to 100%. The process of manually converting the functional coverage code often consumes a large amount of human and time costs. And during the conversion process, due to manual intervention, there are often some clerical errors, resulting in inconsistencies between the verification plan and the convergence code. And as the project progresses, the verification plan will also be continuously modified. At this time, it is also necessary to frequently modify the functional coverage code, which brings a lot of inconvenience to the project, resulting in low convergence efficiency and a high error probability.

[0003] Therefore, this application provides a method for converting functional coverage code, a computer device, and a medium to address the technical problems in the prior art. Summary of the Invention

[0004] In a first aspect, the present application provides a method for transforming functional coverage code. The transformation method includes: obtaining a first verification plan, where the first verification plan records hierarchical scenarios, command scenarios, and sub-functions. The hierarchical scenario indicates whether two adjacent data operations access the same level or different levels. The command scenario indicates whether two adjacent data operations are write-then-write, write-then-read, read-then-read, or read-then-write. The hierarchical scenario and the command scenario are used to generate multiple verification scenario combinations, and the sub-function indicates the function points associated with each of the multiple verification scenario combinations; parsing the first verification plan to obtain multiple cover groups corresponding to the multiple verification scenario combinations, where each cover group in the multiple cover groups includes coverage points for providing functional coverage of the function points associated with the verification scenario combination corresponding to the cover group, each cover group in the multiple cover groups further includes cross-coverage points for providing cross-coverage of the coverage points included in the cover group, and each cover group in the multiple cover groups further includes skip coding for indicating the cross-coverage points to be skipped among the cross-coverage points included in the cover group; generating a functional coverage statistical result of the multiple cover groups, and then, based on the functional coverage statistical result of the multiple cover groups, generating simulation test cases, where the simulation test cases are used to supplement the functional coverage code associated with the first verification plan.

[0005] In a possible implementation manner of the first aspect of the present application, the functional coverage code associated with the first verification plan is used to converge functional coverage based on the first verification plan during the functional verification phase.

[0006] In a possible implementation manner of the first aspect of the present application, generating the functional coverage statistical result of the multiple cover groups includes: counting whether the coverage points included in each cover group in the multiple cover groups are covered, counting whether the cross-coverage points included in each cover group in the multiple cover groups are indicated to be skipped by the skip coding included in the cover group, and counting whether the unskipped cross-coverage points included in each cover group in the multiple cover groups are covered.

[0007] In a possible implementation manner of the first aspect of the present application, based on the functional coverage statistical result of the multiple cover groups, generating the simulation test cases includes: generating the simulation test cases for targeted functional verification based on the uncovered coverage points and uncovered cross-coverage points included in each cover group in the multiple cover groups.

[0008] In a possible implementation of the first aspect of the present application, the conversion method further includes: after generating the functional coverage statistics results of the multiple coverage groups and before generating the simulation cases, determining the respective reduction options of the uncovered coverage points included in each of the multiple coverage groups, so as to determine the number of the simulation cases, where the reduction option indicates whether to construct a separate simulation case for the corresponding coverage point.

[0009] In a possible implementation of the first aspect of the present application, the function points associated with the multiple verification scenario combinations indicated by the sub-function are user-defined.

[0010] In a possible implementation of the first aspect of the present application, the first verification plan also records the respective coverage ranges and variable types of the function points indicated by the sub-function, and each of the multiple coverage groups further includes a special attention code for indicating the cross-coverage points that need special attention among the cross-coverage points included in the coverage group.

[0011] In a possible implementation of the first aspect of the present application, the first verification plan also records the respective designated scenario skip flags, designated scenario additional coverage ranges, designated scenario additional cross-function points, and designated scenario additional special attention function points of the function points indicated by the sub-function, where the designated scenario skip flag is used to indicate whether to skip the functional coverage of the corresponding function point when generating the functional coverage convergence of the designated scenario, the designated scenario additional coverage range is used to indicate the additional coverage range when generating the functional coverage convergence of the designated scenario, the designated scenario additional cross-function point is used to indicate the additional cross-coverage of the coverage points corresponding to the corresponding function point when generating the functional coverage convergence of the designated scenario, and the designated scenario additional special attention function point is used to indicate the cross-coverage points that need additional special attention when generating the functional coverage convergence of the designated scenario.

[0012] In a possible implementation of the first aspect of the present application, the designated scenario includes a DDR physical layer interface and a dynamic random access memory.

[0013] In a possible implementation of the first aspect of the present application, the first verification plan is used for a chip design project of a double data rate synchronous dynamic random access memory.

[0014] In a possible implementation of the first aspect of the present application, the hierarchical scenario and the command scenario are combined by using the Cartesian product method to obtain the multiple verification scenario combinations.

[0015] Second aspect, an embodiment of the present application further provides a computer device, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the method according to any implementation manner of any of the above aspects.

[0016] Third aspect, an embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions run on a computer device, the computer device is caused to execute the method according to any implementation manner of any of the above aspects.

[0017] Fourth aspect, an embodiment of the present application further provides a computer program product, which includes instructions stored on a computer-readable storage medium. When the instructions run on a computer device, the computer device is caused to execute the method according to any implementation manner of any of the above aspects.

[0018] The beneficial effects of this application are summarized as follows: By optimizing the data format of the first verification plan, it can meet the customized requirements of different chip development designs while being flexible enough to make adjustments for specific projects. Using the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, a data structure combining verification scenario combinations and function points can be achieved. With multiple verification scenario combinations covering various possible functional characteristics that may be encountered during the functional verification phase, these combinations are sufficient to meet the requirements of basic or advanced functions to be verified during the functional verification phase. Moreover, various verification scenario combinations for object switching in hierarchical scenarios and read / write switching in command scenarios are realized, which can ensure that key issues such as data inconsistency and process conflicts are particularly concerned when configuring the first verification plan and conducting functional verification. Based on the first verification plan, through the optimized data format of the first verification plan, a multi-level model is constructed based on the verification plan, which is conducive to extracting information for the generation and convergence of functional coverage through automated scripts, including the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, as well as cross-coverage points and skip encodings. By automatically extracting and sorting out this information, a multi-level model for the conversion of functional coverage in chip design projects is established. Thus, by providing a specific hierarchical model, it can better adapt to changes in the verification plan during the chip development process and lay a good foundation for the subsequent automated generation of functional coverage code and the rapid convergence of functional coverage. Based on the functional coverage statistical results of the multiple coverage groups, the coverage of relevant functional coverage can be extracted through automated scripts, and then auxiliary information can be provided to help generate a targeted use case list for generating simulation use cases to achieve complete functional coverage. The automated conversion of functional coverage code and the rapid convergence of functional coverage to 100% are realized. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings required for the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are some embodiments of this application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0020] Figure 1 A schematic diagram of a chip development project provided by an embodiment of this application;

[0021] Figure 2 A schematic flowchart of a method for converting functional coverage code provided by an embodiment of this application;

[0022] Figure 3 A schematic diagram of the structure of a computing device provided by an embodiment of this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

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

[0024] It should be understood that in the description of the present application, "at least one" means one or more, and "a plurality" means two or more. In addition, terms such as "first" and "second" are only used for the purpose of distinguishing descriptions unless otherwise specified, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying order.

[0025] Figure 1 It is a schematic diagram of a chip development project provided for the embodiments of the present application. As Figure 1As shown, the chip development project 100 includes multiple nodes: specification definition 102, system design 104, and front-end design 106. Among them, the specification definition 102 refers to setting the purpose and performance of the chip and the agreed standards to be met, that is, determining the requirements analysis of the chip and the overall design direction, such as determining the cost control level, power consumption sensitivity, supported connection methods, system security level, etc. The system design 104 refers to further determining the design of the chip architecture, business modules, power supply system, etc. based on the purpose, performance, and requirements of the chip determined in the specification definition 102, that is, performing function allocation and unit division, such as determining the interaction between each system, specific interfaces, etc. The front-end design 106 refers to, according to the solution determined in the system design 104, performing specific circuit design for each module, specifically including: using a hardware description language (HDL) such as Verilog HDL to perform register transfer level (RTL) code description of the hardware behavior, structure, and data flow of the circuit system. After the code is generated, it is simulated and verified according to the previously established specification standards, such as through electronic design automation (EDA) tools, to verify the correctness of the code design; finally, through a logic synthesis tool such as the automatic synthesis function of an EDA tool, the RTL code description is converted into a gate-level netlist, and it is determined whether various circuit parameters such as timing and area meet the standards. Generally, the front-end design 106 can be divided into sub-nodes such as analog circuit design, digital circuit design, and analog-digital hybrid circuit design, or it can be divided into sub-nodes of different functional modules according to different functional definitions, such as sub-nodes of an energy function module and sub-nodes of a storage function module. It can be seen that taking the chip development project 100 as an example, in the application field of chip design and verification, from the requirements set in the specification definition 102 to the function allocation and unit division determined in the system design 104, and then to the specific circuit design involved in the front-end design 106, as the chip development project 100 progresses, it may be necessary to repeatedly modify the chip design plan, for example, it may be necessary to re-set the requirements of the chip. It should be understood that Figure 1 The chip development project 100 shown is only exemplary. Figure 1 It is also shown that during the entire development cycle of the chip development project 100, a verified plan (vplan) 120 is used, and the verified plan 120 is also used in the functional verification phase 130.

[0026] Refer to Figure 1, the verification plan 120 describes what needs to be tested during pre-silicon verification. The verification plan 120 defines and describes what needs to be tested during functional verification. For example, assuming the chip development project 100 is for developing an artificial intelligence chip or a digital signal processing chip, the parameters to be tested will have different focuses. The verification plan 120 needs to determine what to verify during the functional verification phase 130, such as creating and testing a series of scenarios and use cases to ensure that a specific circuit performs as expected. The verification plan 120 can also include determining the chip function priorities. In some embodiments, the verification plan 120 includes a list of steps for indicating the aspects to be focused on and the potential functions to be understood when performing functional verification during the functional verification phase 130. For example, assuming the chip development project 100 is for a graphics processing unit chip, some users expect better game rendering performance, so there is a higher demand for the chip's accelerated media function. For this reason, the verification plan 120 needs to determine which functions in the chip design need to be tested during the functional verification phase 130, and then determine how to test, including decomposing each function to be tested into different steps. For example, assuming the function to be tested is the camera function of a smartphone, generally speaking, the steps to operate the smartphone to take a photo are as follows: open the main menu, then, open the camera function, and then, press the shutter button. And, after taking a photo, the application responsible for taking photos also needs to access the hardware camera and storage device, and perform algorithmic processing on the taken photo through the processor. Additionally, if the photo needs to be transmitted, a wireless connection module is also required. Therefore, the verification plan 120 and the functional verification phase 130 need to simulate the above functions and corresponding chip design modules, such as simulating access to the camera, simulating photo shooting, and simulating storing photos and performing algorithmic processing on photos. It can be seen that with the increasing complexity of chip design and the growing richness of the functions of end products, various challenges have been encountered in sorting out the verification plan 120 related to the chip development project 100 and ensuring 100% functional coverage during the project convergence phase. For example, the usage functions of the product and the design expectations of the chip may change from time to time. Additionally, the verification team members may encounter problems with poor conversion effects of functional coverage code in their respective complex directions. If relying on manual intervention, not only does it increase the time cost and labor cost, but also results in low convergence efficiency and a high error probability. Additionally, during the project convergence phase, the complete time taken for a single simulation use case, as well as subsequent analysis and feedback, may also take a long time. Therefore, the verification duration should be compressed as much as possible and the simulation scale should be controlled. However, relying on manual methods to manually fill in the areas not covered by the functional coverage code often requires adding verification scenarios for directed testing and corresponding functional verification code, which is not conducive to improving verification efficiency and shortening the verification duration.Combined with specific embodiments of the present application, the following will detail a method for converting functional coverage code, a computer device, and a medium provided by the embodiments of the present application. How, through an optimized method for converting functional coverage code and a multi-level model constructed based on a verification plan, the automated conversion of functional coverage code and the rapid convergence of functional coverage to 100% are achieved.

[0027] Figure 2 It is a schematic flowchart of a method for converting functional coverage code provided by an embodiment of the present application. As Figure 2 shown, the conversion method includes the following steps.

[0028] Step S201: Obtain a first verification plan, where the first verification plan records a hierarchical scenario, a command scenario, and sub-functions. The hierarchical scenario indicates whether two adjacent data operations access the same level or different levels. The command scenario indicates whether two adjacent data operations are write-then-write, write-then-read, read-then-read, or read-then-write. The hierarchical scenario and the command scenario are used to generate multiple verification scenario combinations, and the sub-functions indicate the function points associated with each of the multiple verification scenario combinations.

[0029] Step S203: Parse the first verification plan to obtain multiple cover groups corresponding to the multiple verification scenario combinations. Each cover group in the multiple cover groups includes cover points for providing functional coverage of the function points associated with the verification scenario combination corresponding to the cover group. Each cover group in the multiple cover groups also includes cross-cover points for providing cross-coverage of the cover points included in the cover group. Each cover group in the multiple cover groups also includes skip coding for indicating the cross-cover points to be skipped among the cross-cover points included in the cover group.

[0030] Step S205: Generate the functional coverage statistical results of the multiple cover groups, and then, based on the functional coverage statistical results of the multiple cover groups, generate simulation test cases, which are used to supplement the functional coverage code associated with the first verification plan.

[0031] Refer to Figure 2 , in step S201, obtain a first verification plan. Where the first verification plan records a hierarchical scenario, a command scenario, and sub-functions. The hierarchical scenario indicates whether two adjacent data operations access the same level or different levels. The command scenario indicates whether two adjacent data operations are write-then-write, write-then-read, read-then-read, or read-then-write. The hierarchical scenario and the command scenario are used to generate multiple verification scenario combinations, and the sub-functions indicate the function points associated with each of the multiple verification scenario combinations. Here, the first verification plan can correspond to any chip development project, for exampleFigure 1 The chip development project 100 shown. The first verification plan can be directly exported by an electronic design assistant tool or edited and generated by a word processing software, and can adopt a table format such as the xml file format. The first verification plan can be used for the conversion work of one or more function-related functional coverage codes. For example, the first verification plan can be used for the chip design project of Double Data Rate Synchronous Dynamic Random Access Memory (DDR SRAM); for another example, the first verification plan can be used for the relevant functional coverage of the DDR Physical Layer Interface (DFI); for another example, the first verification plan can be used for the relevant functional coverage of dynamic random access memory (DRAM). Generally, in chip design and development, the DDR memory interface is divided into two parts: Memory Controller (MC) and Physical Interface (PHY). DFI is used to provide a standard communication interface between MC and PHY. Considering that different chip development projects have different focuses and also require different design skills and experiences, for example, both MC and PHY are parts of the DDR memory interface but generally use different interconnection standards, therefore, the corresponding verification plan needs to be adjusted accordingly. To improve the processing efficiency of the automation script, Figure 2 The conversion method shown, by optimizing the data format of the first verification plan in the design, can meet the customized requirements of different chip development designs and can also be flexibly adjusted for a specified project, which will be described in detail below.

[0032] Continue to refer to Figure 2, the first verification plan records a hierarchical scenario, a command scenario, and sub-functions. The hierarchical scenario indicates whether two adjacent data operations access the same level or different levels. Here, the same level (single rank) and different levels (cross rank) can be used to distinguish whether the objects on which the data operations act are the same. If two adjacent data operations access the same level, the hierarchical scenario is the same level, which means two adjacent data operations on the same object; if two adjacent data operations access different levels, the hierarchical scenario is different levels (cross rank), which means two adjacent data operations on different objects. The command scenario indicates whether two adjacent data operations are write-then-write, write-then-read, read-then-read, or read-then-write. The hierarchical scenario and the command scenario are used to generate various verification scenario combinations. The sub-functions indicate the function points associated with each of the various verification scenario combinations. Thus, by using the hierarchical scenario, command scenario, and sub-functions recorded in the first verification plan, a data structure that combines verification scenario combinations with function points can be implemented, and various possible functional characteristics that may be encountered during the functional verification phase are covered by the various verification scenario combinations. The functional characteristics to be verified generally involve basic functions such as data processing, data reading, and data writing. Advanced functions such as network transmission and camera photography can also be disassembled into combinations of a series of data operations such as data processing, data reading, and data writing through corresponding modules and circuits. Therefore, performing two data operations on the same object successively, or performing two data operations on different objects successively, and combining whether the two successive data operations are write-then-write, write-then-read, read-then-read, or read-then-write, the various verification scenario combinations obtained in this way are sufficient to meet the requirements of the basic functions or advanced functions to be verified during the functional verification phase. Further, in terms of verification related to data processing and data storage, data inconsistency is a key factor leading to system errors and process conflicts. Through the optimized design of the data format of the first verification plan, various verification scenario combinations for object switching in the hierarchical scenario and read / write switching in the command scenario are realized, which can ensure that key issues such as data inconsistency and process conflicts are particularly noted when configuring the first verification plan and performing functional verification. Further, the sub-functions indicate the function points associated with each of the various verification scenario combinations. Therefore, a data structure of verification scenarios and function points can be constructed according to the own requirements of the specified project and the user customization requirements.For example, for the verification scenario combination where the rank scenario is the same rank (single rank) and the command scenario is write-then-write, the functional points that need to be concerned about can include bubble delay (bubble_dly), preamble write mode (mode_wr_preamble), and postamble write mode (mode_wr_postamble), so as to better adapt to the DDR protocol and DDR operating mechanism.

[0033] Continue to refer to Figure 2, in step S203, parse the first verification plan to obtain multiple covergroups corresponding to the multiple combinations of verification scenarios. Each of the multiple covergroups includes coverpoints for providing functional coverage of the function points associated with the verification scenario combination corresponding to the covergroup. Each of the multiple covergroups also includes cross coverpoints for providing cross coverage of the coverpoints included in the covergroup. Each of the multiple covergroups also includes an ignore bin for indicating the cross coverpoints to be skipped among the cross coverpoints included in the covergroup. As mentioned above, through the optimized data format of the first verification plan, using the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, a data structure combining verification scenario combinations with function points can be achieved. The multiple combinations of verification scenarios cover various possible functional characteristics that may be encountered in the functional verification phase. The multiple combinations of verification scenarios are sufficient to meet the requirements of the basic functions or advanced functions to be verified in the functional verification phase. Moreover, various verification scenario combinations for object switching in hierarchical scenarios and read / write switching in command scenarios are realized, which can ensure that key issues such as data inconsistency and process conflicts are particularly concerned when configuring the first verification plan and performing functional verification. In step S203, based on the first verification plan, by parsing the first verification plan, multiple covergroups corresponding to the multiple combinations of verification scenarios are obtained. And each of the multiple covergroups includes coverpoints for providing functional coverage of the function points associated with the verification scenario combination corresponding to the covergroup. Thus, the conversion of functional coverage from the first verification plan to multiple covergroups is realized. Further, a multi-level model is constructed based on the verification plan, which helps to quickly converge the functional coverage. Specifically, each of the multiple covergroups also includes cross coverpoints for providing cross coverage of the coverpoints included in the covergroup. Each of the multiple covergroups also includes an ignore bin for indicating the cross coverpoints to be skipped among the cross coverpoints included in the covergroup. Here, the cross coverpoints can be specifically indicated by digital numbers. For example, the digital number "0" is used to indicate that there is no need to perform cross coverage with any other coverpoint, and other digital numbers are used for differentiation. The cross coverpoints with the same digital number are placed in the same group. In addition, the ignore bin is used to indicate the cross coverpoints that need to be skipped in each covergroup, that is, the corresponding function points that need to be ignored. The ignore bin can indicate specific function points by variable names or can separate different function points to be ignored by indicating a range of contents, such as continuous values or non-continuous values.Thus, by optimizing the data format of the first verification plan and constructing a multi-level model based on the verification plan, it is beneficial to extract information for the generation and convergence of functional coverage through automated scripts, including the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, as well as cross-coverage points and skip encodings. By automatically extracting and sorting out this information, a multi-level model for the conversion of functional coverage in the chip design project is established. Thus, by providing a specific hierarchical model, it is possible to better adapt to changes in the verification plan during the chip development process and lay a good foundation for the subsequent automated generation of functional coverage code and the rapid convergence of functional coverage. Taking a graphic processing unit (GPU) as an example, assume that the function to be verified is the image rendering function when running large programs such as games and the media function such as animation generation during creative design. Then, the first verification plan can be configured accordingly and the corresponding coverage groups can be generated. For example, when verifying the image rendering function point, the image rendering function of the game platform software can be additionally covered, and the storage function point of the GPU can also be cross-covered. This is because a large number of instantaneously generated images need to be stored in the game verification scenario. Moreover, the network transmission function point of the GPU can be selected to be skipped (games that require a large amount of image rendering processing are generally single-player games, so the demand for network transmission function is limited). Thus, for the coverage point corresponding to the image rendering function, the storage function point can be set as the corresponding cross-coverage point, that is, when verifying the coverage point corresponding to the image rendering function, the cross-coverage point corresponding to the storage function point should also be cross-covered; and when verifying the coverage point corresponding to the image rendering function, the network transmission function point can be selected to be ignored, so as to compress the occupation of verification resources as much as possible while meeting the functional verification requirements. Another example is that when verifying the media function such as the animation generation function point, the corresponding cross-coverage points and skip encodings can also be set, so that the cross-coverage of relevant function points can be provided specifically and some function points can be selectively skipped or ignored, thereby improving the convergence efficiency.

[0034] Continue to refer to Figure 2, in step S205, generate the functional coverage statistics results of the multiple coverage groups, and then, based on the functional coverage statistics results of the multiple coverage groups, generate simulation test cases, which are used to supplement the functional coverage code associated with the first verification plan. As described above, through the optimized design of the data format for the first verification plan, using the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, a data structure that combines verification scenario combinations with functional points can be achieved. By using multiple verification scenario combinations, various possible functional characteristics that may be encountered in the functional verification phase are covered. The multiple verification scenario combinations are sufficient to meet the requirements of the basic functions or advanced functions to be verified in the functional verification phase. Moreover, various verification scenario combinations for object switching in the hierarchical scenario and read / write switching in the command scenario are realized, which can ensure that key issues such as data inconsistency and process conflicts are particularly concerned when configuring the first verification plan and performing functional verification. Based on the first verification plan, through the optimized design of the data format for the first verification plan, a multi-level model is constructed based on the verification plan, which is conducive to extracting information for the generation and convergence of functional coverage through automated scripts, including the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, as well as cross-coverage points and skip coding. By automatically extracting and sorting out this information, a multi-level model for the conversion of functional coverage for chip design projects is established. Thus, by providing a specific hierarchical model, it can better adapt to the changes in the verification plan during the chip development process and lay a good foundation for the subsequent automated generation of functional coverage code and the rapid convergence of functional coverage. Thus, after realizing the conversion from the first verification plan to functional coverage, the automated convergence from the first verification plan to functional coverage can be achieved. Using the functional coverage statistics results of the multiple coverage groups, the coverage statistics related situations of each coverage group can be determined, such as the coverage situations of each functional point and cross-coverage point. For the functional points to be skipped, the status "Excluded" can be used to indicate that the functional point is excluded when generating the coverage statistics report in the convergence stage, while for the covered functional points, the status "Covered bins" can be set, and for the uncovered functional points, the status "Uncovered bins" can be set. Thus, based on the functional coverage statistics results of the multiple coverage groups, the coverage situations of relevant functional coverage can be extracted through automated scripts, and then auxiliary information can be provided to help generate a targeted test case list for generating simulation test cases to achieve complete functional coverage. For example, after extracting the information of the coverage group, these information and text processing mapping scripts can be used to generate a test case list that can be regressed, and through the regression test case list, one hundred percent functional coverage can be achieved.

[0035] Continue to refer to Figure 2, after completing the transformation from verification planning to functional coverage in the first stage, the second stage is an automated solution for rapid convergence. Using a multi-level model, automated scripts can be used to extract the coverage of functional coverage. Then, for coverage groups that do not reach 100% coverage, a targeted test case list is automatically generated, including adding corresponding parameters. For example, if the additional coverage range of a certain function point in a coverage group is not covered, a functional verification instance can be generated for this. For example, the following information can be utilized: "Summary for Variable for Special symbols such as *" indicates the coverpoint name. Here, "Special symbols" indicates the defined coverpoint name; "Summary for Cross Special symbols" indicates the cross coverpoint name; "Uncovered bins" and "Covered bins" define the coverage of this coverpoint; each line in "Element holes" will have the symbol "Special symbols". Here, the symbol "Special symbols such as *" indicates that any value in this function point has not been covered. Additionally, "STATUS" shows "Excluded", which means this function point was excluded when generating the coverage. Based on the above information, scripts can be used to extract the coverage of relevant functional coverage.

[0036] In summary, Figure 2The conversion method of the functional coverage code shown can, by optimizing the designed data format of the first verification plan, meet the customization requirements of different chip development designs while also being flexible in making adjustments for a specified project; by using the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, a data structure that combines verification scenarios and function points can be implemented. Multiple combinations of verification scenarios cover various possible functional characteristics that may be encountered during the functional verification phase. Multiple combinations of verification scenarios are sufficient to meet the requirements of the basic functions or advanced functions to be verified during the functional verification phase. Moreover, various combinations of verification scenarios for object switching in hierarchical scenarios and read / write switching in command scenarios are implemented, which can ensure that key issues such as data inconsistency and process conflicts are specifically addressed when configuring the first verification plan and conducting functional verification; based on the first verification plan, by optimizing the designed data format of the first verification plan, a multi-level model is constructed based on the verification plan, which is conducive to extracting information for the generation and convergence of functional coverage through automated scripts, including the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, as well as cross-coverage points and skip encodings. By automatically extracting and sorting out this information, a multi-level model for the conversion of functional coverage for chip design projects is established. Thus, by providing a specific hierarchical model, it can better adapt to changes in the verification plan during the chip development process and lay a good foundation for the subsequent automated generation of functional coverage code and the rapid convergence of functional coverage; based on the functional coverage statistical results of the multiple coverage groups, the coverage of relevant functional coverage can be extracted through automated scripts, and then auxiliary information can be provided to help generate a targeted test case list for generating simulation test cases to achieve complete functional coverage; the automated conversion of functional coverage code and the rapid convergence of functional coverage to one hundred percent are achieved.

[0037] Refer to Figure 1 and Figure 2 In a possible implementation manner, the functional coverage code associated with the first verification plan is used to perform functional coverage convergence based on the first verification plan during the functional verification phase. Thus, by optimizing the designed data format of the first verification plan, it can meet the customization requirements of different chip development designs while also being flexible in making adjustments for a specified project, constructing a multi-level model based on the verification plan, and using the functional coverage code associated with the first verification plan to perform functional coverage convergence during the functional verification phase, which helps to ensure the smooth execution of the first verification plan, is conducive to extracting information for the generation and convergence of functional coverage through automated scripts, and achieves the automated conversion of functional coverage code and the rapid convergence of functional coverage to one hundred percent.

[0038] In a possible implementation manner, generating the functional coverage statistical results of the multiple coverage groups includes: counting whether the coverage points included in each of the multiple coverage groups are covered, counting whether the cross-coverage points included in each of the multiple coverage groups are to be skipped as indicated by the skip encoding included in the coverage group, and counting whether the non-skipped cross-coverage points included in each of the multiple coverage groups are covered. In this way, through the optimized data format of the first verification plan, a multi-level model is constructed based on the verification plan, which is conducive to extracting information for the generation and convergence of functional coverage through automated scripts, including the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, as well as cross-coverage points and skip encoding. By automatically extracting and sorting out this information, a multi-level model for the conversion of functional coverage in a chip design project is established. Moreover, by counting whether the coverage points are covered and whether the cross-coverage points are covered, more abundant and hierarchical statistical information can be provided, improving the reference value of the functional coverage statistical results. In this way, by providing a specific hierarchical model, it is possible to better adapt to the changes in the verification plan during the chip development process and lay a good foundation for the subsequent automated generation of functional coverage code and the rapid convergence of functional coverage.

[0039] In some embodiments, generating the simulation test cases based on the functional coverage statistical results of the multiple coverage groups includes: generating the simulation test cases for directed functional verification based on the uncovered coverage points and uncovered cross-coverage points included in each of the multiple coverage groups. In this way, after realizing the conversion from the first verification plan to functional coverage, it is possible to achieve the automated convergence from the first verification plan to functional coverage. By using the functional coverage statistical results of the multiple coverage groups, the coverage statistical related situation of each coverage group can be determined. Based on the functional coverage statistical results of the multiple coverage groups, including the uncovered coverage points and uncovered cross-coverage points, the coverage situation of the relevant functional coverage can be extracted through automated scripts, and then auxiliary information can be provided to help generate a directed test case list for generating simulation test cases for directed functional verification, which helps to achieve complete functional coverage.

[0040] In some embodiments, the transformation method further includes: after generating the functional coverage statistics results of the multiple coverage groups and before generating the simulation cases, determining the respective reduction options for each uncovered coverage point included in each of the multiple coverage groups, so as to determine the number of the simulation cases, wherein the reduction option indicates whether to construct a separate simulation case for the corresponding coverage point. Here, the reduction option can be understood as a fold feature. Considering that the system consumes a large amount of simulation time during power-on, reset, and initialization, sometimes in order to improve the verification efficiency, as many function points as possible are covered under a set of randomly generated configurations, which can reduce the waste of simulation time during system startup and allocate more simulation resources for the verification of system functions. Taking the function point bubble delay "bubble_dly" as an example, if it is desired to cover all ranges of the bubble delay function point "bubble_dly" in one simulation, it is not necessary to construct a separate simulation case for each point. By setting the attribute of the reduction option of the bubble delay function point "bubble_dly" to 1, the generated simulation case list can be made to ignore the bubble delay function point "bubble_dly", and only one simulation case is formed. For another example, the attribute of the reduction option can be set to 0, 1, or 2. If it is set to 0, it is directly ignored without covering under the simulation case. If it is set to 1, it is covered under one simulation case without the need to construct a separate simulation case. If it is set to 2, a separate simulation case needs to be constructed. Thus, after generating one simulation case, a conversion operation from 1 to 0 is performed on the attributes of the reduction options of the function points covered by this simulation case, so that when subsequent simulation cases are generated, the function points with the attribute of the reduction option being 0 can be directly ignored, achieving the reduction purpose and being beneficial to improving the overall efficiency.

[0041] In a possible implementation manner, the function points associated with each of the multiple verification scenario combinations indicated by the sub-functions are user-defined. In this way, according to the own requirements of the specified project and the user customization requirements, the data structure of the verification scenarios and function points can be constructed, which can meet the customization requirements of different chip development designs and can also be flexibly adjusted for the specified project.

[0042] In a possible implementation manner, the first verification plan also records the coverage range and variable type of each function point indicated by the sub-function, and each coverage group in the multiple coverage groups further includes a special attention code for indicating the cross-coverage points to be specially concerned about among the cross-coverage points included in this coverage group. Here, the special attention code can be combined with the application of the cross-coverage points. By using the special attention code, in the case of a large scale of cross-coverage, special cross-coverage points can be generated for the corresponding function points and ranges, realizing user-defined special attention and providing a decision-making basis for subsequent processes.

[0043] In some embodiments, the first verification plan also records the designated scenario skip identifier, designated scenario additional coverage, designated scenario additional cross-functional points, and designated scenario additional special attention functional points for each functional point indicated by the sub-function. Among them, the designated scenario skip identifier is used to indicate whether to skip the functional coverage of the corresponding functional point when generating the functional coverage convergence of the designated scenario; the designated scenario additional coverage is used to indicate the additional coverage when generating the functional coverage convergence of the designated scenario; the designated scenario additional cross-functional points are used to indicate the additional cross-coverage of the coverage points corresponding to the corresponding functional points when generating the functional coverage convergence of the designated scenario; the designated scenario additional special attention functional points are used to indicate the cross-coverage points that require additional special attention when generating the functional coverage convergence of the designated scenario. As described above, by optimizing the designed data format of the first verification plan and constructing a multi-level model based on the verification plan, it is beneficial to extract information for the generation and convergence of functional coverage through automated scripts, including the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, as well as cross-coverage points and skip encodings. By automatically extracting and sorting out this information, a multi-level model for the conversion of functional coverage in a chip design project is established. Here, the first verification plan records more abundant information, including the designated scenario skip identifier, designated scenario additional coverage, designated scenario additional cross-functional points, and designated scenario additional special attention functional points, etc. In this way, by providing a specific hierarchical model, it is possible to better adapt to the changes in the verification plan during the chip development process. For example, the designated scenario skip identifier is used to indicate whether to skip the functional coverage of the corresponding functional point when generating the functional coverage convergence of the designated scenario, and it lays a foundation for the subsequent automated generation of functional coverage code and the rapid convergence of functional coverage. Further, through the designated scenario skip identifier, designated scenario additional coverage, designated scenario additional cross-functional points, and designated scenario additional special attention functional points, more flexible customization operations can be provided. For example, the first verification plan can be used simultaneously for the functional verification of two designated scenarios: the DDR physical layer interface (DDR PHY Interface, DFI) and the dynamic random access memory (dynamic RAM, DRAM). The designated scenario skip identifier, designated scenario additional coverage, designated scenario additional cross-functional points, and designated scenario additional special attention functional points can be provided separately for DFI. In this way, when generating the functional coverage of DFI, certain functional points can be skipped, certain ranges can be additionally covered, additional cross-coverage can be provided, and additional special attention can be given to certain functional points.Thus, based on the cross-coverage points, skip encoding, coverage range, and special attention encoding mentioned above, for a specified scenario, through the specified scenario skip identifier, specified scenario additional coverage range, specified scenario additional cross-functional points, and specified scenario additional special attention functional points, more flexible customization options can be provided when the functional coverage of the specified scenario converges.

[0044] In a possible implementation manner, the specified scenario includes a DDR physical layer interface (DDR PHY Interface, DFI) and a dynamic random access memory (dynamic RAM, DRAM). Generally, in chip design and development, the DDR memory interface is divided into two parts: a memory control logic (Memory Controller, MC) and a physical layer interface (Physical Interface, PHY). The DFI is used to provide a standard communication interface between the MC and the PHY. Considering that different chip development projects have different focuses and also require different design skills and experiences, for example, both the MC and the PHY are parts of the DDR memory interface but generally use different interconnection standards, the corresponding verification plan needs to be adjusted accordingly. Thus, in order to improve the processing efficiency of the automated script, by optimizing the data format of the first verification plan, it is possible to meet the customization requirements of different chip development designs and also make flexible adjustments for a specified project.

[0045] In a possible implementation manner, the first verification plan is used for a chip design project of a double data rate synchronous dynamic random access memory (Double Data Rate Synchronous Dynamic Random Access Memory, DDR SRAM). Taking DDR SRAM as an example, sometimes simply referred to as DDR, in the design and development of storage chips, in terms of verification related to data processing and data storage, data inconsistency is a key factor leading to system errors and process conflicts. Thus, by optimizing the data format of the first verification plan, various verification scenario combinations of object switching in the hierarchical scenario and read / write switching in the command scenario are realized, which can ensure that key issues such as data inconsistency and process conflicts are particularly concerned when configuring the first verification plan and performing functional verification.

[0046] In a possible implementation, the hierarchical scenarios and the command scenarios are combined by means of the Cartesian product to obtain the multiple verification scenario combinations. In this way, by using the hierarchical scenarios, command scenarios, and sub-functions recorded in the first verification plan, a data structure combining verification scenario combinations with function points can be realized, and various possible functional characteristics that may be encountered in the functional verification phase are covered by the multiple verification scenario combinations. The functional characteristics to be verified generally involve basic functions such as data processing, data reading, and data writing. Advanced functions such as network transmission and camera photographing can also be disassembled into combinations of a series of data operations such as data processing, data reading, and data writing through corresponding modules and circuits. Therefore, performing two data operations on the same object successively, or performing two data operations on different objects successively, and combining the two data operations successively as write-then-write, write-then-read, read-then-read, or read-then-write, the multiple verification scenario combinations obtained in this way are sufficient to meet the requirements of the basic functions or advanced functions to be verified in the functional verification phase.

[0047] Figure 3 FIG. is a schematic structural diagram of a computing device provided by an embodiment of the present application. The computing device 300 includes one or more processors 310, a communication interface 320, and a memory 330. The processor 310, the communication interface 320, and the memory 330 are interconnected through a bus 340. Optionally, the computing device 300 may further include an input / output interface 350. The input / output interface 350 is connected to an input / output device for receiving parameters set by a user, etc. The computing device 300 can be used to implement some or all of the functions of the device embodiment or the system embodiment in the above embodiment of the present application; the processor 310 can also be used to implement some or all of the operation steps of the method embodiment in the above embodiment of the present application. For example, the specific implementation of the computing device 300 performing various operations can refer to the specific details in the above embodiments. For example, the processor 310 is used to execute some or all of the steps or some or all of the operations in the above method embodiment. For another example, in the embodiment of the present application, the computing device 300 can be used to implement some or all of the functions of one or more components in the above device embodiment. In addition, the communication interface 320 can specifically be used for communication functions necessary to implement the functions of these devices and components, etc., and the processor 310 can specifically be used for processing functions necessary to implement the functions of these devices and components, etc.

[0048] It should be understood that Figure 3The computing device 300 may include one or more processors 310, and the multiple processors 310 may cooperate to provide processing capabilities in a parallel connection mode, a serial connection mode, a serial-parallel connection mode, or any connection mode. Alternatively, the multiple processors 310 may form a processor sequence or a processor array, or the multiple processors 310 may be divided into a main processor and an auxiliary processor, or the multiple processors 310 may have different architectures such as a heterogeneous computing architecture. Additionally, Figure 3 For the computing device 300 shown, the related structural descriptions and functional descriptions are exemplary and non-limiting. In some exemplary embodiments, the computing device 300 may include more or fewer components than Figure 3 shown, or combine certain components, or split certain components, or have a different component arrangement.

[0049] The processor 310 can have various specific implementation forms. For example, the processor 310 can include one or a combination of a central processing unit (CPU), a graphic processing unit (GPU), a neural-network processing unit (NPU), a tensor processing unit (TPU), or a data processing unit (DPU), etc., and the embodiments of the present application do not make specific limitations. The processor 310 can also be a single-core processor or a multi-core processor. The processor 310 can be a combination of a CPU and a hardware chip. The above-mentioned hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above-mentioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 310 can also be implemented separately by a logic device with built-in processing logic, such as an FPGA or a digital signal processor (DSP), etc. The communication interface 320 can be a wired interface or a wireless interface for communicating with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless local area network interface, etc.

[0050] The memory 330 can be a non-volatile memory, for example, read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), or flash memory. The memory 330 can also be a volatile memory, and the volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM). The memory 330 can also be used to store program code and data, so that the processor 310 can call the program code stored in the memory 330 to execute some or all of the operation steps in the above method embodiments, or execute the corresponding functions in the above device embodiments. In addition, the computing device 300 may include more or fewer components than Figure 3 shown, or have a different component configuration.

[0051] The bus 340 can be a Peripheral Component Interconnect Express (PCIe) bus, or an Extended Industry Standard Architecture (EISA) bus, Unified Bus (Ubus or UB), Compute Express Link (CXL), Cache Coherent Interconnect for Accelerators (CCIX), etc. The bus 340 can be divided into an address bus, a data bus, a control bus, etc. In addition to the data bus, the bus 340 can also include a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity,Figure 3 It is represented by only one thick line, but it does not mean that there is only one bus or one type of bus.

[0052] The methods and devices provided in the embodiments of the present application are based on the same inventive concept. Since the principles of the methods and devices for solving problems are similar, the embodiments, implementation manners, examples, or implementation modes of the methods and devices can be referred to each other, and the repeated parts will not be described again. The embodiments of the present application also provide a system, which includes multiple computing devices. The structure of each computing device can refer to the structure of the computing device described above. The functions or operations that the system can implement can refer to the specific implementation steps in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be described again here.

[0053] The embodiments of the present application also provide a computer-readable storage medium. Computer instructions are stored in the computer-readable storage medium. When the computer instructions run on a computer device (such as one or more processors), the method steps in the above method embodiments can be implemented. The specific implementation of the processor of the computer-readable storage medium when executing the above method steps can refer to the specific operations described in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be described again here.

[0054] Those skilled in the art should understand that the embodiments of this application can be provided as a method, a system, or a computer program product. This application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. The embodiments of this application can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. This application can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, the processes or functions described in the embodiments of this application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center containing one or more collections of available media. The available medium can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium, or a semiconductor medium. The semiconductor medium can be a solid-state drive, or it can be a random access memory, a flash memory, a read-only memory, an erasable programmable read-only memory, an electrically erasable programmable read-only memory, a register, or any other suitable form of storage medium.

[0055] This application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of this application. Each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks. These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing devices to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device that implements the functions in Figure 1One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable device provide for implementing the process Figure 1 One or more processes and / or boxes Figure 1 The steps of the functions specified in one or more boxes.

[0056] In the above embodiments, the descriptions of the respective embodiments have their own focuses. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments. Obviously, those skilled in the art can make various changes and modifications to the embodiments of the present application without departing from the spirit and scope of the embodiments of the present application. The steps in the method embodiments of the present application can be adjusted, combined or deleted according to actual needs; the modules in the system embodiments of the present application can be divided, combined or deleted according to actual needs. If these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application also intends to include these changes and variations.

Claims

1. A method for converting functional coverage code, characterized in that, The conversion method includes: Obtain a first verification plan, where the first verification plan records a level scenario, a command scenario, and sub-functions. The level scenario indicates whether two adjacent data operations access the same level or different levels. The command scenario indicates whether two adjacent data operations are write-then-write, write-then-read, read-then-read, or read-then-write. The level scenario and the command scenario are used to generate multiple verification scenario combinations, and the sub-functions indicate the function points associated with each of the multiple verification scenario combinations; Parse the first verification plan to obtain multiple cover groups corresponding to the multiple verification scenario combinations. Each cover group in the multiple cover groups includes cover points for providing function coverage of the function points associated with the verification scenario combination corresponding to the cover group. Each cover group in the multiple cover groups further includes cross-cover points for providing cross-coverage of the cover points included in the cover group. Each cover group in the multiple cover groups further includes skip coding for indicating the cross-cover points to be skipped among the cross-cover points included in the cover group; Generate the function coverage rate statistical results of the multiple cover groups. Then, based on the function coverage rate statistical results of the multiple cover groups, generate simulation test cases, which are used to supplement the function coverage rate code associated with the first verification plan. Generating the function coverage rate statistical results of the multiple cover groups includes: counting whether the cover points included in each cover group in the multiple cover groups are covered, counting whether the cross-cover points included in each cover group in the multiple cover groups are indicated to be skipped by the skip coding included in the cover group, and counting whether the non-skipped cross-cover points included in each cover group in the multiple cover groups are covered.

2. The conversion method according to claim 1, characterized in that, The function coverage rate code associated with the first verification plan is used to converge the function coverage rate based on the first verification plan during the function verification phase.

3. The conversion method according to claim 1, characterized in that, Generating the simulation test cases based on the function coverage rate statistical results of the multiple cover groups includes: generating the simulation test cases for targeted function verification based on the uncovered cover points and uncovered cross-cover points included in each cover group in the multiple cover groups.

4. The conversion method according to claim 3, characterized in that, The conversion method further includes: After generating the function coverage rate statistical results of the multiple cover groups and before generating the simulation test cases, determine the reduction options for each of the uncovered cover points included in each cover group in the multiple cover groups, so as to determine the number of the simulation test cases, where the reduction options indicate whether to construct a separate simulation test case for the corresponding cover point.

5. The conversion method according to claim 1, characterized in that, The function points associated with each of the multiple verification scenario combinations indicated by the sub-functions are user-defined.

6. The conversion method according to claim 1, wherein The first verification plan further records the coverage range and variable type of each function point indicated by the sub-function. Each cover group in the multiple cover groups further includes special attention coding for indicating the cross-cover points to be specially concerned among the cross-cover points included in the cover group.

7. The conversion method according to claim 6, wherein The first verification plan also records the designated scenario skip identifier, designated scenario additional coverage, designated scenario additional cross-functional points, and designated scenario additional special attention functional points of each functional point indicated by the sub-function. Among them, the designated scenario skip identifier is used to indicate whether to skip the functional coverage of the corresponding functional point when generating the functional coverage convergence of the designated scenario. The designated scenario additional coverage is used to indicate the additional coverage when generating the functional coverage convergence of the designated scenario. The designated scenario additional cross-functional points are used to indicate the additional cross-coverage of the coverage points corresponding to the corresponding functional points when generating the functional coverage convergence of the designated scenario. The designated scenario additional special attention functional points are used to indicate the cross-coverage points that require additional special attention when generating the functional coverage convergence of the designated scenario.

8. The conversion method according to claim 7, characterized in that The designated scenario includes a DDR physical layer interface and a dynamic random access memory.

9. The conversion method according to claim 1, wherein The first verification plan is used for the chip design project of a double data rate synchronous dynamic random access memory.

10. The conversion method according to claim 1, characterized in that, The hierarchical scenarios and the command scenarios are combined in a Cartesian product manner to obtain the multiple verification scenario combinations.

11. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the method according to any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions. When the computer instructions run on the computer device, the computer device is caused to execute the method according to any one of claims 1 to 10.

Images