Functional coverage rate code conversion method, computer equipment and medium

Abstract

The invention relates to the technical field of computers and provides a functional coverage rate code conversion method, computer equipment and a medium. The conversion method comprises the steps of obtaining a first verification plan; analyzing the first verification plan to obtain a plurality of coverage groups corresponding to the plurality of verification scene combinations; the method comprises the steps of generating a plurality of coverage groups, generating a function coverage rate statistical result of the plurality of coverage groups, and then generating a simulation case based on the function coverage rate statistical result of the plurality of coverage groups, the simulation case being used for supplementing a function coverage rate code associated with a first verification plan. In this way, automatic conversion of the function coverage rate codes and rapid convergence of the function coverage rate are achieved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, 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 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 the intervention of manual work, 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 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 coverage groups corresponding to the multiple verification scenario combinations, where each coverage group in the multiple coverage groups includes coverage points for providing functional coverage of the function points associated with the verification scenario combination corresponding to the coverage group, each coverage group in the multiple coverage groups further includes cross-coverage points for providing cross-coverage of the coverage points included in the coverage group, and each coverage group in the multiple coverage groups further includes skip coding for indicating the cross-coverage points to be skipped among the cross-coverage points included in the coverage group; generating a functional coverage statistical result of the multiple coverage groups, and then, based on the functional coverage statistical result of the multiple 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.

[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 coverage groups includes: counting whether the coverage points included in each coverage group in the multiple coverage groups are covered, counting whether the cross-coverage points included in each coverage group in the multiple coverage groups are indicated to be skipped by the skip coding included in the coverage group, and counting whether the unskipped cross-coverage points included in each coverage group in the multiple coverage 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 coverage 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 coverage group in the multiple coverage groups.

[0008] In a possible implementation manner of the first aspect of the present application, the conversion method further includes: after generating the functional coverage rate statistical 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 manner of the first aspect of the present application, the function points associated with the multiple verification scenario combinations indicated by the sub-functions are user-defined.

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

[0011] In a possible implementation manner of the first aspect of the present application, the first verification plan further 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-functions, 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 rate convergence of the designated scenario, the designated scenario additional coverage range is used to indicate the additional coverage range when generating the functional coverage rate 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 rate convergence of the designated scenario, and the designated scenario additional special attention function point is used to indicate the cross-coverage points that need to be specially concerned additionally when generating the functional coverage rate convergence of the designated scenario.

[0012] In a possible implementation manner 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 manner 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 manner 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] In a 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, the method according to any implementation manner of any of the above aspects is implemented.

[0016] In a third aspect, an embodiment of the present application further provides a computer-readable storage medium storing 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] In a 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 realized. Multiple verification scenario combinations cover various possible functional characteristics that may be encountered in the functional verification stage. These combinations are sufficient to meet the requirements of basic or advanced functions to be verified in the functional verification stage. 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, by optimizing the 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. In this way, 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 100% are realized. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order 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 It is a schematic diagram of a chip development project provided by an embodiment of this application; Figure 2 It is a schematic flowchart of a method for converting functional coverage code provided by an embodiment of this application; Figure 3 It is a schematic diagram of the structure of a computing device provided by an embodiment of this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0021] The embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

[0022] 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 an order.

[0023] 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 agreement 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 performing specific circuit design for each module according to the solution determined in the system design 104, 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 formulated 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 EDA tools, 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 mixed-signal circuit design, or it can be divided into sub-nodes of different functional modules according to different functional definitions, such as sub-nodes of the energy function module and sub-nodes of the 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.

[0024] 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, assume that the chip development project 100 is for developing an artificial intelligence chip or a digital signal processing chip, then the parameters to be tested 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 what aspects should be focused on and what potential functions need to be understood when performing functional verification during the functional verification phase 130. For example, assume that the chip development project 100 is for a graphics processing unit chip, and 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, assume that 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 the photo 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 taking, and simulating storing the photo and performing algorithmic processing on the photo, etc. It can be seen that with the increase in chip design complexity and the increasing richness of terminal product functions, 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 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.The following will combine with specific embodiments of the present application to elaborate in detail on a method for converting functional coverage code, a computer device, and a medium provided by the embodiments of the present application. How to achieve the automatic conversion of functional coverage code and the rapid convergence of functional coverage to one hundred percent through an optimized method for converting functional coverage code and a multi-level model constructed based on a verification plan.

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

[0026] Step S201: 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.

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

[0028] Step S205: Generate the functional coverage statistical results of the multiple coverage groups, and then, based on the functional coverage statistical 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.

[0029] Refer to Figure 2 , in step S201, 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. 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 designed, 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.

[0030] Continue to refer to Figure 2, the first verification plan records the level scenario, command scenario, and sub-functions. The level 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 level scenario is the same level, which means two adjacent data operations on the same object; if two adjacent data operations access different levels, the level 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 level 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 level 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 shooting 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 level scenario and read / write switching in the command scenario 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 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 a verification scenario combination where the rank scenario is a single rank and the command scenario is write then write again, the functional points that need to be concerned about may 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.

[0031] 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 further includes cross coverpoints for providing cross coverage of the coverpoints included in the covergroup, and each of the multiple covergroups further includes ignore bins 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 and 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 achieved, which can ensure that key issues such as data inconsistency and process conflicts are specifically 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. In this way, the conversion of functional coverage from the first verification plan to multiple covergroups is achieved. 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 further includes cross coverpoints for providing cross coverage of the coverpoints included in the covergroup, and each of the multiple covergroups further includes ignore bins 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 no cross coverage with any other coverpoint is required, and other digital numbers are used for differentiation. The cross coverpoints with the same digital number are grouped together. 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 through variable names, or can separate different function points to be ignored by indicating a range of content, 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 a 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 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 functions to be verified are the image rendering function when running large programs such as games and the media functions 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 amount 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 or solo games, so the demand for network connection transmission functions 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 media functions such as the animation generation function point, corresponding cross-coverage points and skip encodings can also be set, so as to provide cross-coverage of relevant function points and selectively skip or ignore certain function points, thereby improving the convergence efficiency.

[0032] 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, by optimizing the 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 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 during 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 during 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, by optimizing the data format of the first verification plan, a multi-level model is constructed based on the verification plan, which is beneficial 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. In this way, 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. In this way, 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 can be displayed as "Excluded" to indicate that the functional point is excluded when generating the coverage statistics report during the convergence phase, while for the covered functional points, the status can be set to "Covered bins", and for the uncovered functional points, the status can be set to "Uncovered bins". In this way, 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.

[0033] 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 the 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, where "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", where the symbol "Special symbols such as *" indicates that any value in this function point is not covered. Additionally, "STATUS" shows "Excluded", which means this function point is excluded when generating coverage. Based on the above information, scripts can be used to extract the coverage of relevant functional coverage.

[0034] 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 customized 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 realized. Multiple combinations of verification scenarios cover various possible functional characteristics that may be encountered in 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 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 specifically addressed when configuring the first verification plan and performing 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 the 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 100% are realized.

[0035] See 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 customized 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 realizes the automated conversion of functional coverage code and the rapid convergence of functional coverage to 100%.

[0036] 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 coding 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 coding. 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. Moreover, by counting whether the coverage points are covered and whether the cross-coverage points are covered, richer 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.

[0037] 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 targeted 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, the automated convergence from the first verification plan to functional coverage can be achieved. 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 targeted test case list for generating simulation test cases for targeted functional verification, which helps to achieve complete functional coverage.

[0038] In some embodiments, the transformation method further includes: after generating the functional coverage statistics of the multiple coverage groups and before generating the simulation cases, determining, for each of the multiple coverage groups, the respective reduction options for the uncovered coverage points included therein, 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. 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 for 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 constructing 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 for the function points covered by this simulation case. In this way, when generating subsequent simulation cases, the function points with the attribute of the reduction option being 0 can be directly ignored, achieving the purpose of reduction and being beneficial to improving the overall efficiency.

[0039] In a possible implementation manner, the function points associated with the various 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.

[0040] In a possible implementation, 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 that need special attention among the cross-coverage points included in the 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.

[0041] 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 the 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 can 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 a specified scenario skip identifier, a specified scenario additional coverage range, a specified scenario additional cross-functional point, and a specified scenario additional special attention functional point, more flexible customization options can be provided when the functional coverage of the specified scenario converges.

[0042] 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, although both the MC and the PHY are parts of the DDR memory interface, they generally use different interconnection standards. Therefore, 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 flexibly make adjustments for a specified project.

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

[0044] In a possible implementation, the hierarchical scenarios and the command scenarios are combined in a Cartesian product manner 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 implemented, 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 shooting 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 in the order of 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.

[0045] 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, and 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, and the processor 310 can specifically be used for processing functions necessary to implement the functions of these devices and components.

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

[0047] The processor 310 may have various specific implementation forms. For example, the processor 310 may 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. The embodiments of the present application do not make specific limitations. The processor 310 may also be a single-core processor or a multi-core processor. The processor 310 may be a combination of a CPU and a hardware chip. The above hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above PLD may 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 may also be implemented by a logic device with built-in processing logic alone, such as an FPGA or a digital signal processor (DSP), etc. The communication interface 320 may be a wired interface or a wireless interface for communicating with other modules or devices. The wired interface may be an Ethernet interface, a local interconnect network (LIN), etc. The wireless interface may be a cellular network interface or a wireless local area network interface, etc.

[0048] The memory 330 can be a non-volatile memory, for example, a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), or a 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.

[0049] The bus 340 can be a Peripheral Component Interconnect Express (PCIe) bus, or an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL), a 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.

[0050] The methods and devices provided in the embodiments of the present application are based on the same inventive concept. Since the principles for the methods and devices to solve 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 further provide a system, which includes a plurality of 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.

[0051] The embodiments of the present application further 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.

[0052] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. The present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. The embodiments of the present 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. The present 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 the present 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. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (such as coaxial cable, fiber optic, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) means. 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, 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.

[0053] The present application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present 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 means 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 device 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 process or multiple processes and / or boxes Figure 1 The functions specified in one box or multiple 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 process or multiple processes and / or boxes Figure 1 The steps of the functions specified in one box or multiple boxes.

[0054] In the above embodiments, the descriptions of the various embodiments have their own emphases. 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 modifications.

Claims

1. A method for converting functional coverage code, characterized in that: The transformation method comprises: Obtaining a first verification plan, wherein the first verification plan records a level scenario, a command scenario, and a sub-function, wherein the level scenario indicates whether two adjacent data operations are accesses to the same level or to different levels, and the command scenario indicates whether two adjacent data operations are write first and then write, write first and then read, read first and then read, or read first and then write, wherein the level scenario and the command scenario are used to generate a plurality of verification scenario combinations, and the sub-function indicates the functional points associated with each of the plurality of verification scenario combinations; Parsing the first verification plan to obtain a plurality of coverage groups corresponding to the plurality of verification scenario combinations, wherein each of the plurality of coverage groups includes coverage points for providing functional coverage of functional points associated with the verification scenario combination corresponding to the coverage group, each of the plurality of coverage groups also includes cross coverage points for providing respective cross coverage of the coverage points included in the coverage group, and each of the plurality of coverage groups also includes skip codes for indicating cross coverage points to be skipped among the cross coverage points included in the coverage group; Generate functional coverage statistics of the multiple coverage groups, and then generate simulation cases based on the functional coverage statistics of the multiple coverage groups, wherein the simulation cases are used to supplement the functional coverage codes associated with the first verification plan.

2. The conversion method according to claim 1, characterized in that 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.

3. The conversion method according to claim 1, characterized in that Generate functional coverage statistics of the multiple coverage groups, including: 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 skipped by the skip coding instructions included in the coverage group, and counting whether the cross coverage points included in each of the multiple coverage groups that are not skipped are covered.

4. The conversion method according to claim 3, characterized in that The simulation case is generated based on the functional coverage statistics of the multiple cover groups, including: based on the uncovered cover points and uncovered cross-cover points included in each of the multiple cover groups, the simulation case is generated to perform directional functional verification.

5. The conversion method according to claim 4, characterized in that The conversion method further comprises: After generating the functional coverage statistics of the multiple cover groups and before generating the simulation use cases, determine the respective simplification options of the uncovered cover points included in each of the multiple cover groups, thereby determining the number of simulation use cases, wherein the simplification options indicate whether to construct separate simulation use cases for corresponding cover points.

6. 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 customized by the user.

7. The conversion method according to claim 1, characterized in that The first verification plan also records the coverage range and variable type of each function point indicated by the sub-function, and each of the multiple cover groups also includes a special attention code for indicating the cross-cover points that need special attention among the cross-cover points included in the cover group.

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

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

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

11. The conversion method according to claim 1, characterized in that: The level scenario and the command scenario are combined using a Cartesian product method to obtain the plurality of verification scenario combinations.

12. A computer device, characterized in that: The computer device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 11 when executing the computer program.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, which, when executed on a computer device, cause the computer device to perform the method according to any one of claims 1 to 11.

Images