Chip verification coverage data processing method, device and equipment and storage medium

Abstract

Embodiments of the present application provide a chip verification coverage data processing method, device and equipment and a storage medium. The method comprises: obtaining preset configuration information and preset code repository access authority, the configuration information containing coverage parameters and simulation parameters; detecting the latest version code by a code repository version label, and updating a coverage substrate based on the latest version code; executing a plurality of module simulation tasks based on the latest version code and the configuration information, generating a coverage database and storing it in a preset path; merging the coverage substrate and the coverage database in the preset path to obtain a global coverage database; storing the global coverage database and generating a coverage data report. The method is used to achieve the effects of automatically synchronizing code versions and coverage data, improving data updating timeliness and accuracy, reducing version inconsistency problems caused by manual operation, and ensuring the reliability of verification analysis data.

Description

Technical Field

[0001] This application relates to the field of hardware design, and in particular to a chip verification coverage data processing method, apparatus, device and storage medium. Background Technology

[0002] With the continuous expansion of integrated circuit scale and the increasing complexity of designs, coverage data, as a core indicator for measuring the adequacy and completeness of verification, is collected and managed throughout the entire lifecycle of simulation verification. Coverage data encompasses multiple dimensions, including code coverage, functional coverage, and scenario coverage, objectively reflecting whether the design logic has been fully executed and whether the functional scenarios have been completely covered. This data plays a crucial role in locating design defects and analyzing verification progress.

[0003] In existing technical solutions, the collection and management of coverage data primarily rely on manually driven processes. Validation engineers need to configure simulation parameters and coverage collection rules for different modules or subsystems, manually triggering simulation tasks to generate a fragmented coverage database. Engineers then need to manually identify and merge these fragmented databases using scripts or tools, based on code version information, to form a global coverage view. During the merging process, relevant analysis files must be manually loaded to remove invalid coverage points. Furthermore, to ensure data timeliness, the validation team needs to periodically repeat the entire process of parameter configuration, simulation triggering, data merging, and result analysis.

[0004] The existing coverage data management process lacks a unified automated control mechanism, resulting in delayed data updates, inability to guarantee version consistency, and a high rate of data errors caused by human operation. As a result, the overall management efficiency is difficult to match the progress requirements of large-scale chip verification. Summary of the Invention

[0005] This application provides a chip verification coverage data processing method, apparatus, device, and storage medium to improve the timeliness and accuracy of data updates.

[0006] In a first aspect, embodiments of this application provide a chip verification coverage data processing method, including:

[0007] Obtain preset configuration information and access permissions to preset code repositories, wherein the configuration information includes coverage parameters and simulation parameters;

[0008] The version tags of the code repository are detected to obtain the latest version of the code, and the coverage base plate is updated based on the latest version of the code;

[0009] Based on the latest version code and the configuration information, the simulation tasks of multiple modules are executed to generate a coverage database and store it in a preset path;

[0010] The coverage substrate and the coverage database in the preset path are merged from multiple data sources to obtain a global coverage database.

[0011] The global coverage database is stored and a coverage data report is generated.

[0012] In one possible implementation, based on the latest version code and the configuration information, simulation tasks for multiple modules are executed to generate a coverage database and store it in a preset path, including:

[0013] The coverage filtering rules and simulation duration parameters in the configuration information are parsed using a preset script;

[0014] The coverage filtering rules and simulation duration parameters are mapped to the simulation execution scripts of multiple modules;

[0015] Load the latest version of the code into the simulation execution environment corresponding to each module;

[0016] Run the simulation execution script and perform simulation verification on the module in the simulation execution environment to obtain the coverage point execution data corresponding to each module;

[0017] The coverage point execution data is encapsulated based on preset database generation rules to obtain a coverage database;

[0018] The coverage database of each module is stored in the specified storage location according to the preset path rules.

[0019] In one possible implementation, mapping the coverage filtering rules and simulation duration parameters to simulation execution scripts of multiple modules includes:

[0020] Extract the unique identifier information corresponding to each module in the configuration information;

[0021] Establish a mapping table between the unique identifier information and the corresponding parsed coverage filtering rules and simulation duration parameters;

[0022] Based on the mapping table, the corresponding coverage filtering rules and simulation duration parameters are written into the preset parameter configuration area of ​​the simulation execution script of each module.

[0023] In one possible implementation, the coverage substrate and the coverage database in the preset path are merged from multiple data sources to obtain a global coverage database, including:

[0024] Get the preset incremental merging rules;

[0025] Based on the preset incremental merging rules, databases to be updated are selected from the coverage database;

[0026] The database to be updated is merged with the coverage substrate to obtain a global coverage database.

[0027] In one possible implementation, it also includes:

[0028] Obtain the preset metadata verification rules;

[0029] The merged database is subjected to integrity verification according to the preset metadata verification rules, and the verification result is obtained.

[0030] The global coverage database is corrected based on the verification results.

[0031] In one possible implementation, selecting databases to be updated from the coverage database based on the incremental merge rules includes:

[0032] Obtain the first version identifier of the coverage database for each module;

[0033] Compare the first version identifier with the second version identifier of the coverage substrate;

[0034] The coverage databases whose first version identifier and second version identifier do not match are selected as the databases to be updated.

[0035] In one possible implementation, it also includes:

[0036] Obtain the preset exemption file storage path and preset exemption rules;

[0037] Read at least one exemption file from the preset exemption file storage path;

[0038] The exemption conditions for the coverage points are obtained by parsing the exemption file.

[0039] The coverage point data in the global coverage database is matched according to the coverage point exemption conditions to obtain the matching results;

[0040] The global coverage database is corrected based on the matching results to generate a corrected coverage database.

[0041] Secondly, embodiments of this application provide a chip verification coverage data processing apparatus, comprising:

[0042] The acquisition module is used to acquire preset configuration information and access permissions to preset code repositories. The configuration information includes coverage parameters and simulation parameters.

[0043] The detection module is used to detect the version tags of the code repository to obtain the latest version of the code, and update the coverage baseboard based on the latest version of the code;

[0044] The simulation module is used to execute simulation tasks of multiple modules based on the latest version of the code and the configuration information, generate a coverage database and store it in a preset path;

[0045] The merging module is used to merge the coverage substrate and the coverage database in the preset path into a global coverage database by merging multiple data sources.

[0046] The generation module is used to store the global coverage database and generate coverage data reports.

[0047] In one possible implementation, the simulation module is specifically used for:

[0048] The coverage filtering rules and simulation duration parameters in the configuration information are parsed using a preset script;

[0049] The coverage filtering rules and simulation duration parameters are mapped to the simulation execution scripts of multiple modules;

[0050] Load the latest version of the code into the simulation execution environment corresponding to each module;

[0051] Run the simulation execution script and perform simulation verification on the module in the simulation execution environment to obtain the coverage point execution data corresponding to each module;

[0052] The coverage point execution data is encapsulated based on preset database generation rules to obtain a coverage database;

[0053] The coverage database of each module is stored in the specified storage location according to the preset path rules.

[0054] In one possible implementation, the simulation module is further configured to:

[0055] Extract the unique identifier information corresponding to each module in the configuration information;

[0056] Establish a mapping table between the unique identifier information and the corresponding parsed coverage filtering rules and simulation duration parameters;

[0057] Based on the mapping table, the corresponding coverage filtering rules and simulation duration parameters are written into the preset parameter configuration area of ​​the simulation execution script of each module.

[0058] In one possible implementation, the merging module is specifically used for:

[0059] Get the preset incremental merging rules;

[0060] Based on the preset incremental merging rules, databases to be updated are selected from the coverage database;

[0061] The database to be updated is merged with the coverage substrate to obtain a global coverage database.

[0062] In one possible implementation, the merging module is further configured to:

[0063] Obtain the preset metadata verification rules;

[0064] The merged database is subjected to integrity verification according to the preset metadata verification rules, and the verification result is obtained.

[0065] The global coverage database is corrected based on the verification results.

[0066] In one possible implementation, the merging module is further configured to:

[0067] Obtain the first version identifier of the coverage database for each module;

[0068] Compare the first version identifier with the second version identifier of the coverage substrate;

[0069] The coverage databases whose first version identifier and second version identifier do not match are selected as the databases to be updated.

[0070] In one possible implementation, a correction module is further included, the correction module being specifically used for:

[0071] Obtain the preset exemption file storage path and preset exemption rules;

[0072] Read at least one exemption file from the preset exemption file storage path;

[0073] The exemption conditions for the coverage points are obtained by parsing the exemption file.

[0074] The coverage point data in the global coverage database is matched according to the coverage point exemption conditions to obtain the matching results;

[0075] The global coverage database is corrected based on the matching results to generate a corrected coverage database.

[0076] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0077] The memory stores computer-executed instructions;

[0078] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0079] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0080] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0081] In a sixth aspect, embodiments of this application provide a chip, the chip including at least one processor, the processor being configured to execute program instructions to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0082] The chip verification coverage data processing method, apparatus, device, and storage medium provided in this application embodiment obtain the latest version of the code by detecting the code repository version tag and update the coverage substrate. Based on the latest version of the code and configuration information, multiple module simulation tasks are executed to generate a coverage database. The coverage substrate and the coverage database are merged from multiple data sources to obtain a global coverage database. This achieves the effects of automatic synchronization of coverage data and code version, improving the timeliness and accuracy of data updates, reducing version inconsistency caused by manual operation, and ensuring the reliability of verification analysis data. Attached Figure Description

[0083] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0084] Figure 1 A schematic diagram illustrating the application scenario of the chip verification coverage data processing method provided in this application embodiment;

[0085] Figure 2 A flowchart illustrating the chip verification coverage data processing method provided in this application embodiment;

[0086] Figure 3 A schematic diagram of the chip verification coverage data processing device provided in this application embodiment;

[0087] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0088] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0089] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0090] In existing technologies, manually configuring simulation parameters, manually triggering simulation tasks, and manually merging coverage databases present technical problems such as coverage data being out of sync with code version updates, data updates being delayed, and the susceptibility to human error.

[0091] The chip verification coverage data processing method provided in this application solves the technical problems of coverage data being out of sync with code version and data updates not being timely by automatically detecting code repository version tags to update the coverage substrate, executing simulation tasks based on the latest version of the code to generate a coverage database, and then merging the coverage substrate with multiple coverage databases.

[0092] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0093] Figure 1 This is a schematic diagram illustrating an application scenario of the chip verification coverage data processing method provided in the embodiments of this application, such as... Figure 1 As shown, it includes: terminal 101 and server 102.

[0094] Terminal 101 is used to send preset configuration information and preset code repository access permissions to server 102, and to receive coverage data reports returned by server 102.

[0095] Server 102 is used to receive information sent by terminal 101, detect the code repository version tag to obtain the latest version code and update the coverage substrate, execute multiple module simulation tasks based on the latest version code and configuration information to generate a coverage database, merge the coverage substrate and the coverage database to obtain a global coverage database, store the global coverage database and generate a coverage data report to return to terminal 101.

[0096] Figure 2 This is a flowchart illustrating the chip verification coverage data processing method provided in this application embodiment. The execution entity in this embodiment can be... Figure 1 The server 102 in the illustrated embodiment can also be other computer-related devices, and this embodiment is not particularly limited. This method can also be applied to terminal devices, base stations, or chips or chip modules in terminal devices / base stations. By automatically synchronizing code versions and coverage data, improving the timeliness of data updates, and reducing human error, the reliability of verification data is improved.

[0097] like Figure 2 As shown, the chip verification coverage data processing method includes the following steps:

[0098] Step S201: Obtain the preset configuration information and access permissions to the preset code repository. The configuration information includes coverage parameters and simulation parameters.

[0099] Specifically, the configuration information is a pre-set set of parameters used to guide the execution of simulation tasks, including coverage parameters and simulation parameters; coverage parameters are used to define coverage collection rules, including coverage filtering rules; simulation parameters are used to define simulation execution conditions, including simulation duration parameters; and the code repository refers to the system used to store and manage chip design code versions.

[0100] By reading pre-stored configuration files, coverage and simulation parameters are obtained, and access permissions are requested from the code repository system. A pre-defined mechanism centrally manages scattered configuration items, and a secure connection to the code repository is established through permission verification. This prepares the foundational data for subsequent automated processes, provides a unified input standard for the entire coverage data management process, and ensures consistency between coverage collection rules and simulation environment configuration. It avoids the inconsistencies caused by manually configuring parameters module by module, laying a data foundation for subsequent automated execution.

[0101] Step S202: Detect the version tags of the code repository to obtain the latest version of the code, and update the coverage baseboard based on the latest version of the code.

[0102] Specifically, version tags are markers in the code repository used to identify specific code versions; the coverage baseboard is a coverage data infrastructure built on specific code versions, serving as the merging benchmark. By periodically accessing the code repository, comparing the current version tags with historical records, if an update is detected, the latest version of the code is extracted, and the coverage baseboard is regenerated based on this code.

[0103] By automatically identifying code changes through version tag comparison and using the latest code to build a baseline database, the reference for coverage analysis is always the latest design. By establishing a binding relationship between coverage data and code version, the analysis bias caused by version lag is eliminated, ensuring that the coverage database generated subsequently is based on the latest code version and preventing version disconnect.

[0104] Step S203: Based on the latest version of the code and configuration information, execute simulation tasks for multiple modules, generate a coverage database, and store it in a preset path.

[0105] Specifically, the preset path is a pre-defined file system location for storing the coverage database. By loading the latest version of the code into the simulation environment and starting parallel simulation tasks for multiple modules according to the parameters in the configuration information, coverage point data during the simulation process is collected, and a database file is generated according to a preset format. Using unified parameter configuration and scripted execution, multiple modules are simultaneously simulated and verified, coverage point execution data is collected and encapsulated into a standard database format. While ensuring code version consistency, the original coverage data for each module is efficiently generated, achieving automated parallel execution of simulation tasks, significantly improving data generation efficiency, and ensuring that all modules have consistent data formats and standardized paths.

[0106] Step S204: Merge the coverage substrate and the coverage database in the preset path using multiple data sources to obtain a global coverage database.

[0107] Specifically, the global coverage database is a complete database containing coverage information for all modules, obtained by merging multiple data sources. By identifying the coverage databases of all modules in the preset path, the version identifier of each database is obtained, compared with the coverage base plate, and the databases that need to be updated are selected for merging.

[0108] The incremental merging algorithm only merges databases with version mismatches, avoiding duplicate processing of unchanged module data. Metadata verification ensures the integrity of the merge results. By integrating scattered module-level data, a system-level global view is formed, providing a data foundation for comprehensive analysis and verification of progress. While ensuring merging efficiency, the integrity and accuracy of data in the global database are guaranteed, avoiding the resource waste caused by full merging.

[0109] In some optional implementations, the process of obtaining the multi-source coverage database further includes: checking a preset dedicated list, which records special data paths that need to be merged separately; when an update is detected in a path in the list, automatically capturing the coverage data under that path and including it in the set of data sources to be merged. This approach allows for flexible handling of coverage data from special modules with non-fixed outputs or provided by external collaborators, ensuring that all relevant data sources are merged in a timely manner, further improving the integrity of the global coverage database.

[0110] Step S205: Store the global coverage database and generate a coverage data report.

[0111] Specifically, the coverage data report is a document generated based on the global coverage database to display the coverage analysis results. The merged global coverage database is stored in a specified location, and key coverage point information is extracted to generate a structured report according to a preset report template.

[0112] By transforming complex coverage data into an easy-to-understand document format, it facilitates review and analysis by the verification team, provides designers with intuitive feedback on verification progress, supports subsequent defect localization and verification completeness analysis, enables visualized output of coverage data, shortens the data analysis cycle, and improves team collaboration efficiency.

[0113] The chip verification coverage data processing method provided in this invention automatically detects the code version and updates the coverage substrate, executes simulation tasks in parallel based on the latest code, and performs incremental merging and verification of multi-source coverage databases. This achieves automatic synchronization between coverage data and code version, improves the timeliness and accuracy of data updates, reduces the risk of version inconsistency caused by manual operation, and ensures the reliability of the data on which verification analysis is based.

[0114] In some optional implementations, the execution of the above-described chip verification coverage data processing method can be automatically triggered based on a preset scheduled task configuration. By acquiring the timing rules, the entire process from configuration acquisition to report generation is automatically started when a specified time point is reached, achieving daily or periodic automated operation. In this way, regular updates of coverage data can be guaranteed without manual intervention, significantly improving data timeliness and meeting the needs of rapid iteration.

[0115] This embodiment details the process described in the above embodiment of executing simulation tasks of multiple modules based on the latest version of the code and configuration information, generating a coverage database, and storing it to a preset path. The specific implementation of this process includes the following steps:

[0116] Step a1: Parse the coverage filtering rules and simulation duration parameters in the configuration information using a preset script.

[0117] Specifically, the preset script is a pre-written executable program used to automate parameter parsing and task distribution; the coverage filtering rules are a set of rules used to specify which coverage points need to be collected or excluded; and the simulation duration parameter refers to the configuration parameter used to control the execution time of the simulation task. By calling the pre-written parsing script to read the configuration information file, the coverage filtering rules and simulation duration parameters are extracted from it, and these parameters are converted into an internally recognizable instruction format.

[0118] By performing syntactic analysis on structured configuration data, human-readable rules are transformed into a set of machine-executable parameters. Key parameters are separated from the unified configuration information, providing precise control conditions for subsequent simulation tasks. This ensures that all modules use consistent rules and durations, avoiding rule omissions or parameter errors caused by manual configuration.

[0119] Step a2: Map the coverage filtering rules and simulation duration parameters to the simulation execution scripts of multiple modules.

[0120] Specifically, a simulation execution script refers to an executable script file used to drive simulation tools to perform simulation tasks. Based on the unique identifier information of each module, the parsed parameters are dynamically injected into the simulation execution script template corresponding to each module, forming a customized script version.

[0121] By using parameterized script templates, global parameters are combined with module-specific requirements, enabling precise parameter distribution. This allows each module's simulation script to carry coverage collection rules and simulation duration suitable for that module, ensuring the consistency of simulation tasks and module independence. It also effectively simplifies script maintenance and improves the flexibility and accuracy of parameter configuration.

[0122] Step a3: Load the latest version of the code into the simulation execution environment corresponding to each module.

[0123] Specifically, the simulation execution environment is the set of software and hardware environments required to run simulation tasks. By obtaining the latest version of code from the code repository, deploying the code files to the simulation working directories of each module according to module division, and setting environment variables to point to this code, the code resources are associated with the simulation execution environment through file system operations and environment variable settings. This ensures that the simulation of each module is based on the same code version, laying the foundation for the comparability and merging of subsequent simulation results, eliminating simulation result deviations caused by inconsistent code versions, and ensuring that coverage data reflects the latest design state.

[0124] Step a4: Run the simulation execution script and perform simulation verification on the module in the simulation execution environment to obtain the execution data of the coverage points corresponding to each module.

[0125] Specifically, coverage point execution data is raw data recorded during the simulation process that reflects the triggering status of coverage points. By starting the simulation process of each module and executing its corresponding simulation script, the simulation tool dynamically records the triggering status of coverage points during the simulation process, generating raw coverage point data. By executing simulation tasks of multiple modules, data generation efficiency is improved while ensuring the integrity of data acquisition.

[0126] Step a5: Based on the preset database generation rules, encapsulate the coverage point execution data to obtain the coverage database.

[0127] Specifically, database generation rules are used to encapsulate coverage point execution data into a standard database format. The raw coverage point data generated during simulation is organized, compressed, and indexed according to a preset database format to form a standardized coverage database file; the scattered coverage point information is stored in a structured manner, transforming the raw simulation data into a reusable coverage database that supports version management and multi-source merging. By unifying the data format, data portability and subsequent processing efficiency are improved.

[0128] Step a6: Store the coverage database of each module to the specified storage location according to the preset path rules.

[0129] Specifically, following preset path naming rules, the coverage database files generated by each module are moved or copied to the specified directory structure, and the storage path is recorded. Through file system operations and path mapping, the generated database files are archived to a centrally managed storage area, centrally managing the coverage data of all modules. This provides a clear access path for subsequent multi-data source merging, ensuring orderly data storage and traceability, and avoiding data loss or path confusion.

[0130] This invention parses configuration parameters using a preset script and maps them to a module simulation script, loads the latest code to execute the simulation, collects coverage point data and encapsulates it into a database, and finally stores it according to rules. This achieves automated execution of simulation tasks and standardized data generation, improves the accuracy of parameter configuration, ensures code version consistency, and enhances the efficiency and reliability of data generation.

[0131] In some optional implementations, step a2 above specifically includes:

[0132] Step a21: Extract the unique identifier information corresponding to each module in the configuration information.

[0133] Specifically, unique identifier information refers to the characteristic information used to distinguish different modules, such as module number or name. By parsing the module list from the configuration information, the unique identifier information corresponding to each module is extracted. Through data parsing, key fields used to distinguish different modules are separated from the structured configuration data to form an identifier set. This provides an accurate index basis for subsequent parameter allocation, ensuring that each module can be uniquely identified, guaranteeing the accuracy of subsequent parameter mapping, and avoiding configuration errors caused by identifier confusion.

[0134] Step a22: Establish a mapping table between unique identifier information and corresponding parsed coverage filtering rules and simulation duration parameters.

[0135] Specifically, the mapping table is a data structure that establishes the correspondence between module identifiers and configuration parameters. The extracted unique module identifiers are associated with the parsed coverage filtering rules and simulation duration parameters to construct a key-value mapping table. Using the module identifier as the key and the corresponding parameter as the value, a quickly searchable correspondence is formed, clearly defining the specific parameters that each module should use. This provides a precise reference for parameter writing, ensuring the correspondence between parameters and modules and guaranteeing the logical correctness of subsequent parameter allocation.

[0136] Step a23: Based on the mapping relationship table, write the corresponding coverage filtering rules and simulation duration parameters into the preset parameter configuration area of ​​the simulation execution script of each module.

[0137] Specifically, the preset parameter configuration area is a specific location reserved in the simulation execution script for writing configuration parameters. By traversing the mapping table, the corresponding simulation execution script file is located according to the module identifier, and the parameter values ​​stored in the table are written into the preset parameter configuration area in the script.

[0138] By using file read / write and string replacement operations, parameter values ​​are dynamically injected into specified locations in the script template to generate customized scripts. Global parameters are specified into the simulation scripts of each module, enabling the scripts to carry the exclusive parameters required by that module, completing the automated configuration of parameters, reducing the workload of manual script editing, and avoiding parameter omissions or errors.

[0139] This invention achieves precise matching and automated configuration of parameters and modules by extracting module identifiers, constructing a mapping table, and writing parameters into the preset configuration area of ​​the script. This improves the accuracy and efficiency of parameter allocation and ensures the consistency and reliability of the simulation script configuration for each module.

[0140] This embodiment provides a detailed description of the process in the above embodiment of merging multiple data sources, including the coverage substrate and the coverage database in the preset path, to obtain a global coverage database. The specific implementation of this process includes the following steps:

[0141] Step b1: Obtain the preset incremental merging rules.

[0142] Specifically, incremental merge rules refer to the judgment rules used to determine which coverage databases need to participate in the merge, including version-based comparison rules. By reading the pre-stored incremental merge rule configuration file, the version comparison strategy, merge priority, and other rule content defined within it are parsed and loaded into memory for subsequent steps. Parameterizing the merge logic makes the merge behavior customizable and reusable, providing clear judgment criteria for subsequently selecting databases to be updated. This ensures that the merge operation follows a unified logic, guarantees the consistency and controllability of the merge process, and avoids merge errors or omissions caused by unclear rules.

[0143] Step b2: Select the databases to be updated from the coverage database based on the preset incremental merging rules.

[0144] Specifically, the databases to be updated are coverage databases that need to be merged with the coverage baseboard, selected according to incremental merging rules. By traversing the coverage databases of each module stored in the preset path, the version identifier of each database is obtained and compared with the version identifier of the coverage baseboard. Based on the incremental merging rules, it is determined which databases are outdated or have differences, and these are marked as databases to be updated. The version identifier comparison technology is used to identify the differences between the data source and the benchmark, and only databases with inconsistent versions are selected for subsequent processing. This accurately identifies the data sources that need to be merged, avoids repeated merging of databases of unchanged modules, significantly reduces the amount of input data for the merging operation, reduces computing resource consumption, and improves merging efficiency.

[0145] Step b3: Merge the database to be updated with the coverage baseboard to obtain the global coverage database.

[0146] Specifically, the selected databases to be updated are merged with the coverage baseboard in sequence. The coverage merging tool integrates the coverage point information from multiple databases to generate a global coverage database containing all coverage point data.

[0147] By aggregating scattered coverage point data to form a unified system-level coverage view, and integrating coverage information of each module, a complete data foundation is provided for overall verification progress analysis and defect localization. This results in a global database that accurately reflects the coverage of all modules, ensuring the comprehensiveness and reliability of subsequent analysis results.

[0148] This invention achieves efficient and accurate multi-source data merging by acquiring incremental merging rules, filtering the database to be updated based on the rules, and merging only the difference data with the substrate. This avoids the redundant operation of full merging, significantly improves merging efficiency, and ensures the accuracy and integrity of the global coverage database.

[0149] In some optional implementations, the specific implementation of the method in the above embodiments further includes the following steps:

[0150] Step c1: Obtain the preset metadata verification rules.

[0151] Specifically, metadata verification rules are the criteria used to check the integrity of the merged database. By reading the pre-set metadata verification rules from the configuration storage system, the metadata verification rules include, according to actual needs, the integrity threshold of coverage points, data type consistency requirements, and verification standards for coverage point associations.

[0152] By parameterizing the verification logic, the verification process can be flexibly adjusted according to different needs, ensuring the applicability of the verification standard, providing a clear judgment basis for subsequent integrity verification, unifying the verification execution standard, ensuring the standardization and repeatability of the verification process, and avoiding subjective bias introduced by human judgment.

[0153] Step c2: Perform integrity verification on the merged database according to the preset metadata verification rules, and obtain the verification result.

[0154] Specifically, the metadata information in the merged database is parsed, including the total number of coverage points, the distribution of coverage point types, and the relationship between coverage points. This information is then compared item by item with the preset metadata verification rules to identify problems such as missing coverage points, abnormal data formats, or broken relationships, and to generate verification results that include information on the type and location of the anomalies.

[0155] By using metadata parsing and rule matching technology, the internal structure of the database is automatically checked to discover potential data quality issues, verify the data integrity and logical consistency of the merged database, ensure that it meets the quality requirements of subsequent analysis, automatically identify errors or omissions that may be introduced during the data merging process, provide accurate location information for data correction, and avoid drawing incorrect analytical conclusions based on incomplete data.

[0156] Step c3: Correct the global coverage database based on the verification results.

[0157] Specifically, based on the anomaly type and location identified in the verification results, corresponding correction operations are performed, including re-extracting missing coverage points from the original database, adjusting data format, repairing relationships, or removing invalid data, ultimately generating a corrected global coverage database.

[0158] By performing targeted corrections on various issues discovered during verification, the integrity and correctness of the data are restored, data defects introduced during the merging process are eliminated, the quality of the global coverage database is improved, and a high-quality, high-reliability global coverage database is obtained, ensuring the accuracy and reliability of subsequent verification analysis results.

[0159] This invention achieves automated quality assurance of merged data by acquiring preset metadata verification rules, performing integrity verification on the merged database, and correcting the database based on the verification results. It effectively identifies and repairs data defects, improves the integrity and accuracy of the global coverage database, and provides a reliable data foundation for subsequent verification and analysis.

[0160] This embodiment provides a detailed description of the process in the above embodiment of selecting the database to be updated from the coverage database based on the incremental merge rule. The specific implementation of this process includes the following steps:

[0161] Step d1: Obtain the first version identifier of the coverage database for each module.

[0162] Specifically, the version identifier is used to represent the characteristic information of the code version corresponding to the coverage database. By traversing the coverage database files of each module stored in the preset path, the version identifier field is extracted from the header information or metadata area of ​​each database to obtain the first version identifier representing the code version of the database.

[0163] Based on the standard storage format of database files, version information is obtained by parsing metadata. The version identifier is usually associated with the code version tag used when the database was generated, providing a data foundation for subsequent version comparison, clarifying the version status of each module database, accurately obtaining the version information of each module database, and ensuring that version comparison has a reliable basis.

[0164] Step d2: Compare the first version identifier with the second version identifier of the coverage substrate.

[0165] Specifically, the first version identifier of each module's database is compared one by one with the second version identifier of the coverage substrate to determine if they match, and the comparison results are recorded. The comparison process can employ string or numerical comparison algorithms, using precise matching of version identifiers to determine if the versions are the same. Version identifiers typically correspond to code repository tags. This accurately identifies which module's database version differs from the substrate version, quickly completing version comparisons for all module databases and pinpointing the targets that need updating.

[0166] Step d3: Filter out the coverage databases where the first version identifier and the second version identifier do not match, and use them as the databases to be updated.

[0167] Specifically, based on the comparison results, all module databases whose first version identifiers do not match their second version identifiers are filtered out to form a list of databases to be updated. The filtering process is based on conditional filtering logic, retaining only databases with mismatched versions, while databases with matching versions are skipped in subsequent merge operations; the data sources that need to participate in the merge are determined, enabling incremental merge data preparation, accurately identifying the databases to be updated, avoiding duplicate processing of unchanged module data, and improving merge efficiency.

[0168] This invention achieves incremental filtering based on version differences by obtaining the module database version identifier and comparing it with the baseboard version identifier, and filtering out databases with mismatched versions as objects to be updated. This effectively reduces the amount of data to be merged, improves the efficiency and accuracy of the merging process, and ensures that the merging operation only applies to modules that have actually changed.

[0169] In some optional specific embodiments, the specific implementation of the method in the above embodiments further includes the following steps:

[0170] Step e1: Obtain the preset exemption file storage path and preset exemption rules.

[0171] Specifically, the exemption file is the file that stores the exemption conditions for the coverage point; the exemption rule is the rule used to define the parsing method and matching logic of the exemption conditions; by reading the pre-set storage path of the exemption file from the system configuration parameters, and at the same time obtaining the preset exemption rule, the rule defines the parsing method and matching logic of the exemption conditions.

[0172] By centrally storing and retrieving exemption-related parameters, it ensures that subsequent processes can accurately locate exemption files and follow unified processing rules. This provides input parameters and operational basis for the exemption processing process, clarifies data sources and processing standards, guarantees the configurability and consistency of the exemption processing process, and avoids processing failures caused by incorrect paths or unclear rules.

[0173] Step e2: Read at least one exemption file from the preset exemption file storage path.

[0174] Specifically, the system accesses the preset exemption file storage path, scans the file list under that path, reads one or more exemption files stored therein, and loads the file content into memory for processing.

[0175] By reading file data from a specified directory, it supports batch reading of multiple exemption files to meet the needs of multiple modules or multiple exemptions, obtains the stored exemption data source, provides raw input for subsequent parsing, realizes automatic loading of exemption files without manual intervention, and improves processing efficiency.

[0176] Step e3: Obtain the coverage point exemption conditions by parsing the exemption file.

[0177] Specifically, the coverage point exemption conditions are the conditions used to identify which coverage points should be excluded. By parsing the loaded exemption file, the coverage point exemption conditions defined in the file are extracted, including the exemption coverage point identifier, exemption reason, validity period, and other information, forming a structured set of exemption conditions.

[0178] By parsing and extracting exemption conditions that can be used for matching from the original file, the process of converting the file into data transforms human-readable exemption rules into machine-recognizable structured data, facilitating subsequent automated matching, accurately parsing the content of the exemption file, and ensuring the integrity and usability of the exemption conditions.

[0179] Step e4: Match the coverage point data in the global coverage database according to the coverage point exemption conditions to obtain the matching results.

[0180] Specifically, the matching result is the correspondence information obtained by comparing the coverage point data with the exemption conditions. By traversing the coverage point data in the global coverage database, each coverage point is compared with the obtained set of exemption conditions to identify the coverage points that match the exemption conditions, and the matching relationship is recorded to form the matching result.

[0181] By matching data, the coverage points in the database are associated with the exemption conditions to determine which coverage points should be exempted, locate the coverage points that need to be excluded from the coverage statistics, accurately identify exempted coverage points, avoid omissions or incorrect matches, ensure the accuracy of exemption processing, and provide a basis for subsequent corrections.

[0182] Step e5: Based on the matching results, the global coverage database is corrected to generate a corrected coverage database.

[0183] Specifically, based on the matching results, coverage points in the global coverage database that match the exemption conditions are marked or removed, coverage statistics are adjusted, and a revised coverage database without exempted coverage points is regenerated. Through data correction, the original data is selectively filtered based on the matching results to generate a database reflecting the true coverage situation after exemption; points that do not need coverage due to design intent or verification limitations are effectively excluded, resulting in coverage data that better meets actual verification needs. This generates a revised database that accurately reflects effective coverage, providing a reliable basis for verification progress analysis and avoiding misjudgments caused by unnecessary coverage points.

[0184] This invention achieves automated exemption processing by obtaining the exemption file path and rules, reading and parsing the exemption file to obtain the exemption conditions, and matching and correcting the global database. This effectively eliminates unnecessary coverage points and improves the accuracy of coverage data and the reliability of analysis results.

[0185] Figure 3 This is a schematic diagram of the chip verification coverage data processing device provided in an embodiment of this application. Figure 3 As shown, the chip verification coverage data processing device 30 includes:

[0186] The acquisition module 301 is used to acquire preset configuration information and access permissions to preset code repositories. The configuration information includes coverage parameters and simulation parameters.

[0187] The detection module 302 is used to detect the version tags of the code repository to obtain the latest version of the code, and update the coverage base plate based on the latest version of the code;

[0188] Simulation module 303 is used to execute simulation tasks of multiple modules based on the latest version of the code and configuration information, generate a coverage database and store it to a preset path;

[0189] The merging module 304 is used to merge the coverage base plate and the coverage database in the preset path into a global coverage database by multiple data sources.

[0190] The generation module 305 is used to store the global coverage database and generate coverage data reports.

[0191] In one possible implementation, simulation module 303 is specifically used for:

[0192] The coverage filtering rules and simulation duration parameters in the configuration information are parsed using a preset script;

[0193] Map coverage filtering rules and simulation duration parameters to simulation execution scripts of multiple modules;

[0194] Load the latest version of the code into the simulation execution environment corresponding to each module;

[0195] Run the simulation execution script and perform simulation verification on the modules in the simulation execution environment to obtain the execution data of the coverage points corresponding to each module;

[0196] Based on preset database generation rules, the execution data of the coverage points is encapsulated to obtain a coverage database;

[0197] The coverage database of each module is stored in the specified storage location according to the preset path rules.

[0198] In one possible implementation, the simulation module 303 is further configured to:

[0199] Extract the unique identifier information corresponding to each module in the configuration information;

[0200] Establish a mapping table between unique identifier information and corresponding parsed coverage filtering rules and simulation duration parameters;

[0201] Based on the mapping table, the corresponding coverage filtering rules and simulation duration parameters are written into the preset parameter configuration area of ​​the simulation execution script of each module.

[0202] In one possible implementation, the merging module 304 is specifically used for:

[0203] Get the preset incremental merging rules;

[0204] Databases to be updated are selected from the coverage database based on preset incremental merging rules;

[0205] The database to be updated is merged with the coverage baseboard to obtain the global coverage database.

[0206] In one possible implementation, the merging module 304 is further configured to:

[0207] Obtain the preset metadata verification rules;

[0208] The merged database is subjected to integrity verification according to the preset metadata verification rules, and the verification results are obtained.

[0209] The global coverage database is corrected based on the verification results.

[0210] In one possible implementation, the merging module 304 is further configured to:

[0211] Obtain the first version identifier of the coverage database for each module;

[0212] Compare the first version identifier with the second version identifier of the coverage substrate;

[0213] The coverage databases whose first version identifier and second version identifier do not match are selected as the databases to be updated.

[0214] In one possible implementation, a correction module 306 is further included, which is specifically used for:

[0215] Obtain the preset exemption file storage path and preset exemption rules;

[0216] Read at least one exemption file from the preset exemption file storage path;

[0217] The exemption conditions for coverage points are obtained by parsing the exemption file;

[0218] The coverage point data in the global coverage database is matched according to the coverage point exemption conditions to obtain the matching results;

[0219] The global coverage database is corrected based on the matching results, resulting in a corrected coverage database.

[0220] The chip verification coverage data processing device provided in this embodiment can be used to execute the chip verification coverage data processing method described above. Its implementation principle and technical effect are similar, and will not be described again in this embodiment.

[0221] Figure 4 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application, such as... Figure 4 As shown, the electronic device 40 includes at least one processor 401 and a memory 402. Optionally, the electronic device 40 also includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0222] In the specific implementation process, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above method.

[0223] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0224] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0225] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0226] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0227] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0228] This application also provides a chip, which includes at least one processor for executing program instructions to perform the methods described above.

[0229] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0230] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0231] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0232] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0233] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0234] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0235] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0236] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0237] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for processing chip verification coverage data, characterized in that, include: Obtain preset configuration information and access permissions to preset code repositories, wherein the configuration information includes coverage parameters and simulation parameters; The version tags of the code repository are detected to obtain the latest version of the code, and the coverage base plate is updated based on the latest version of the code; Based on the latest version code and the configuration information, the simulation tasks of multiple modules are executed to generate a coverage database and store it in a preset path; The coverage substrate and the coverage database in the preset path are merged from multiple data sources to obtain a global coverage database. The global coverage database is stored and a coverage data report is generated.

2. The method according to claim 1, characterized in that, Based on the latest version code and the configuration information, simulation tasks for multiple modules are executed to generate a coverage database and store it in a preset path, including: The coverage filtering rules and simulation duration parameters in the configuration information are parsed using a preset script; The coverage filtering rules and simulation duration parameters are mapped to the simulation execution scripts of multiple modules; Load the latest version of the code into the simulation execution environment corresponding to each module; Run the simulation execution script and perform simulation verification on the module in the simulation execution environment to obtain the coverage point execution data corresponding to each module; The coverage point execution data is encapsulated based on preset database generation rules to obtain a coverage database; The coverage database of each module is stored in the specified storage location according to the preset path rules.

3. The method according to claim 2, characterized in that, Mapping the coverage filtering rules and simulation duration parameters to simulation execution scripts for multiple modules includes: Extract the unique identifier information corresponding to each module in the configuration information; Establish a mapping table between the unique identifier information and the corresponding parsed coverage filtering rules and simulation duration parameters; Based on the mapping table, the corresponding coverage filtering rules and simulation duration parameters are written into the preset parameter configuration area of ​​the simulation execution script of each module.

4. The method according to claim 1, characterized in that, The coverage substrate and the coverage database in the preset path are merged from multiple data sources to obtain a global coverage database, including: Get the preset incremental merging rules; Based on the preset incremental merging rules, databases to be updated are selected from the coverage database; The database to be updated is merged with the coverage substrate to obtain a global coverage database.

5. The method according to claim 4, characterized in that, Also includes: Retrieve preset metadata verification rules; The merged database is subjected to integrity verification according to the preset metadata verification rules, and the verification result is obtained. The global coverage database is corrected based on the verification results.

6. The method according to claim 5, characterized in that, Based on the incremental merge rules, databases to be updated are selected from the coverage database, including: Obtain the first version identifier of the coverage database for each module; Compare the first version identifier with the second version identifier of the coverage substrate; The coverage databases whose first version identifier and second version identifier do not match are selected as the databases to be updated.

7. The method according to claim 1, characterized in that, Also includes: Obtain the preset exemption file storage path and preset exemption rules; Read at least one exemption file from the preset exemption file storage path; The exemption conditions for the coverage points are obtained by parsing the exemption file. The coverage point data in the global coverage database is matched according to the coverage point exemption conditions to obtain the matching results; The global coverage database is corrected based on the matching results to generate a corrected coverage database.

8. A chip verification coverage data processing device, characterized in that, include: The acquisition module is used to acquire preset configuration information and access permissions to preset code repositories. The configuration information includes coverage parameters and simulation parameters. The detection module is used to detect the version tags of the code repository to obtain the latest version code, and update the coverage baseboard based on the latest version code; The simulation module is used to execute simulation tasks of multiple modules based on the latest version of the code and the configuration information, generate a coverage database and store it in a preset path; The merging module is used to merge the coverage substrate and the coverage database in the preset path into a global coverage database by multiple data sources. The generation module is used to store the global coverage database and generate coverage data reports.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images