Inspector setting method, report generation method, device and related equipment

Abstract

Embodiments of the present application provide an inspector setting method, a report generation method, a device and related equipment, wherein the inspector setting method comprises: determining a target inspector in a verification environment; defining an inspector parameter in a global file of the verification environment, the inspector parameter comprising a classification parameter, the classification parameter comprising at least one classification field; and setting the classification parameter for the target inspector based on the inspector parameter defined in the global file. Further, the report generation method provided by the embodiments of the present application can classify the inspector report of the target inspector in at least one dimension according to the classification parameter set for the target inspector, and obtain report content in at least one dimension. The embodiments of the present application can classify the inspector report of the inspector in at least one dimension based on the classification parameter set for the inspector, and obtain report content in different dimensions, so that the report content of the inspector can be efficiently checked with focus in different dimensions, and the checking quality is improved.

Description

Technical Field

[0001] This application relates to the field of chip design technology, specifically to a checker setting method, report generation method, apparatus, and related equipment. Background Technology

[0002] Chip design (or simply design) refers to the design of integrated circuits such as ASICs (Application Specific Integrated Circuits) and SOCs (System-On-Chip). To verify whether a design meets expectations, a verification environment can be built and used to verify the design; in this process, checkers in the verification environment can verify from a functional perspective whether the design works as expected.

[0003] Due to the complexity of the design and the diversity of simulation verification scenarios, some checkers may not be suitable for specific simulation verification scenarios. Therefore, in certain simulation verification scenarios, some checkers need to be disabled in the verification environment. Whether the checkers are disabled correctly and reasonably is crucial to the verification quality of the design. Therefore, it is necessary to check the closure information of the checkers in the verification environment. Against this background, how to provide a method for setting up checkers so that the closure information in the checker report can be checked efficiently and with focus when generating the checker report, thereby improving the inspection quality, has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, embodiments of this application provide an inspector setting method, a report generation method, an apparatus, and related equipment. By reconstructing the inspector in the verification environment, classification parameters are set in the inspector, including at least one classification field. Furthermore, when generating an inspector report, the inspector report can be classified in at least one dimension based on the inspector's classification parameters (one classification field in the classification parameters can be used to classify the inspector report in one dimension), thereby obtaining report content in different dimensions. This allows the inspector's report content to be checked efficiently and with focus in different types of dimensions, thereby improving the inspection quality.

[0005] To address the aforementioned problems, the embodiments of this application provide the following technical solutions.

[0006] In a first aspect, embodiments of this application provide an inspector setting method, including:

[0007] Determine the target inspector in the verification environment;

[0008] In addition, inspector parameters are defined in the global file of the verification environment, the inspector parameters including classification parameters, the classification parameters including at least one classification field;

[0009] Based on the inspector parameters defined in the global file, classification parameters are set for the target inspector; the classification parameters of the target inspector are used to classify the inspector report of the target inspector in at least one dimension, wherein a classification field in the classification parameters is used to classify the inspector report of the target inspector in one dimension.

[0010] Secondly, embodiments of this application provide a report generation method, including:

[0011] The design is subjected to regression verification in the verification environment, and an inspector report of the target inspector in the verification environment is generated; the target inspector is set with classification parameters based on the inspector setting method described in the first aspect above.

[0012] The inspector report is classified in at least one dimension according to at least one classification field included in the classification parameters set by the target inspector, so as to obtain report content in at least one dimension; wherein, a classification field is used to classify the inspector report in one dimension.

[0013] Thirdly, embodiments of this application provide an inspection device, comprising:

[0014] The target inspector determination module is used to determine the target inspectors in the verification environment;

[0015] A parameter definition module is used to define inspector parameters in a global file of the verification environment. The inspector parameters include classification parameters, which include at least one classification field.

[0016] The parameter setting module is used to set classification parameters for the target inspector based on the inspector parameters defined in the global file; the classification parameters of the target inspector are used to classify the inspector report of the target inspector in at least one dimension, wherein a classification field in the classification parameters is used to classify the inspector report of the target inspector in one dimension.

[0017] Fourthly, embodiments of this application provide a report generation apparatus, including:

[0018] The regression verification and report generation module is used to perform regression verification on the design in the verification environment and generate a checker report for the target checker in the verification environment; the target checker is set with classification parameters based on the checker setting method described in the first aspect above.

[0019] A classification module is used to classify the inspector report in at least one dimension according to at least one classification field included in the classification parameters set by the target inspector, so as to obtain report content in at least one dimension; wherein, a classification field is used to classify the inspector report in one dimension.

[0020] Fifthly, embodiments of this application provide a computer device, characterized in that it includes at least one memory and at least one processor, the memory storing one or more computer-executable instructions, and the processor invoking the one or more computer-executable instructions to execute the checker setting method as described in the first aspect above, and / or the report generation method as described in the second aspect above.

[0021] In a sixth aspect, embodiments of this application provide a storage medium, characterized in that the storage medium stores one or more computer-executable instructions, which, when executed, implement the checker setting method as described in the first aspect above, and / or the report generation method as described in the second aspect above.

[0022] The inspector setting method provided in this application can determine the target inspector that needs to be reconstructed in the verification environment, and define inspector parameters in the form of classification parameters in the global file of the verification environment, thereby reconstructing the target inspector in the verification environment so that the target inspector in the verification environment can be set with the classification parameters. In an optional implementation, since the global file of the verification environment can be accessed by the inspectors in the verification environment, this application embodiment can set classification parameters for the target inspector based on the inspector parameters defined in the global file of the verification environment when setting parameters for the target inspector in the verification environment (e.g., when passing parameters to the target inspector in the verification environment), so that the parameters of the target inspector carry classification parameters; furthermore, after verifying the design using the verification environment, this application embodiment can classify the inspector report of the target inspector based on the classification parameters set by the target inspector when generating the inspector report of the target inspector in the verification environment, to obtain the report content of the target inspector in at least one dimension, so that the verification personnel can perform focused and efficient inspection of the report content of the target inspector in different types of dimensions through the report content in at least one dimension, thereby improving the inspection quality of the inspector report. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0024] Figure 1A Example diagram for verifying the environment.

[0025] Figure 1B Another example diagram to verify the environment.

[0026] Figure 2 This is an example diagram illustrating the implementation process of the inspector's report generation method.

[0027] Figure 3 A flowchart of the inspector setting method provided in the embodiments of this application.

[0028] Figure 4 Another flowchart of the inspector setting method provided in the embodiments of this application.

[0029] Figure 5 Another example diagram of the verification environment provided for embodiments of this application.

[0030] Figure 6 This is a flowchart illustrating how to set classification parameters for a reused inspector by replacing the inspector format in an embodiment of this application.

[0031] Figure 7A This is a flowchart illustrating the method for processing the invalidity checker according to an embodiment of this application.

[0032] Figure 7B This is a flowchart illustrating the method for setting classification parameters for a new inspector in an embodiment of this application.

[0033] Figure 8A A flowchart of a report generation method provided in an embodiment of this application.

[0034] Figure 8B Example diagram of the processing procedure for the inspector report.

[0035] Figure 9 This is an example diagram illustrating the implementation process from setting up the inspector to generating a report in an embodiment of this application.

[0036] Figure 10A A block diagram of an inspection device provided in an embodiment of this application.

[0037] Figure 10B A block diagram of a report generation apparatus provided in an embodiment of this application.

[0038] Figure 11 A block diagram of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0040] As chip designs, such as SoCs, become increasingly feature-rich and large-scale, the verification environment for chip designs is also becoming more complex. Verification environments, such as UVM (Universal Verification Methodology), can be written in languages ​​like SystemVerilog. In a verification environment, chip designs can be simulated to verify whether they meet design expectations.

[0041] As verification environments become increasingly complex, they can exist at different levels, such as the lowest level IP (intellectual property) verification environment, the middle level subsystem verification environment, and the upper level system-level verification environment, such as the SOC verification environment.

[0042] It should be noted that design modules (such as IP modules) are functional modules in chip design. The underlying IP verification environment can be used to verify at the design module level. A design module can be instantiated and verified in one or more IP verification environments. For example, a relatively simple design module can be instantiated and verified in one IP verification environment, while a more complex design module needs to be instantiated in multiple IP verification environments and verified from different perspectives. In addition, a design module may be instantiated multiple times in an IP verification environment to simulate special verification scenarios. In a multi-level verification environment, the number of IP verification environments may be one or more.

[0043] The intermediate-level subsystem verification environment can be used to verify subsystems formed by instantiating multiple design modules, thereby verifying the collaborative work of multiple design modules; in a multi-level verification environment, the number of subsystem verification environments may be one or more. The system-level verification environment can be used to verify the interconnection and communication of multiple subsystems, where the instantiation of multiple design modules can form a subsystem; in a multi-level verification environment, the number of system-level verification environments is generally one.

[0044] For ease of understanding, let's take the IP authentication environment and subsystem authentication environment as examples. Figure 1A An example diagram of a verification environment is shown as an example, such as... Figure 1AAs shown, there can be multiple IP authentication environments, namely IP authentication environment A0, IP authentication environment A1, IP authentication environment B0, IP authentication environment B1, IP authentication environment C0 and IP authentication environment D0.

[0045] In this process, IP verification environments A0 and A1 instantiate the same design module A once each to verify the design module A from different perspectives. Thus, when the design of design module A is relatively complex, the design quality of design module A can be guaranteed through verification from different perspectives by IP verification environments A0 and A1.

[0046] It should be noted that when a design module is instantiated multiple times in a multi-layered verification environment, the instantiation name of the design module can be different each time. For example, the instantiation name of design module A in IP verification environment A0 is different from the instantiation name in IP verification environment A1.

[0047] When design B (e.g., design module B) needs to simulate the communication scenarios of its own design and the communication scenarios of its own and peer designs, IP verification environment B0 can instantiate design module B once to simulate the communication scenarios of its own design within IP verification environment B0. IP verification environment B1 can instantiate design module B twice at the top level of design B to simulate the communication scenarios of its own and peer designs within IP verification environment B1. It should be noted that the design module can be instantiated at the top level of the verification environment. When the design module is instantiated in different verification environments, the top-level instantiation and design level of the design module differ in different verification environments. For example, the top-level instantiation and design level of design module B are different in IP verification environments B0 and B1.

[0048] For designs of relatively simple modules C and D, IP verification environment C0 can instantiate design module C once for verification; at the same time, IP verification environment D0 can instantiate design module D once for verification.

[0049] Further as Figure 1A As shown, the subsystem verification environment X0 can be used to verify the subsystems formed by instantiating design modules A, B, C, and D. This subsystem can be considered as a design X containing design modules A, B, C, and D. Therefore, the subsystem verification environment X0 can instantiate design modules A, B, C, and D at the top level of design X, and verify the subsystems formed by the instantiated design modules A, B, C, and D to verify the collaborative work between multiple design modules.

[0050] Furthermore, in Figure 1A Based on the example, taking a system-level verification environment as an example, Figure 1BAnother example diagram of the verification environment is shown as an example, such as Figure 1B As shown, the system-level verification environment M0 can be used to verify the interconnection and communication of multiple subsystems. A design containing multiple subsystems can be considered as a design M. Therefore, the system-level verification environment M0 can instantiate multiple designs X at the top level of design M. A design X can instantiate design modules A, B, C, and D at the top level. In other words, when multiple design modules form a subsystem, and multiple subsystems constitute a system, the system-level verification environment can verify the interconnection and communication of multiple subsystems at the system level.

[0051] It should be noted that, for actual chip design, there are many design modules. Therefore, the instantiation of design modules in each layer of verification environment needs to be determined based on the specific design requirements of the chip design. Figure 1A and Figure 1B The instantiation of design modules A, B, C, and D in the IP verification environment, subsystem verification environment, and system-level verification environment is listed for the purpose of illustrative purposes only and should not be regarded as the actual instantiation of the design modules.

[0052] When validating a design, checkers can be generated within the validation environment. These checkers can then functionally verify whether the design functions as expected. For example, for design modules instantiated in various validation environments (e.g., design modules instantiated in various IP validation environments, design modules instantiated in various subsystem validation environments, and design modules instantiated in a system-level validation environment), each validation environment can generate checkers to functionally verify the instantiated design modules. For each validation environment, there may be a large number of checkers, which may be categorized into different types. In one example, the checker types in a validation environment might include:

[0053] CDC (Clock Domain Crossing) is an important part of chip design verification because, with the increasing scale of chip design, there are more and more clocks in the chip, and synchronization circuits across clock domains are very common. Therefore, chip design and verification must ensure the correctness of CDC, and corresponding CDC synchronizer checking has become an important part of chip design verification.

[0054] Assertion-based verification, or simply assertion, is used to describe the properties that a chip design must have correctly for certain interfaces, timings, or special functions. The main purpose of property verification (such as assertion verification) is to ensure that the chip design is consistent with the design specifications.

[0055] Force (force assignment), including force / release / deposit, is collectively referred to as force; force exists in the verification environment to create special stimuli, such as to simulate power connection, to accelerate initialization in simulation, to simulate metastable propagation, for switch checkers, and some temporary strain methods, etc. Using force can quickly achieve the verification goal.

[0056] Parameter checking involves checking the key parameters in the chip design manual.

[0057] Data inspection involves monitoring the data output from the design and comparing it with the results from the reference model.

[0058] It should be noted that the above examples only use five types of checkers for illustration. The types of checkers in the verification environment will vary as the complexity of the design functions changes. This application does not limit the types of checkers in the verification environment.

[0059] Due to the complexity of the design and the diversity of simulation verification scenarios, there are numerous checker entries and a large number of verification test cases in the verification environment. At the same time, some checkers in the verification environment may not be suitable for specific simulation verification scenarios and need to be turned off. Therefore, in specific simulation verification scenarios, some checkers need to be turned off in the verification environment.

[0060] Whether the checkers are closed correctly and reasonably is crucial to the quality of design verification. Therefore, after verifying the design using the verification environment, it is necessary to check the closing information of the checkers in the verification environment. For example, after verifying the design using the verification environment, it is necessary to check and confirm whether the checkers in the verification environment are closed as expected, whether there are any incorrect closures, omissions, etc.

[0061] To verify the checker's closure information, a checker report containing this information is needed; this report can be generated during the signoff process. For example, after verifying the design using a verification environment, a signoff can be performed, outputting the checker's closure information from the verification environment in the signoff checker report. This allows for verification of the checker's closure information based on the checker report, thus determining whether the checker in the verification environment has been closed as expected.

[0062] Signoff refers to the process of reviewing and verifying design data before delivery to a chip manufacturer to ensure the design meets delivery standards. These checks and verifications are collectively called signoff. In other words, signoff is performed on verification environment items, including checker shutdown information. Therefore, signoff can output a checker report containing checker shutdown information. A checker report can be a type of signoff report.

[0063] To facilitate further understanding, let's take a chip design R&D project (hereinafter referred to as a project) as an example. Each project has a corresponding chip design (e.g., chip design code). The chip design of a project needs to be verified through a verification environment to verify whether the chip design conforms to the product manual. It should be noted that after verifying that the chip design of a project conforms to the product manual, the chip design can be used for chip manufacturing and thus enter the market for use. However, the verification environment, checkers, and other components used to verify the chip design are not put into production and enter the market.

[0064] Based on this, the verification environment can verify the chip design of the project through iterative regression verification. After verifying that the chip design meets the project's pass rate and coverage requirements, the verification environment can be signed off. During the signoff process, a checker report containing checker shutdown information can be output. After confirming that all check items of the signoff have passed the checks (including that the checker shutdown information in the checker report has no incorrect shutdowns or omissions), the project can be completed. Then, the design can be delivered to the chip manufacturer for production.

[0065] It should be noted that, as an example, during the signoff process, the signoff based on the checker's closing information mainly falls into two categories:

[0066] Database-based checkers are designed to intentionally disable checkers for specific simulation verification scenarios to ensure that verification test cases pass. The checker's disabling information is not output in the simulation log.

[0067] The signoff of the checker based on the simulation results will be output in the simulation log. In other words, the simulation log records the checker's shutdown information, such as the UVM_WARNING alarm.

[0068] Recording checker shutdown information in the simulation log allows for review later in the project, confirming whether checkers were incorrectly shut down and preventing oversights. For example, verification environment warnings such as FATAL (FATAL indicates a serious error, for which the simulator will stop by default) or ERROR may be downgraded to Warnings by the user in specific simulation verification scenarios. This is a dynamic downgrade in the verification environment, and the corresponding checker shutdown information can be output in the simulation log.

[0069] As can be seen from the above introduction, after the design verification is completed in the verification environment, a checker report containing checker closure information can be output during the signoff process. Based on this checker report, it is possible to check and confirm whether the checkers in the verification environment have been closed as expected, and thus, to infer and confirm the verification quality of the design during the verification phase. Therefore, researching checker report generation schemes is of great significance.

[0070] As an optional implementation, Figure 2 An exemplary diagram illustrates the implementation process of an inspector's report generation method, as shown below. Figure 2 As shown, the process may include:

[0071] With each validation environment labeled (different validation environments can have different labels), regression validation of the design is performed in each validation environment.

[0072] The script in the automatic reporting layer analyzes the regression verification results of each verification environment based on the signoff checks (including the checker's closing information in the verification environment) and generates checker reports for each verification environment.

[0073] The cross-label and cross-verification environment convergence layer performs cross-label and cross-verification environment back-annotation processing on the inspector reports of the inspectors in each verification environment to obtain cross-label and cross-verification environment back-annotation reports.

[0074] The automatic aggregation layer statistically summarizes the back-annotation reports across tags and verification environments, generating a total index report;

[0075] Verifiers analyze the master index report and fill in the forms to produce the final checker report;

[0076] The verification environment is modified and the above steps are repeated continuously to gradually converge the final checker report.

[0077] based on Figure 2As shown, although verification personnel can confirm whether the checker in the verification environment has performed the expected shutdown operation, whether there has been any erroneous shutdown, or omission of shutdown, through the checker report after the design simulation verification is completed; however, Figure 2 The inspector report provided by the method shown has low inspection quality. For example, validators need to identify different dimensions of the report content from the inspector report and then conduct manual review. This makes it impossible for validators to conduct focused and efficient inspections of the inspector report content based on the directly generated inspector report.

[0078] To address the aforementioned issues, this application provides an inspector setting method that reconstructs the inspector in the verification environment, thereby setting classification parameters in the inspector. These classification parameters include at least one classification field for classifying inspector reports. Simultaneously, based on the report generation scheme provided in this application, when generating the inspector report, this application can classify the inspector report of the inspector in at least one dimension based on at least one classification field in the inspector's classification parameters, resulting in report content of different dimensions. This allows the inspector's report content to be efficiently and effectively checked across different dimensions, thereby improving the inspection quality of the inspector report.

[0079] Based on the above ideas, the checker setting scheme provided in the embodiments of this application will be introduced below. The checker setting scheme can be executed before the design is verified. For example, before the design is verified, the checker in the verification environment is reconstructed so that the checker in the verification environment is set with classification parameters.

[0080] As an optional implementation Figure 3 An exemplary flowchart of an optional checker setup method provided in an embodiment of this application is shown. This method can be implemented by a simulation verification tool for simulating and verifying chip designs. The simulation verification tool can be a computer program running on a computer device; for example, a simulation verification program can run on the computer device, which can perform simulation verification on the chip design. Optionally, the description of the chip design (e.g., a hardware description language description) can be compiled to form the simulation verification program. Before verifying the design, the simulation verification tool can... Figure 3 The method shown refactors the inspector in the validation environment so that the inspector in the validation environment is set with classification parameters. (Refer to...) Figure 3 The method process may include the following steps.

[0081] In step S310, the target inspector in the verification environment is determined.

[0082] The target inspector can be viewed as an inspector in the verification environment that needs to be refactored, i.e., an inspector in the verification environment that needs to have its classification parameters set. In some embodiments, the target inspector in the verification environment that needs to have its classification parameters set can be a reusable inspector that can be reused by the project in the verification environment relative to other projects, or a newly added inspector that is added relative to other projects.

[0083] As an optional implementation, for inherited projects, most inspectors are reusable. The target inspector determined in the embodiments of this application can be a reusable inspector that can be reused between projects. For example, for old and new projects in chip design, if the new project inherits from the old project, the embodiments of this application can reuse the inspector of the old project in the new project, and determine the reusable inspector reused in the new project as the target inspector that needs to be set with classification parameters in the verification environment of the new project.

[0084] In other alternative implementations, the target inspector determined in the embodiments of this application can also be a new inspector in the project. For example, for old and new chip design projects, the new inspector added to the new project relative to the old project can be determined as the target inspector for which classification parameters need to be set in the verification environment of the new project.

[0085] It should be noted that the reuse checker and the new checker for the project are only optional forms of the target checker that need to be set with classification parameters in the project's verification environment. For the project's verification environment, the embodiments of this application can define the form of the target checker according to the requirements, and are not limited to the reuse checker and the new checker in the above examples.

[0086] In step S311, inspector parameters are defined in the global file of the verification environment. The inspector parameters include classification parameters, which include at least one classification field.

[0087] The global file of the verification environment is a file that can be accessed by the entire verification environment. Defining inspector parameters in the global file of the verification environment allows all inspectors in the verification environment to access the inspector parameters defined in the global file, thus providing a basis for subsequent reconstruction of the target inspector in the verification environment (i.e., setting classification parameters for the target inspector in the verification environment).

[0088] In this embodiment of the application, the inspector parameters defined in the global file of the verification environment may include classification parameters. The classification parameters may include at least one classification field (one or more classification fields). A classification field can be used to classify the inspector report in one dimension.

[0089] In some embodiments, this application embodiment may select one or more classification fields based on keywords that can classify the inspector report in different dimensions, and set the selected classification fields in the classification parameters, thereby defining the classification parameters as inspector parameters in the global file of the verification environment (for example, adding inspector parameters in the form of classification parameters to the global file of the verification environment).

[0090] As an optional implementation, the classification field can be one or more keywords used to determine the affiliation of the inspector. For example, regarding the design module to which the inspector belongs, the verification environment to which the design module belongs, and the project to which the verification environment belongs, this embodiment can set at least one of the following classification fields: Project ID, Team ID, and Function ID, to determine the affiliation of the inspector through the at least one classification field. The Project ID can indicate the project corresponding to the verification environment in which the inspector is located; the Team ID can indicate the verification environment to which the inspector belongs; and the Function ID can indicate the design function of the project and / or the verification environment. It should be noted that the classification fields in the classification parameters can be expanded according to the needs of the verification personnel and are not limited to the forms listed above. For example, this embodiment can further expand the classification parameters to include a Sub Function ID classification field. The Sub Function ID can be a detailed description of the design function to refine the affiliation of the inspector.

[0091] In some embodiments, the classification parameter can be an enumeration type (proj_t), including classification fields such as Project ID, Environment ID, and Function ID used to determine the affiliation of the inspector, thereby adding the above-mentioned enumeration type of inspector parameter to the global file of the verification environment to realize the definition of inspector parameters in the global file of the verification environment.

[0092] In step S312, classification parameters are set for the target inspector based on the inspector parameters defined in the global file; the classification parameters of the target inspector are used to classify the inspector report of the target inspector in at least one dimension, wherein a classification field in the classification parameters is used to classify the inspector report of the target inspector in one dimension.

[0093] After determining the target inspector to be reconstructed in the verification environment and defining inspector parameters in the form of classification parameters in the global file of the verification environment, this embodiment of the application can reconstruct the target inspector in the verification environment, thereby setting the classification parameters for the target inspector in the verification environment. In this embodiment of the application, since the global file of the verification environment can be accessed by the inspector in the verification environment, this embodiment of the application can set classification parameters for the target inspector based on the inspector parameters defined in the global file of the verification environment when setting parameters for the target inspector in the verification environment (e.g., when passing parameters to the target inspector in the verification environment), so that the parameters of the target inspector carry classification parameters; then, after verifying the design using the verification environment, this embodiment of the application can generate an inspector report for the target inspector in the verification environment based on the signoff process, and classify the inspector report of the target inspector based on the classification parameters set for the target inspector, to obtain the report content of the target inspector in at least one dimension, so that the verification personnel can perform focused and efficient inspection of the report content of the target inspector in different types of dimensions through the report content in at least one dimension, thereby improving the inspection quality of the inspector report.

[0094] In other words, classification parameters are set for the target inspector, and the classification parameters may include at least one classification field. A classification field can be used to classify the inspector report of the target inspector in one dimension. Thus, after the design is verified, the embodiments of this application can generate an inspector report of the target inspector in the verification environment (e.g., an automatic reporting layer generates an inspector report of the target inspector in the verification environment), and classify the report content of the inspector report based on at least one classification field in the classification parameters of the target inspector to obtain report content of at least one dimension. This allows verification personnel to conduct focused and efficient checks on the closure information in the inspector report of the target inspector in different types of dimensions through the report content of at least one dimension, thereby improving the inspection quality of the inspector report.

[0095] It can be seen that, compared to Figure 2 The implementation shown in this application can be achieved through... Figure 3 The inspector setup method shown allows you to set classification parameters for the inspector. This enables the inspector report to be categorized based on the classification field in the classification parameters when it is generated. This results in different dimensions of the inspector report content, which helps verification personnel to conduct focused and efficient checks on the inspector report content, thereby improving the inspection quality of the inspector report.

[0096] In some embodiments, based on project inheritance, when generating checkers for a project's verification environment, checkers are mainly divided into reuse checkers and difference checkers. A reuse checker can be considered as a checker from an old project that can be reused in a new project, i.e., a checker from an old project that can be reused in the verification environment of a new project. Difference checks can include, for example, new checkers added to the new project compared to the old project, and invalid checkers from the old project that are no longer applicable to the new project. For example, for old and new projects in chip design, if the new project inherits from the old project, when generating checkers for the new project's verification environment, the main focus is on determining reuse checkers from the old project that can be reused in the new project, new checkers added to the new project compared to the old project, and invalid checkers from the old project that are no longer applicable to the new project. The checker setting method provided in this application embodiment can determine the target checkers for which classification parameters need to be set for the project's verification environment, and these target checkers can be reuse checkers in the new project's verification environment, as well as new checkers in the new project's verification environment; while for invalid checkers, this application embodiment can set invalid checkers to no longer be used in the new project's verification environment.

[0097] Based on this, the inspector setting method provided in the embodiments of this application will be further described below from the perspective of setting classification parameters for the reuse inspector. As an optional implementation, Figure 4 An exemplary flowchart of another optional inspector setting method provided in an embodiment of this application is shown, with reference to Figure 4 The method process may include the following steps.

[0098] In step S410, the type of multiplexed inspector in the verification environment is determined.

[0099] In some embodiments, this application can determine the type of reuse checker reused in the verification environment of a new project, specifically for the verification environment of a new project. Due to the inheritance nature of chip design R&D projects (hereinafter referred to as "projects"), most checkers used in the verification environment of an old project can be reused in the verification environment of a new project. This application can reuse the reuse checkers of an old project in the verification environment of a new project as an optional form of the target checker in the verification environment of the new project. To determine the reuse checkers in the verification environment, as an optional implementation, this application can determine the reuse checkers between the old and new projects by comparing the functional manuals of the old and new projects after the old project completes its signoff.

[0100] As an optional implementation, the reuse inspector in the verification environment can have the following types:

[0101] Module-based checkers, such as IP checkers generated within the design module of a verification environment, can be reused in multiple verification environments. IP checkers can be considered as module-based checkers.

[0102] Class-based checkers, such as UVC (Universal Verification Methodology Component) checkers, can be low-level verification components used to build a verification environment. IP UVC checkers generated within a design module can be reused in the verification environment of a subsystem (system-level verification environments such as SOCs mainly focus on the architecture and pathways of chip design, rather than the details inside the IP, so IP UVC checkers are generally not reused in system-level verification environments).

[0103] To facilitate understanding of the architecture of the verification environment with inspectors, Figure 5 Another example diagram of the verification environment provided in the embodiments of this application is shown, such as... Figure 5 As shown, the IP verification environment A0 has an initialization checker a0 generated at its top level, and the IP verification environment A0 instantiates a design module A, which in turn instantiates an IP checker a. The initialization checker a0 can be used to enable and control the checkers in the IP verification environment A0, and the IP checker a instantiated inside the design module A can be used to verify the design module A.

[0104] The top-level generation of IP verification environment A1 includes an initialization checker a1, and IP verification environment A1 instantiates a design module A, which in turn instantiates an IP checker a. The initialization checker a1 can be used to enable and control the checkers in IP verification environment A1, and the IP checker a instantiated inside design module A can be used to verify design module A.

[0105] The top-level generation of the IP verification environment B0 includes an initialization checker b0, and the IP verification environment B0 instantiates a design module B, which in turn instantiates an IP checker b. The initialization checker b0 can be used to enable and control the checkers in the IP verification environment B0, and the IP checker b instantiated inside the design module B can be used to verify the design module B.

[0106] The top-level generation of IP verification environment B1 includes an initialization checker b1, and IP verification environment B1 instantiates two design modules B, each of which instantiates an IP checker b. The initialization checker b1 can be used to enable and control the checkers in IP verification environment B1, and the IP checkers b instantiated within each design module B can be used to verify the design module B separately.

[0107] The top-level generation of the IP verification environment C0 includes an initialization checker c0, and the IP verification environment C0 instantiates a design module C, which in turn instantiates an IP checker c. The initialization checker c0 can be used to enable and control the checkers in the IP verification environment C0, and the IP checker c instantiated inside the design module C can be used to verify the design module C.

[0108] The top-level generation of the IP verification environment D0 includes an initialization checker d0, and the IP verification environment D0 instantiates a design module D, which in turn instantiates an IP checker d. The initialization checker d0 can be used to enable and control the checkers in the IP verification environment D0, and the IP checker d instantiated inside the design module D can be used to verify the design module D.

[0109] Further as Figure 5 As shown, the top-level generation of the subsystem verification environment X0 is an initial checker x0, and the subsystem verification environment X0 instantiates subsystems formed by design modules A, B, C and D. The design modules A, B, C and D respectively instantiate IP checkers a, b, c and d.

[0110] The top-level generation of the system-level verification environment includes an initialization checker, and the architecture of generating IP checkers within each design module can be similarly referenced, so it will not be elaborated here. The IP checker generated within the design module of the verification environment in this embodiment can be regarded as a module-based checker, which can be used as a reused checker in the verification environment of a new project.

[0111] It should also be noted that Figure 5 The verification system architecture shown is only an optional example. This application embodiment can also support an architecture that generates an inspector only at the top level of the verification environment, without generating an IP inspector inside the design module. For example, this application embodiment can use an inspector generated at the top level of the verification environment to verify the design module in the verification environment, instead of generating an IP inspector inside the design module. When generating an inspector at the top level of the verification environment, the inspector file can be instantiated as part of the top-level file of the verification environment.

[0112] In step S411, a file list of multiplexing checkers is obtained according to the type of the multiplexing checker.

[0113] After determining the type of multiplexer in the verification environment, this embodiment of the application can automatically query a database (e.g., a chip design database) via a script to obtain a file list of multiplexers in the verification environment. This allows for subsequent format replacement of the multiplexer using the file list, thereby reconstructing the multiplexer and setting classification parameters for it. Alternatively, the file list of the multiplexer can be considered a list of verification files used by the multiplexer, including files in the source code that have operated on the multiplexer.

[0114] In some embodiments, taking as an example the reuse checker types determined in the verification environment, such as CDC, Assertion, Force, UVC (Universal Verification Methodology), and Warning, this application embodiment can automatically query the database via script to obtain a file list of checkers of CDC, Assertion, Force, UVC Warning, etc., in the verification environment of a new project. In one example, Table 1 below exemplarily shows an example format of the file list of reuse checkers in the verification environment, which can be referred to.

[0115]

[0116]

[0117] Table 1

[0118] In step S412, an inspector parameter is added to the global file of the verification environment. The inspector parameter includes a classification parameter, which includes at least one classification field.

[0119] After obtaining the file list of reuse checkers in the verification environment through steps S410 and S411, in order to set classification parameters for the reuse checkers, this embodiment of the application requires first adding checker parameters in the form of classification parameters to the global file of the verification environment.

[0120] As an optional implementation, the classification parameter can be an enumeration type proj_t, supporting classification fields such as project identifier, environment identifier, and function identifier. The classification fields in the enumeration type can also be customized according to the needs of the verifier, adding more classification fields that reflect the affiliation of the checker (e.g., adding more classification fields for sub-functions). The classification fields in the enumeration type are easy to maintain. For example, when there are additions to the project or design functions, the verifier can modify the classification fields in the enumeration type to adapt to the project situation and design function situation.

[0121] In one example, taking the classification parameter (e.g., enumeration type) as supporting classification fields such as project identifier, environment identifier, and function identifier, assuming that the project identifier of the old project is S0, the project identifier of the new project is S1, and the environment identifiers of the verification environment corresponding to the old project and the new project are ENV0, ENV1, and ENV2, and the function identifiers are FUN0 to FUNN, then the example definition of the classification parameter can be shown in Table 2 below.

[0122]

[0123] Table 2

[0124] It should be noted that a project may have multiple verification environments and multiple design functions, and a verification environment may also have multiple design functions. In the example in Table 2, the classification parameter can be the project identifier as the classification field (used for classification from the project dimension), or it can be the project identifier and function identifier as the classification fields (used for classification from the project and design function dimensions), or it can be the project identifier, environment identifier, and function identifier as the classification fields (used for classification from the project, verification environment, and design function dimensions). The classification parameter definition forms shown in Table 2 are only optional definition examples of classification parameters. The embodiments of this application can set the specific classification fields and the number of classification fields in the classification parameters as needed, as long as the classification fields in the classification parameters can classify the inspector report in one or more dimensions.

[0125] In step S413, based on the inspector parameters added to the global file, the classification parameters are set for the file content in the file list of the reuse inspector; the classification parameters are used to classify the inspector report of the reuse inspector in at least one dimension, wherein a classification field in the classification parameters is used to classify the inspector report of the reuse inspector in one dimension.

[0126] After determining the file list of the reuse checker and adding checker parameters in the form of classification parameters to the global file of the verification environment, this embodiment of the application can set the classification parameters added in the global file for the files in the file list of the reuse checker, thereby realizing the reconstruction of the reuse checker and setting the classification parameters in the reuse checker.

[0127] In some embodiments, setting classification parameters for file content in the file list of the multiplexing checker can be: based on the file list of the multiplexing checker, performing checker format replacement on files and file positions corresponding to the checker format of the multiplexing checker, so that the replaced checker format has classification parameters.

[0128] As an optional implementation, embodiments of this application can determine the old checker format of the multiplexing checker (i.e., the old format of the multiplexing checker without classification parameters) and the new checker format of the multiplexing checker (i.e., the new format of the multiplexing checker with classification parameters), and then replace the old checker format with the new checker format in the file and file location corresponding to the checker format of the multiplexing checker, so as to realize the format replacement of the multiplexing checker and make the replaced checker format have classification parameters.

[0129] In a further optional implementation, the embodiments of this application can achieve a multiplexing checker replacement format through function refactoring or macro definition. Function refactoring can be used to process the checker function (e.g., information processing function) of the multiplexing checker, so that the checker function's parameters include classification parameters; macro definition can be used to add classification parameters to the multiplexing checker's source code (i.e., macro definition). In one example, function refactoring is applicable to multiplexing checkers with signal processing functions, such as warning checkers with warning information processing interface functions; macro definition is applicable to multiplexing checkers of types such as CDC, Assertion, force, and UVC.

[0130] As an optional implementation Figure 6 An exemplary flowchart illustrates an optional approach to setting classification parameters for a reuse checker by replacing the checker format, see reference. Figure 6 The method process may include the following steps.

[0131] In step S610, based on the inspector parameters added to the global file, classification parameters are set for the old format of the reuse inspector to obtain a new format of the reuse inspector.

[0132] In some embodiments, setting classification parameters for the old format of the multiplexing checker based on function reconstruction can be achieved by adding classification parameters to the original parameters of the checker function of the multiplexing checker, resulting in new parameters for the checker function. In other embodiments, setting classification parameters for the old format of the multiplexing checker based on macro definition can be achieved by adding classification parameters to the original macro definition of the multiplexing checker, resulting in a new macro definition for the multiplexing checker.

[0133] As an optional implementation, based on the function reconstruction method, this embodiment of the application can extract the checker information of the reuse checker from the simulation log. The checker information includes the checker function of the reuse checker. Therefore, based on the checker parameters added to the global file, this embodiment of the application can add classification parameters to the original parameters of the checker function of the reuse checker, thereby obtaining new parameters for the checker function of the reuse checker. Among them, the classification field in the classification parameter can be recognized and processed by the internal code of the checker function so that the output information of the checker function can carry the classification field (for example, the output information of the checker function can be suffixed with the classification field).

[0134] Optionally, the checker function referred to in the embodiments of this application can be an information processing function of the checker, such as the warning information processing interface function of the warning checker; the warning information processing interface function is only an optional example of the information processing function, and any function in the checker that has information processing capabilities can be regarded as the checker function referred to in the embodiments of this application.

[0135] In one example, taking the warning message processing interface function as an example, the original parameters of the warning message processing interface function can be, for example, object, id, old_severity, new_severity, and message. These original parameters can distinguish the output information of the warning message processing interface function by keywords. For example, object can identify a unique verification component, id can identify a unique warning message within that verification component, severity can determine the original severity level of the warning message, and message represents the original warning message. In this embodiment, a classification parameter can be added to the original parameters of the warning message processing interface function. This classification parameter can include at least one classification field; for example, the classification parameter can include at least one of project identifier, environment identifier, and function identifier to distinguish the project, verification environment, and design function in which the warning checker is located. Taking the classification parameter as an enumeration type proj_t, and supporting classification fields such as project identifier as an example, assuming the project identifier is S0 of the old project, and the original parameters of the warning message processing interface function are object_0, id_0, old_severity_UVM_ERROR, and new_severity_UVM_WARNING, then Table 3 below shows an example of the new parameter content of the warning message processing interface function.

[0136] proj_t object id old_severity new_severity S0 object_0 id_0 UVM_ERROR UVM_WARNING

[0137] Table 3

[0138] The content of the example in Table 3 can be considered as the new parameter content of the warning information processing interface function in the case of warning degradation (e.g., the warning changes from UVM_ERROR to UVM_WARNING). Based on the classification parameter (e.g., item identifier S0) carried in the new parameters of the warning information processing interface function, in the case of warning degradation, the warning information in the simulation log will carry the item identifier S0 in the original message; for example, the item identifier S0 will be carried as a suffix to the original message. In one example, the warning information in the simulation log will change from "ERROR_HOOK" to "ERROR_HOOK_S0". Therefore, when the warning information is output to the signoff checker report, this embodiment can realize the automatic classification of warning information for different items according to the item identifier in the warning information; for example, if the warning information is suffixed with the item identifier S0, and the warning information is output to the signoff checker report, this embodiment can determine the warning information content of item identifier S0 according to item identifier S0.

[0139] It should be noted that the example content of the warning information processing interface function, which automatically classifies warning information based on category fields such as project identifiers, is only an optional way for the inspector function's output information to be classified based on category fields. Any inspector function, when adding category parameters, can classify the output information based on each category field or a combination of multiple category fields in the category parameters, and is not limited to warning information. Similarly, the embodiments of this application can add category parameters to the original parameters of the inspector function based on the specific category fields set in the category parameters (such as the category fields in the category parameters shown in Table 2), and are not limited to setting only category parameters with project identifiers.

[0140] In other embodiments, based on macro definitions, this application can define macro definitions with unified naming rules for multiplexing checkers such as CDC, Assertion, force, UVC, and signal, and add classification parameters. That is, this application can add classification parameters (including one or more classification fields) to the existing macro definitions of multiplexing checkers such as CDC, Assertion, force, UVC, and signal checkers, based on checker parameters added to the global file, to obtain new macro definitions for the multiplexing checkers. It should be noted that, unlike function refactoring, when adding classification parameters to the macro definitions of multiplexing checkers, the classification parameters are not used by the internal functions of the multiplexing checkers, but are used in the file source code of the multiplexing checkers to identify classification fields. In other words, for multiplexing checkers such as CDC, Assertion, force, UVC, and signal checkers, the newly added classification parameters exist in the parameters of the macro definitions of the multiplexing checkers and are not passed to the parameter list of the checker functions corresponding to the macro definitions.

[0141] For ease of understanding, the macro definitions of the multiplexing checkers are shown in Table 4 below. Examples of macro definitions for multiplexing checkers such as CDC, Assertion, force, Function, and Signal can be used for reference.

[0142]

[0143] Table 4

[0144] In one alternative implementation example, this application embodiment can add classification parameters to the original macro definitions of each multiplexing checker in the examples in Table 4 above to obtain new macro definitions for the multiplexing checkers.

[0145] In step S611, based on the file list of the multiplexing checker, the file and file location corresponding to the checker format of the multiplexing checker are determined; based on the determined file, file location, old format and new format of the multiplexing checker, replacement information of the multiplexing checker is formed.

[0146] Optionally, the replacement information for the multiplexing checker can be in tabular form, such as a replacement table for the multiplexing checker. In some embodiments, this application can perform automated script searches on a database (e.g., a chip design database) based on the file list of the multiplexing checker (e.g., as shown in Table 1) to determine the files and file locations in the file list that correspond to the checker format of the multiplexing checker; simultaneously, based on the new format and the old format of the multiplexing checker, a replacement table for the checker functions is formed, which can be used to perform format replacement on the multiplexing checker. In one example, the new format of the multiplexing checker can be, for example, the new parameters of the checker functions shown in Table 3 (with added classification parameters); in another example, the new format of the multiplexing checker can be, for example, based on the macro definitions shown in Table 4, with added new macro definitions containing classification parameters. The old format of the multiplexing checker can be, for example, the original parameters of the checker functions, or the macro definition content shown in Table 4 (without set classification parameters).

[0147] In other words, in an optional implementation, the replacement table of the multiplexing checker can include the file corresponding to the checker format of the multiplexing checker, the file position (e.g., a line in the file), the old format, and the new format. In one example, using the CDC checker, Table 5 below exemplarily shows sample content of the replacement table for reference.

[0148]

[0149] Table 5

[0150] Here, tb.udut.syncra represents the path of the design module of the reuse checker in the verification environment, tb is the instantiation of the first layer in this path, udut is the instantiation name of the second layer, and so on.

[0151] In step S612, after checking and confirming the replacement information, the old format is replaced with the new format in the file and file location indicated by the replacement information.

[0152] In some embodiments, for the replacement information of the formed multiplexing checker, this application embodiment can manually check the replacement information to confirm whether the format replacement of each type of multiplexing checker meets expectations; for content in the replacement information that does not meet expectations (for example, statements in the replacement information that reference underlying functions are considered to be content that does not meet expectations without considering the reconstruction of underlying functions), manual modification or deletion can be performed to avoid the problem of script replacement errors. Thus, after checking and confirming that the replacement information meets expectations, this application embodiment can perform script scanning on the replacement information of the multiplexing checker, and based on the file indicated by the replacement information (e.g., the file in the File column of the example in Table 5) and the file position (e.g., the row number in the Line column of the example in Table 5), replace the corresponding old format content (e.g., the content in the Old format column of the example in Table 5) with the new format content (e.g., the content in the New format column of the example in Table 5); and then, after regression confirms that the multiplexing checker update function is normal, the database is updated.

[0153] It should be noted that the script referred to in this application embodiment is an executable file written in a specific descriptive language and according to a certain format, capable of batch processing files. The checker format referred to in this application embodiment is the source code format of the checker. Based on the function refactoring rules and macro definition rules of this application embodiment, this application embodiment can rewrite the code of the Old format column of the reuse checker and add classification parameters to generate the New format column format. In addition, the script may contain the checker's code format, but not the checker's file name and file line information; the file name and file line information are automatically recorded by the script through script search. The replacement table serves as an intermediate table for batch processing, used for manual review of whether the new format of the New format column is correct, avoiding erroneous operations caused by script errors. After confirming that the replacement table is correct, the script can be run to replace the code format of the reuse checker, replacing the code of the Old format column with the code of the New format column.

[0154] In further embodiments, considering that new projects may contain difference checkers compared to old projects, such as invalid checkers and newly added checkers in the new project, this application further provides a scheme for processing invalid checkers and newly added checkers. For invalid checkers, since invalid checkers are no longer applicable in the new project, this application can replace the format of the invalid checker by setting whitespace characters in the format content, so that the invalid checker is no longer used in the new project. For newly added checkers, this application can include classification parameters in the parameter passing content of the newly added checker when adding it, so that the newly added checker has classification parameters, and thus the checker report of the newly added checker can perform classification based on the classification field in the classification parameters in different dimensions.

[0155] As an optional implementation Figure 7A An exemplary flowchart of an optional method for processing an invalidity checker according to an embodiment of this application is shown, with reference to... Figure 7A The method process may include the following steps.

[0156] In step S710, the type of invalid checker in the verification environment is determined.

[0157] In step S711, a list of invalid checker files is obtained according to the type of invalid checker.

[0158] In some embodiments, this application can compare the functional manuals between projects (e.g., the functional manuals between old and new projects) to determine the invalid checker type in the verification environment of the new project. Based on the invalid checker type, the database can be automatically queried by a script to obtain a list of invalid checker files, so that the file content related to the format of the invalid checker in the file list of invalid checkers can be set with whitespace characters.

[0159] In one example, taking the invalid checkers of type CheckerX and CheckerY as examples, Table 6 below shows an example of the file list of invalid checkers for reference.

[0160] Type File CheckerX File_X0…File_XN CheckerY File_Y0…File_YN

[0161] Table 6

[0162] In step S712, the file contents in the file list of the invalid checker are set to blank characters.

[0163] In some embodiments, setting the file content in the file list of the invalid checker to whitespace can be: based on the file list of the invalid checker, replacing the checker format with whitespace in the file and file position corresponding to the checker format of the invalid checker, so that the invalid checker is no longer used.

[0164] As an optional implementation, embodiments of this application can determine the file and file location corresponding to the checker format of the invalid checker based on the file list of the invalid checker; simultaneously, based on the determined file and file location, and the old format and new format of whitespace characters corresponding to the determined file and file location of the invalid checker, replacement information (e.g., a replacement table) for the invalid checker is formed; then, after the replacement information of the invalid checker is checked and confirmed to be correct, the old format of the invalid checker can be replaced with the new format of whitespace characters according to the file and file location indicated by the replacement information of the invalid checker, so as to replace the checker format of the invalid checker with whitespace characters, so that the invalid checker is no longer used.

[0165] In one example, taking a certain type of CDC checker as an example, if the CDC checker's hierarchy is tb.udut.core.syncr and it is no longer used in a new project, then this embodiment of the application can automatically search the database using a script based on the list of invalid checker files to determine the files and file locations corresponding to the checker format of the invalid checker; simultaneously, combining the old format corresponding to the determined files and file locations with the new format of whitespace characters, a replacement table for invalid checkers is formed. In one example, an example of the replacement table format can be seen in Table 7 below.

[0166]

[0167] Table 7

[0168] After obtaining the replacement table for the invalidity checker, this embodiment can manually check the replacement table to confirm whether the format replacement content in the replacement table meets expectations, avoiding script misoperation issues. Then, after confirming that the replacement table for the invalidity checker is correct, this embodiment can perform a script scan on the replacement table for the invalidity checker. This involves replacing the old format content in the "Old format" column with blank characters in the "New format" column at the file positions indicated by the "File" column and the "Line" column in the replacement table, and updating the server's database. This ensures that the file content of the invalidity checker is set to blank characters, preventing the invalidity checker from being used in the new project. In other words, this embodiment can delete the old format code of the invalidity checker, ensuring that the subsequent signoff process will not output invalidity checker information.

[0169] As an optional implementation Figure 7BAn exemplary flowchart illustrates an optional method for setting classification parameters for a new inspector according to an embodiment of this application. (Refer to...) Figure 7B The method process may include the following steps.

[0170] In step S720, new inspectors are identified in the verification environment.

[0171] In step S721, based on the inspector parameters added in the global file, when setting parameters for the new inspector, classification parameters are carried in the parameter passing content of the new inspector so that the new inspector has classification parameters.

[0172] In some embodiments, this application can determine the new inspector in the verification environment of a new project by comparing the functional manuals between projects. Since the new inspector does not exist in the old project, this application needs to set new parameters for it. Setting parameters for the new inspector involves passing parameters to it. Because this application adds inspector parameters in the form of classification parameters to the global file of the verification environment, it can carry classification parameters in the parameter passing content of the new inspector based on the inspector parameters added to the global file when passing parameters to it. This allows the new inspector to have classification parameters, enabling its inspector report to be classified in different dimensions based on the classification field in the classification parameters.

[0173] In one example, taking a newly added inspector as a warning inspector with an information processing interface function as an example, when passing parameters to the newly added warning inspector, the parameter content can include not only parameters such as object, id, old_severity, new_severity, and message, but also category parameters. As an example, if the category parameters of the newly added inspector need to be set to the project identifier of S1, the environment identifier of ENV0, and the function identifier of FUN0, Table 8 below shows a partial example of the parameter content of the newly added inspector for reference.

[0174]

[0175]

[0176] Table 8

[0177] In one implementation example, for a reuse checker, this embodiment of the application can set classification parameters including project identifiers for the reuse checker. For example, for a reuse checker that can reuse old projects, the project identifier can be used as a keyword to classify the checker report of the reuse checker. For a new checker, since there is no reuse in the new checker, this embodiment of the application can set classification parameters including project identifiers, environment identifiers, and function identifiers for the new checker. Of course, the implementation content in this paragraph is only an example. For the reuse checker and the new checker, this embodiment of the application can specifically set the classification fields of the classification parameters in the reuse checker and the classification fields of the classification parameters in the new checker according to the classification needs of the verification personnel, and is not limited to the example described in this paragraph.

[0178] After setting classification parameters for target inspectors (such as reused inspectors and new inspectors) in the verification environment, embodiments of this application can use the verification environment to perform simulation verification of the design and generate inspector reports for the target inspectors in the verification environment. Based on the classification fields in the classification parameters set for the target inspectors, the inspector reports are classified in different dimensions so that the report content of the target inspectors can be efficiently checked in different types of dimensions, thereby improving the inspection quality of the inspector reports.

[0179] As an optional implementation Figure 8A An exemplary flowchart of an optional report generation method provided in an embodiment of this application is shown. This method can be implemented by a simulation verification tool for simulating and verifying chip designs. The simulation verification tool can be a computer program running on a computer device; see reference... Figure 8A The method process may include the following steps.

[0180] In step S810, regression verification of the design is performed in the verification environment, and a checker report of the target checker in the verification environment is generated.

[0181] In step S811, the inspector report is classified in at least one dimension according to at least one classification field included in the classification parameters set by the target inspector, so as to obtain report content in at least one dimension; wherein, a classification field is used to classify the inspector report in one dimension.

[0182] In some embodiments, the present application embodiments can utilize the verification environment of a new project to perform regression verification on the design, thereby the script of the automatic reporting layer can analyze the regression verification results of the verification environment and generate a checker report for the target checker; the checker report for the target checker can be regarded as the signoff report of the target checker; furthermore, based on the classification parameters set for the target checker in the present application embodiments, the present application embodiments can classify the checker report of the target checker in at least one dimension based on at least one classification field in the classification parameters to obtain report content in at least one dimension.

[0183] As an optional implementation, taking the classification fields in the classification parameters as including project identifier, environment identifier and function identifier as an example, the embodiments of this application can classify the inspector report of the target inspector according to the project dimension based on the project identifier of the old project and the new project in the classification field, and obtain the report content of the target inspector in the new project and the old project respectively;

[0184] Regarding the report content of the target inspector in a new project, this embodiment of the application can classify the report content of the target inspector in a new project according to the verification environment dimension based on the environment identifier in the classification field, so as to obtain the report content corresponding to different verification environments of the target inspector in the new project.

[0185] For the report content of the target inspector in any verification environment of the new project, the embodiments of this application can classify the report content of the target inspector in the verification environment of the new project according to the functional identifier in the classification field, so as to obtain the report content of the target inspector in each functional dimension of the verification environment of the new project.

[0186] The above description uses the classification fields in the classification parameters, which include project identifier, environment identifier, and function identifier, as an example. The embodiments of this application can also support classification fields including at least one of project identifier, environment identifier, and function identifier, thereby supporting the classification of the inspector report of the target inspector in at least one dimension, and not limited to classification from the perspective of project, verification environment, and function.

[0187] In one implementation example, the CDC inspector is configured with category fields including project identifier, environment identifier, and function identifier. The project identifier includes S0 and S1 (S0 is the project identifier of the old project, and S1 is the project identifier of the new project; the CDC inspector of the old project can be reused by the new project because it inherits from the old project), the environment identifier includes ENV0 to ENVN, and the function identifier includes FUN0 to FUNN. Figure 8B An exemplary diagram illustrating the processing flow of an inspector report is shown, such as... Figure 8B As shown:

[0188] After performing regression verification on the design using the verification environment of the new project S1, the script in the automatic reporting layer can generate a CDC report by analyzing the regression verification results of the verification environment. The CDC report can be regarded as the signoff report of the CDC checker.

[0189] Based on the item identifiers S0 and S1 set in the classification parameters of the CDC inspector, the embodiments of this application can classify the CDCreport according to the item dimension to obtain the report content of the CDC inspector in the old item S0, CDC_S0 report, and the report content of the CDC inspector in the new item S1, CDC_S1 report.

[0190] As an optional implementation, for the CDC checker's report content CDC_S0 report in the old project S0, this embodiment of the application can reuse the CDC checker's report content in the new project S1 after analyzing the regression verification results of the verification environment of the new project S1, and automatically fill in the CDC checker's signoff table in the old project S0 by adjusting the project identifier to S0, thereby obtaining the CDC checker's report content CDC_S0 report in the old project S0; in one example, the sample content of the reused CDC_S0 report can be shown in Table 9 below;

[0191]

[0192] Table 9

[0193] Further combining with 8B, regarding the report content CDC_S1 report of the CDC inspector in the new project S1, this embodiment of the application can classify the report content CDC_S1 report of the CDC inspector in the new project S1 according to the environmental identifiers ENV0 to ENVN set in the classification parameters of the CDC inspector, and obtain the report content corresponding to the verification environment ENV0 to ENVN of the CDC inspector in the new project S1 respectively: CDC_S1_ENV0 report to CDC_S1_ENVN report;

[0194] For the report content of the CDC inspector in any verification environment of the new project S1, this embodiment of the application can classify the report content of the CDC inspector in the verification environment of the new project S1 according to the functional identifiers FUN0 to FUNN set in the classification parameters of the CDC inspector, thereby obtaining the report content of the CDC inspector in each functional dimension of each verification environment of the new project S1; for example, combined with Figure 8BAs shown, for the report content (CDC_S1_ENV0 report) corresponding to the verification environment ENV0 of the new project S1, the embodiments of this application can further classify it according to the functional dimensions from FUN0 to FUNN to obtain the report content of the CDC inspector corresponding to the functional dimensions from FUN0 to FUNN in the verification environment ENV0 of the new project S1: CDC_S1_ENV0_FUN0 report to CDC_S1_ENV0_FUNN report.

[0195] In further embodiments, after obtaining the report content of each functional dimension of the target inspector in the verification environment of the new project, this application embodiment can determine the verification personnel corresponding to the report content of each functional dimension of the target inspector in the verification environment of the new project, based on the report content of each functional dimension of the target inspector in the verification environment of the new project, and task allocation information (e.g., task allocation table). This allows verification personnel to obtain and check the report content of their assigned functional dimensions, avoiding checking conflicts between verification personnel and thus improving the checking accuracy of the report content of the functional dimensions. Furthermore, it allows each verification personnel to quickly view the checking progress of the report content of each functional dimension. The task allocation information (e.g., task allocation table) can record the correspondence between functions and verification personnel; the correspondence between functions and verification personnel can indicate the design functions that verification personnel should check.

[0196] In further examples, combined Figure 8B As shown, the Owner Mapping (task allocation table) can record the relationship between Function (specifically, design function) and Verifier (Owner). For example, the Verifier identified by Owner_0 can check the design function of FUN0, and the Verifier identified by Owner_1 can check the design function of FUN1.

[0197] In further embodiments, based on the inspection results of the target checker's report content in each functional dimension of the new project, this application embodiment can modify the verification environment and target checker of the new project, thereby performing regression verification iteration and signoff processing in the verification environment of the new project until the report content of each functional dimension in the verification environment of the new project reaches the convergence condition; then, after the report content of each functional dimension reaches the convergence condition, for any verification environment of the new project, this application embodiment can merge the report content of each functional dimension in the verification environment of the new project to obtain the summary report content of the target checker in each verification environment of the new project; and then, merge the summary report content of the target checker in each verification environment of the new project with the report content of the target checker in the old project to obtain the target report content of the target checker in each verification environment.

[0198] In one implementation example, combining Figure 8B As shown, for the verification environment ENV0 of the new project S1, after the CDC_S1_ENV0_FUN0 report to the CDC_S1_ENV0_FUNN report are checked by the corresponding verification personnel, this embodiment of the application can modify the verification environment ENV0 and the CDC checker of the new project S1 based on the inspection results of the CDC_S1_ENV0_FUN0 report to the CDC_S1_ENV0_FUNN report, until the report content of each functional dimension of the CDC checker in the verification environment ENV0 of the new project S1 reaches the convergence condition; then, this embodiment of the application can merge the report content of each functional dimension of the CDC checker in the verification environment ENV0 of the new project S1 that has reached the convergence state to obtain the summary report content CDC_S1_ENV0_new report of the CDC checker in the verification environment ENV0 of the new project S1; then, the CDC_S1_ENV0_new report is merged with the report content CDC_S0 report of the CDC checker in the old project S0 to obtain the target report content CDC_ENV0_new report of the CDC checker in the verification environment ENV0. Furthermore, the CDC_S1_ENV0_new report can back-annotate the same signoff entries in the CDC_S1_ENV1 report to the CDC_S1_ENVN report that are identical to those in the CDC_S1_ENV0_new report.

[0199] It should be noted that the signoff entries identical to ENV0 can be automatically confirmed through the above steps, while the remaining differentiated entries can also be obtained in the same way as described in this application embodiment, and will not be elaborated here.

[0200] It should be noted that, in the optional implementation method, the convergence condition for the report content of each functional dimension in the verification environment of the new project can be: all the check items corresponding to the report content of each functional dimension in the verification environment of the new project have been confirmed as passed, the verification personnel have signed the pass comments and reasons for passing, and there are no blank items.

[0201] It should be further explained that, in the optional implementation, the modification of the verification environment and target inspector of the new project based on the report content of the target inspector in each functional dimension of the new project can be as follows: by analyzing the report content, identifying and correcting any questionable aspects of the target inspector's closure, which is related to the specific functional analysis of the project; for example, if the verification environment is fine and the target inspector should not be closed, the target inspector code needs to be modified to open the target inspector; or, for example, if the verification environment has problems and the target inspector should not be closed, the verification environment and the target inspector code need to be modified to open the target inspector.

[0202] In further embodiments, based on the methods described above, the target report content of the target inspector in different types of verification environments can be obtained. For example, the target report content of the target inspector in various IP verification environments, various subsystem verification environments, and various system-level verification environments can all be obtained in the same way as described above. Therefore, the target report content of the target inspector in different types of verification environments can be subjected to back-annotation processing of the verification environment to achieve hierarchical management and inspection of the target report content of the target inspector in different types of verification environments.

[0203] As an optional implementation, the target report content of the target checker in each verification environment obtained in this embodiment may include: the target report content of the target checker in each IP verification environment, the target report content in each subsystem verification environment, and the target report content in the system-level verification environment. Therefore, this embodiment can merge the target report content of the target checker in each IP verification environment to obtain a merged report content of the target checker at the IP verification environment level. Furthermore, the target report content of the target checker in each IP verification environment is merged with the target report content of the target checker in the subsystem verification environment to obtain a merged report content of the target checker at the subsystem verification environment level. Then, using the merged report content of the target checker at the IP verification environment level and the merged report content of the target checker at the subsystem verification environment level, regression verification iteration is performed on the subsystem verification environment until the subsystem verification environment reaches a convergence state.

[0204] After the subsystem verification environment reaches a convergence state, the embodiments of this application can merge the report content of the target inspector in the subsystem verification environment with the target report content of the target inspector in the system-level verification environment to obtain the merged report content of the target inspector at the system-level verification environment level; then, using the merged report content of the target inspector at the system-level verification environment level, regression verification iteration is performed on the system-level verification environment until the system-level verification environment reaches a convergence state.

[0205] Through the above methods, the embodiments of this application can realize hierarchical management and inspection of the report content of the target inspector at different levels of IP verification environment, subsystem verification environment and system-level verification environment, thereby further improving the inspection quality of the inspector report.

[0206] This application embodiment reconstructs the target inspector in the verification environment, enabling the target inspector to be set with classification parameters (e.g., the enumeration type proj_t). As a result, the inspector report of the target inspector can be classified according to different dimensions such as project, verification environment, and function based on the classification field in the classification parameters. This achieves automatic signoff of report content in the project dimension when the inspector is reused, classification of differential reports in different dimensions of the verification environment, and automatic task allocation of report content in the function dimension, thereby improving the inspection quality of the inspector report.

[0207] To facilitate comparison of the solutions provided in the embodiments of this application with... Figure 2 The advantages of the example solution are discussed below, comparing the solution provided in the embodiments of this application with those of other solutions. Figure 2 The problem that the example solution can solve will be further elaborated:

[0208] (1) With the launch of new projects and the updating of verification environments, changes in the implementation of inspectors, their location files, or lines of code may occur. The signoff reports of old projects may not be automatically reverse-annotated or may be prone to mismatches in reverse-annotation. This results in the inability to automatically signoff reused items between projects, requiring manual inspection and reversal processing. Even if the original signoff report can be referenced, manually searching for the report is time-consuming and laborious. For example, in the IP verification environment, there are more than 20 types of inspectors and thousands of verification items, generating tens of thousands of signoff report items. The situation of inspectors corresponding to subsystems and SOC systems is even more complex, which leads to a repetitive and huge workload in checking inspector reports.

[0209] This application embodiment reconstructs the reuse checker (UVC, CDC, Assertion, force, etc.) of the new project. For example, it automatically captures the reuse checker between projects through a script and performs macro definition format replacement and checker function format replacement. Thus, a classification parameter including at least the project identifier (e.g., the project name with the project identifier as signoff) can be set in the reuse checker. Then, when generating the checker report of the reuse checker, this application embodiment can automatically signoff the report content from the project dimension according to the project identifier in the classification parameter, thereby solving the problem mentioned in (1) above.

[0210] (2) For reused modules, there will be subtle differences when they are reused in different levels of verification environments. For example, a certain CDC checker in the IP checker needs to be distinguished by environment macro definitions due to the differences between the SOC and IP verification environments. However, each verification environment will generate a signoff report. For reused checkers, a large number of duplicate entries have already been confirmed in the IP verification environment, and there is no need to perform the same duplicate operation in the subsystem or SOC verification environment. Figure 2 The signoff report generated by the example solution cannot distinguish these differences, requiring manual code inspection to find macro-defined code blocks in each verification environment. This process is tedious, repetitive, and prone to errors. Therefore, it is necessary to accurately find the entries with the above differences in the inspector and clarify the scope of signoff responsibility.

[0211] Based on this, the embodiments of this application can delete invalid checkers, and can pass classification parameters including project identifier, environment identifier and function identifier during the parameter passing process of adding a checker. Thus, the checker report of the added checker can generate a signoff report for each verification environment through a script based on the environment identifier of the classification parameter, so as to solve the problem mentioned in (2) above.

[0212] (3) A single inspection report involves multiple functional inspectors, requiring multiple verifiers to work simultaneously. This often leads to access conflicts, affecting inspection efficiency and making it inconvenient to track the progress of each functional module.

[0213] (4) The shared files of the verification environment involve multiple functional checkers, such as the underlying test cases of the verification environment. Each functional checker corresponds to a different verification personnel. The signoff report generated by the script cannot automatically assign personnel and requires manual inspection to assign tasks. For such shared file checker entries, there are thousands, tens of thousands or even hundreds of thousands of entries. Manual allocation is not accurate, and it is also very tedious and inefficient, resulting in an extra waste of manpower.

[0214] Based on this, the embodiments of this application can further classify the report content of the target inspector in the verification environment dimension of the project according to the functional identifier in the classification parameters, and obtain the report content of the target inspector in each functional dimension of the project verification environment, thereby generating the report content of each functional dimension; and based on the correspondence between the function indicated by the task allocation table and the verification personnel, the report content of each functional dimension can be automatically assigned tasks and the completed signoff duplicate entries can be filtered out, so that after the report content of all functional dimensions is checked, the summary report of the verification environment dimension is generated by merging, thereby solving the problems mentioned in (3) and (4) above.

[0215] To facilitate a further understanding of the solutions provided in the embodiments of this application, Figure 9An exemplary diagram illustrates the implementation process of this application, from setting up the inspector to generating a report, as shown in the following example diagram. Figure 9 As shown, this process can mainly include the following stages:

[0216] The reuse checker refactoring phase 911 is used to refactor the reuse checker in the validation environment of the new project, so that the reuse checker is set with classification parameters; the reuse checker refactoring phase may include:

[0217] Determine the file list for the reuse checker;

[0218] Function refactoring and macro definition processing; for example, selecting the function refactoring method or macro definition method based on the different types of reuse checkers, and determining the replacement table of the checker format of the reuse checker;

[0219] Script processing; for example, by using script processing and replacing tables, the format of the reuse checker can be replaced with a new format that has classification parameters set; the relevant content of the reuse checker reconstruction stage can be found in the description of the corresponding section above, and will not be elaborated here.

[0220] The difference checker processing stage 912 is used to de-use invalid checkers in the new project's verification environment and to set classification parameters for new checkers. The difference checker processing stage 912 may include: checker classification, used to determine invalid checkers and new checkers in the new project's verification environment; checker update, used to set the checker format of the classified invalid checkers to blank characters, and to carry classification parameters in the parameter content when passing parameters to new checkers, so that the new checkers can set classification parameters. The implementation process of the above can be referred to the description of the corresponding section above, and will not be elaborated here.

[0221] The regression verification phase 913 is used to perform regression verification of the design using a verification environment.

[0222] Phase 914 generates the signoff report and generates the checker report (i.e., the checker's signoff report) for the target checker (e.g., a reused checker, a new checker, etc.) by analyzing the regression validation results of the validation environment.

[0223] In the signoff report processing stage 915, the signoff reports from the target inspector are categorized by project dimension to obtain project report content; the project report content is then categorized by verification environment dimension to obtain the project's report content in the verification environment; the project's report content in the verification environment is further categorized by function dimension to obtain the project's report content in the verification environment's function dimension; and, according to the task allocation table, the report content of each function dimension of the project in the verification environment is assigned to the corresponding verification personnel.

[0224] The functional report inspection phase 916 is used by validators to inspect and confirm the content of the functional dimension reports. Based on the inspection results of the functional dimension report content, the regression validation, reuse checker and difference checker can be modified so that the functional dimension report content reaches a convergent state.

[0225] The report summary stage 917 is used to merge the report content of each functional dimension in the new project's verification environment based on the report content of the functional dimensions that have reached the convergence state, so as to obtain the summary report content of the target checker in each verification environment of the new project; further, the summary report content of the target checker in each verification environment of the new project can be merged with the report content of the target checker in the old project to obtain the target report content of the target checker in each verification environment.

[0226] This application embodiment can segment inspector reports in multiple dimensions, generate reusable signoff reports, and automatically allocate tasks. This allows for focused signoff checks, reducing manual intervention time, significantly improving signoff efficiency, and ensuring verification quality. Furthermore, this application embodiment can generate inspector reports for different levels of verification environments, such as IP verification environments, subsystem verification environments, and system-level verification environments, reducing redundant work between different verification environments. It can also review inspector reports, for example, focusing on signoff checks of inspectors for differences in new projects, thereby improving signoff efficiency.

[0227] The inspector setting apparatus provided in the embodiments of this application will be described below. The apparatus described below can be considered as the functional modules required for the simulation verification tool (running on a computer device) to implement the inspector setting method provided in the embodiments of this application. The apparatus described below can be referred to in correspondence with the description above.

[0228] As an optional implementation Figure 10A An exemplary block diagram of the inspector setting apparatus provided in an embodiment of this application is shown, such as... Figure 10A As shown, the device may include:

[0229] The target inspector determination module 101 is used to determine the target inspector in the verification environment;

[0230] The parameter definition module 102 is used to define inspector parameters in the global file of the verification environment. The inspector parameters include classification parameters, and the classification parameters include at least one classification field.

[0231] The parameter setting module 103 is used to set classification parameters for the target inspector based on the inspector parameters defined in the global file; the classification parameters of the target inspector are used to classify the inspector report of the target inspector in at least one dimension, wherein a classification field in the classification parameters is used to classify the inspector report of the target inspector in one dimension.

[0232] In some embodiments, the at least one classification field is one or more keywords that determine the attribution of the inspector.

[0233] In some embodiments, the at least one classification field includes at least one of a project identifier, an environment identifier, and a function identifier; wherein the project identifier indicates the project corresponding to the verification environment in which the inspector is located; the environment identifier indicates the verification environment to which the inspector belongs; and the function identifier indicates the design function of the project and / or the verification environment.

[0234] In some embodiments, the target inspector includes a reuse inspector, which is an inspector of an old project reused in the verification environment of a new project, the new project inheriting from the old project.

[0235] As an optional implementation, the target inspector determination module 101, used to determine the target inspector in the verification environment, includes:

[0236] Determine the type of reuse inspector in the verification environment;

[0237] Based on the type of the multiplexing checker, obtain a file list of multiplexing checkers.

[0238] As an optional implementation, parameter setting module 103 is used to set classification parameters for the target inspector based on the inspector parameters defined in the global file, including:

[0239] Based on the inspector parameters added to the global file, the classification parameters are set for the file content in the file list of the reuse inspector; the classification parameters are used to classify the inspector report of the reuse inspector in at least one dimension, wherein a classification field in the classification parameters is used to classify the inspector report of the reuse inspector in one dimension.

[0240] Optionally, the parameter setting module 103 is used to set the classification parameters for the file content in the file list of the reuse checker according to the checker parameters added to the global file, including:

[0241] Based on the inspector parameters added to the global file, classification parameters are set for the old format of the reuse inspector to obtain a new format for the reuse inspector;

[0242] Based on the file list of the multiplexing checker, determine the file and file location that correspond to the checker format of the multiplexing checker in the file list of the multiplexing checker; based on the determined file, file location, old format and new format of the multiplexing checker, form replacement information for the multiplexing checker;

[0243] After verifying and confirming the replacement information, replace the old format with the new format in the file and file location indicated by the replacement information.

[0244] Optionally, the parameter setting module 103 is used to set classification parameters for the old format of the reuse checker based on the checker parameters added in the global file, so as to obtain a new format of the reuse checker, including:

[0245] Extract the checker information of the reuse checker from the simulation log. The checker information includes the checker function of the reuse checker. Based on the checker parameters added to the global file, add classification parameters to the original parameters of the checker function to obtain new parameters of the checker function. The classification field in the classification parameters is recognized and processed by the internal code of the checker function so that the output information of the checker function carries the classification field.

[0246] And / or, based on the inspector parameters added to the global file, a classification parameter is added to the original macro definition of the reuse inspector to obtain a new macro definition of the reuse inspector.

[0247] In some embodiments, the target inspector includes a new inspector, which is a new inspector added relative to an old project in the verification environment of a new project.

[0248] As an optional implementation, parameter setting module 103 is used to set classification parameters for the target inspector based on the inspector parameters defined in the global file, including:

[0249] Based on the inspector parameters added to the global file, when setting parameters for the new inspector, classification parameters are carried in the parameter passing content of the new inspector so that the new inspector has classification parameters.

[0250] In further embodiments, the apparatus provided in this application can also be used to: determine the type of invalid checker in the verification environment; the invalid checker is a checker that is no longer applicable to the new project in the old project; obtain a file list of invalid checkers according to the type of invalid checker; and set the file content in the file list of invalid checkers to blank characters.

[0251] As an optional implementation, the device is used to set the file contents in the invalidity checker's file list to whitespace characters, including:

[0252] Based on the invalid checker's file list, determine the file and file location that correspond to the invalid checker's checker format;

[0253] Based on the determined file, file location, and the old format and new format of whitespace characters corresponding to the determined file and file location, the replacement information of the invalid checker is formed.

[0254] After the invalidity checker's replacement information is checked and confirmed to be correct, the old format of the invalidity checker is replaced with the new format of whitespace characters according to the file and file location indicated by the invalidity checker's replacement information.

[0255] In some embodiments, the target inspector includes a reuse inspector and a new inspector; wherein the classification parameters set in the reuse inspector include an item identifier;

[0256] The new inspector settings include item identifier and function identifier in the classification parameters; or, the new inspector settings include item identifier, environment identifier, and function identifier in the classification parameters.

[0257] This application also provides a report generation apparatus. The apparatus described below can be considered as the functional modules required by the simulation verification tool (running on a computer device) to implement the report generation method provided in this application. The apparatus described below can be referred to in correspondence with the description above.

[0258] As an optional implementation Figure 10B An exemplary block diagram of the report generation apparatus provided in an embodiment of this application is shown, such as... Figure 10B As shown, the device may include:

[0259] The regression verification and report generation module 111 is used to perform regression verification on the design in the verification environment and generate a checker report for the target checker in the verification environment; the target checker is set with classification parameters based on the checker setting method provided in the embodiments of this application.

[0260] The classification module 112 is used to classify the inspector report in at least one dimension according to at least one classification field included in the classification parameters set by the target inspector, so as to obtain report content in at least one dimension; wherein, a classification field is used to classify the inspector report in one dimension.

[0261] In some embodiments, the classification fields in the classification parameters include project identifier, environment identifier, and function identifier.

[0262] As an optional implementation, the classification module 112 is used to classify the inspector report in at least one dimension according to at least one classification field included in the classification parameters set by the target inspector, so as to obtain report content in at least one dimension including:

[0263] Based on the project identifiers of old and new projects in the classification field, the inspector report is classified according to the project dimension to obtain the report content of the target inspector for new and old projects respectively;

[0264] Based on the environment identifier in the classification field, the report content of the target inspector in the new project is classified according to the verification environment dimension to obtain the report content of the target inspector corresponding to different verification environments in the new project.

[0265] For the report content of the target inspector in any verification environment of the new project, based on the functional identifier in the classification field, the report content of the target inspector in the verification environment of the new project is classified according to the functional dimension to obtain the report content of the target inspector in each functional dimension of the verification environment of the new project.

[0266] In some further embodiments, the device can also be used for:

[0267] Based on the report content of each functional dimension and the task allocation information, the verification personnel corresponding to the report content of each functional dimension are determined; wherein, the task allocation information records the correspondence between functions and verification personnel, and the correspondence between functions and verification personnel indicates the design functions that the verification personnel should check.

[0268] In some further embodiments, the device can also be used for:

[0269] Based on the inspection results of the report content of each functional dimension, the verification environment and target inspector of the new project are modified until the report content of each functional dimension reaches the convergence condition.

[0270] After the report content of each functional dimension reaches the convergence condition, for any verification environment of the new project, the report content of each functional dimension in the verification environment of the new project is merged to obtain the summary report content of the target checker in each verification environment of the new project.

[0271] The summary reports of the target checker in each verification environment of the new project are merged with the reports of the target checker in the old project to obtain the target report content of the target checker in each verification environment.

[0272] As an optional implementation, the target report content of the target inspector in each verification environment includes: the target report content of the target inspector in each IP verification environment, the target report content in each subsystem verification environment, and the target report content in the system-level verification environment.

[0273] In some further embodiments, the device can also be used for:

[0274] The target report content of the target inspector in each IP verification environment is merged to obtain the merged report content of the target inspector at the IP verification environment level.

[0275] The target report content corresponding to each IP verification environment of the target inspector is merged with the target report content of the target inspector in the subsystem verification environment to obtain the merged report content of the target inspector at the subsystem verification environment level.

[0276] Using the merged report content of the target inspector at the IP verification environment level and the merged report content of the target inspector at the subsystem verification environment level, regression verification iteration is performed on the subsystem verification environment until the subsystem verification environment reaches a convergence state.

[0277] After the subsystem verification environment reaches a convergence state, the report content of the target checker in the subsystem verification environment is merged with the target report content of the target checker in the system-level verification environment to obtain the merged report content of the target checker at the system-level verification environment level.

[0278] By utilizing the merged report content of the target inspector at the system-level verification environment level, regression verification iterations are performed on the system-level verification environment until the system-level verification environment reaches a convergent state.

[0279] This application also provides a computer device that can execute computer-executable instructions and other programs to implement the inspector setting method and / or report generation method provided in this application. As an optional implementation, Figure 11 An exemplary block diagram of an optional computer device provided in an embodiment of this application is shown, such as... Figure 11 As shown, the computer device may include at least one processor 11, at least one communication interface 21, at least one memory 31, and at least one communication bus 41.

[0280] In this embodiment of the application, the number of processor 11, communication interface 21, memory 31 and communication bus 41 is at least one, and processor 11, communication interface 21 and memory 31 communicate with each other through communication bus 41.

[0281] Optionally, the communication interface 21 can be an interface for a communication module used for network communication.

[0282] Optionally, the processor 11 may be a CPU (Central Processing Unit), GPU (Graphics Processing Unit), NPU (Embedded Neural Network Processor), FPGA (Field Programmable Gate Array), TPU (Tensor Processing Unit), AI chip, ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0283] The memory 31 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage.

[0284] The memory 31 stores one or more computer-executable instructions, and the processor 11 calls the one or more computer-executable instructions to execute the checker setting method and / or report generation method provided in the embodiments of this application.

[0285] This application also provides a storage medium that stores one or more computer-executable instructions. When these instructions are executed, they implement the checker setting method and / or report generation method provided in this application.

[0286] The foregoing describes multiple embodiment schemes provided by the embodiments of this application. The optional methods described in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending to a variety of possible embodiment schemes. These can all be considered as the embodiment schemes disclosed and published by the embodiments of this application.

[0287] While the embodiments disclosed above are described in this application, this application is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application should be determined by the scope defined in the claims.

Claims

1. A method for setting up an inspector, characterized in that, include: A target checker is identified in the verification environment, wherein the chip design is verified and simulated in the verification environment to verify whether the chip design meets the design expectations; In addition, inspector parameters are defined in the global file of the verification environment. The inspector parameters include classification parameters, which include at least one classification field, and the at least one classification field is one or more keywords that determine the attribution relationship of the inspector. Based on the inspector parameters defined in the global file, classification parameters are set for the target inspector; the classification parameters of the target inspector are used to classify the inspector report of the target inspector in at least one dimension, wherein a classification field in the classification parameters is used to classify the inspector report of the target inspector in one dimension.

2. The method according to claim 1, characterized in that, The at least one classification field includes at least one of project identifier, environment identifier, and function identifier; wherein, the project identifier indicates the project corresponding to the verification environment in which the inspector is located; the environment identifier indicates the verification environment to which the inspector belongs; and the function identifier indicates the design function of the project and / or the verification environment.

3. The method according to any one of claims 1-2, characterized in that, The target inspector includes a reuse inspector, which is an inspector of an old project reused in the verification environment of a new project, and the new project inherits from the old project; The target inspector in the verification environment includes: Determine the type of reuse inspector in the verification environment; Based on the type of the multiplexing checker, obtain a file list of multiplexing checkers.

4. The method according to claim 3, characterized in that, The step of setting classification parameters for the target inspector based on the inspector parameters defined in the global file includes: Based on the inspector parameters added to the global file, the classification parameters are set for the file content in the file list of the reuse inspector.

5. The method according to claim 4, characterized in that, The step of setting the classification parameters for the file content in the file list of the reuse inspector based on the inspector parameters added in the global file includes: Based on the inspector parameters added to the global file, classification parameters are set for the old format of the reuse inspector to obtain the new format of the reuse inspector; Based on the file list of the multiplexing checker, determine the file and file location corresponding to the checker format of the multiplexing checker; based on the determined file, file location, old format and new format of the multiplexing checker, form the replacement information of the multiplexing checker; After verifying and confirming the replacement information, replace the old format with the new format in the file and file location indicated by the replacement information.

6. The method according to claim 5, characterized in that, The step of setting classification parameters for the old format of the multiplexing checker based on the checker parameters added to the global file to obtain the new format of the multiplexing checker includes: Extract the checker information of the reuse checker from the simulation log. The checker information includes the checker function of the reuse checker. Based on the checker parameters added to the global file, add classification parameters to the original parameters of the checker function to obtain new parameters of the checker function. The classification field in the classification parameter is identified and processed by the internal code of the checker function so that the output information of the checker function carries the classification field. And / or, based on the inspector parameters added to the global file, a classification parameter is added to the original macro definition of the multiplexing inspector to obtain a new macro definition of the multiplexing inspector.

7. The method according to any one of claims 1-2, characterized in that, The target inspector includes a new inspector, which is a new inspector added to the verification environment of the new project relative to the old project. The step of setting classification parameters for the target inspector based on the inspector parameters defined in the global file includes: Based on the inspector parameters added in the global file, when setting parameters for the new inspector, classification parameters are carried in the parameter passing content of the new inspector so that the new inspector has classification parameters.

8. The method according to any one of claims 1-2, characterized in that, Also includes: Determine the type of invalid checker in the verification environment; the invalid checker is one that is no longer applicable to the new project from the old project. Based on the type of the invalid checker, obtain the file list of the invalid checker; Set the contents of the files in the file list of the invalid checker to blank characters.

9. The method according to claim 8, characterized in that, Setting the file content in the file list of the invalid checker to whitespace includes: Based on the file list of the invalid checker, determine the file and file location corresponding to the checker format of the invalid checker; Based on the determined file, file location, the old format of the invalidity checker corresponding to the determined file and file location, and the new format of whitespace characters, replacement information for the invalidity checker is formed. After verifying the replacement information of the invalid checker, the old format of the invalid checker is replaced with the new format of whitespace characters according to the file and file location indicated by the replacement information of the invalid checker.

10. The method according to claim 2, characterized in that, The target inspector includes a reuse inspector and a new inspector; wherein, the classification parameters set in the reuse inspector include an item identifier; The classification parameters set for the newly added inspector include a project identifier and a function identifier; or, the classification parameters set for the newly added inspector include a project identifier, an environment identifier, and a function identifier.

11. A report generation method, characterized in that, include: The design is regressed and validated in the validation environment, and a checker report of the target checker in the validation environment is generated. The target inspector is configured with classification parameters based on the inspector setting method according to any one of claims 1-10; The inspector report is classified in at least one dimension according to at least one classification field included in the classification parameters set by the target inspector, so as to obtain report content in at least one dimension; wherein, a classification field is used to classify the inspector report in one dimension.

12. The method according to claim 11, characterized in that, The classification fields in the classification parameters include project identifier, environment identifier, and function identifier; the process of classifying the inspector report according to at least one dimension based on at least one classification field included in the classification parameters set by the target inspector to obtain report content in at least one dimension includes: Based on the project identifiers of old and new projects in the classification field, the inspector report is classified according to the project dimension to obtain the report content of the target inspector for new and old projects respectively; Based on the environment identifier in the classification field, the report content of the target inspector in the new project is classified according to the verification environment dimension to obtain the report content of the target inspector corresponding to different verification environments in the new project. For the report content of the target inspector in any verification environment of the new project, based on the functional identifier in the classification field, the report content of the target inspector in the verification environment of the new project is classified according to the functional dimension to obtain the report content of the target inspector in each functional dimension of the verification environment of the new project.

13. The method according to claim 12, characterized in that, Also includes: Based on the report content of each functional dimension and the task allocation information, the verification personnel corresponding to the report content of each functional dimension are determined; wherein, the task allocation information records the correspondence between functions and verification personnel, and the correspondence between functions and verification personnel indicates the design functions that the verification personnel should check.

14. The method according to claim 13, characterized in that, Also includes: Based on the inspection results of the report content of each functional dimension, the verification environment and target inspector of the new project are modified until the report content of each functional dimension reaches the convergence condition. After the report content of each functional dimension reaches the convergence condition, for any verification environment of the new project, the report content of each functional dimension in the verification environment of the new project is merged to obtain the summary report content of the target checker in each verification environment of the new project. The summary reports of the target checker in each verification environment of the new project are merged with the reports of the target checker in the old project to obtain the target report content of the target checker in each verification environment.

15. The method according to claim 14, characterized in that, The target report content of the target inspector in each verification environment includes: the target report content of the target inspector in each IP verification environment, the target report content in each subsystem verification environment, and the target report content in the system-level verification environment; The method further includes: The target report content of the target inspector in each IP verification environment is merged to obtain the merged report content of the target inspector at the IP verification environment level. The target report content corresponding to each IP verification environment of the target inspector is merged with the target report content of the target inspector in the subsystem verification environment to obtain the merged report content of the target inspector at the subsystem verification environment level. By utilizing the merged report content of the target inspector at the IP verification environment level and the merged report content of the target inspector at the subsystem verification environment level, regression verification iteration is performed on the subsystem verification environment until the subsystem verification environment reaches a convergence state.

16. The method according to claim 15, characterized in that, Also includes: After the subsystem verification environment reaches a convergence state, the report content of the target checker in the subsystem verification environment is merged with the target report content of the target checker in the system-level verification environment to obtain the merged report content of the target checker at the system-level verification environment level. By utilizing the merged report content of the target inspector at the system-level verification environment level, regression verification iterations are performed on the system-level verification environment until the system-level verification environment reaches a convergent state.

17. An inspection device, characterized in that, include: The target checker determination module is used to determine the target checker in the verification environment, wherein the chip design is verified and simulated in the verification environment to verify whether the chip design meets the design expectations. The parameter definition module is used to define inspector parameters in the global file of the verification environment. The inspector parameters include classification parameters, which include at least one classification field. The at least one classification field is one or more keywords that determine the attribution relationship of the inspector. The parameter setting module is used to set classification parameters for the target inspector based on the inspector parameters defined in the global file; the classification parameters of the target inspector are used to classify the inspector report of the target inspector in at least one dimension, wherein a classification field in the classification parameters is used to classify the inspector report of the target inspector in one dimension.

18. A report generation device, characterized in that, include: The regression verification and report generation module is used to perform regression verification on the design in the verification environment and generate a checker report for the target checker in the verification environment. The target inspector is configured with classification parameters based on the inspector setting method according to any one of claims 1-10; A classification module is used to classify the inspector report in at least one dimension according to at least one classification field included in the classification parameters set by the target inspector, so as to obtain report content in at least one dimension; wherein, a classification field is used to classify the inspector report in one dimension.

19. A computer device, characterized in that, It includes at least one memory and at least one processor, the memory storing one or more computer-executable instructions, the processor invoking the one or more computer-executable instructions to perform the checker setup method as described in any one of claims 1-10, and / or the report generation method as described in any one of claims 11-16.

20. A storage medium, characterized in that, The storage medium stores one or more computer-executable instructions, which, when executed, implement the checker setting method as described in any one of claims 1-10, and / or the report generation method as described in any one of claims 11-16.

Images