A general merging method of coverage data, electronic equipment and storage medium

Abstract

The present application relates to the technical field of electronic automation design, in particular to a general merging method of coverage data, an electronic device and a storage medium, which loads a mapping file including module mapping and instance mapping, judges whether the abstract syntax tree structure of the module to which the first instance belongs and the abstract syntax tree structure of the module to which the second instance to be merged are the same, when they are the same, if the full path name verification code of the first instance and the second instance is the same, or the first instance and the second instance meet the instance-level merging condition according to the instance mapping in the mapping file, the coverage data is merged, when they are not the same, if the first instance and the second instance meet the module-level merging condition according to the module mapping in the mapping file, then the coverage data is merged, which realizes the support of the instance-level merging scene. It simultaneously realizes the general and supports the requirements of the instance-level merging scene and the module-level merging scene, and improves the flexibility and efficiency of the verification analysis.

Description

Technical Field

[0001] This invention relates to the field of electronic automation design technology, and in particular to a universal method for merging coverage data, an electronic device, and a storage medium. Background Technology

[0002] In modern VLSI design verification workflows, coverage is a key indicator of verification completeness, and its data collection and merging are core components of the verification closed loop. Coverage database merging typically refers to aggregating and analyzing coverage data from multiple independent simulation test cases based on a unified design model structure to generate a global coverage statistical report. However, its merging granularity is relatively limited, making it difficult to flexibly adapt to diverse verification analysis needs. Specifically, current merging methods face challenges in the following two typical scenarios: First, in a module-level merging scenario: when multiple different design implementations contain the same submodule definition (e.g., sub1.v), verification engineers often need to aggregate and analyze the coverage data of all instances of that submodule across all designs. For example, design 1 instantiates the sub1 module once, while design 2 instantiates it twice. In this scenario, the goal of merging is to generate a unified report representing the overall coverage of the sub1 module in the overall verification, that is, to merge all sub1 instance data into a single logical entity. This requires the merging method to be able to identify and aggregate instances of the same module across designs.

[0003] Second, instance-level merging scenarios: For more granular analysis needs, users need to manually specify which instance coverage data to merge, rather than relying on automatic categorization based on module definitions. For example, a user might only want to merge the coverage data of instance u_sub1 in Design1 and instance u_sub1_1 in Design2 to analyze the joint coverage of these two specific instances. This merging mode is more granular and emphasizes precise control based on specific instance paths.

[0004] However, there is currently no universal database merging method to support both of the above merging scenarios. Different vendors have their own proprietary merging methods, such as merging via command-line parameters or merging via text file definitions. This makes it impossible to effectively merge coverage data in these two scenarios when processing complex validation data. Therefore, there is an urgent need for a universal coverage database merging method that can simultaneously support module-level and instance-level merging requirements to improve the flexibility and efficiency of validation analysis. Summary of the Invention

[0005] To address the aforementioned technical problems, the present invention adopts the following technical solution: a general method for merging coverage data, the method comprising the following steps: S100, Load the mapping file, which includes module mapping and instance mapping.

[0006] S300, determine whether the abstract syntax tree structure of the module to which the first instance belongs in the first database is the same as the abstract syntax tree structure of the module to which the second instance belongs in the second database to be merged, and perform the following steps: S310, when they are the same, obtain the full path name verification codes of the first instance and the second instance respectively; if the full path name verification codes of the first instance and the second instance are the same, or if the first instance and the second instance are determined to meet the instance-level merging condition according to the instance mapping in the mapping file, then merge the coverage data of the second instance in the second coverage data file into the coverage data of the first instance in the first coverage data file.

[0007] S330, when they are different, if the first instance and the second instance satisfy the module-level merging condition according to the module mapping in the mapping file, then the coverage data of the second instance in the second coverage data file is merged into the coverage data of the first instance in the first coverage data file.

[0008] Furthermore, the present invention also provides a non-transitory computer-readable storage medium storing at least one instruction or at least one program segment, wherein the at least one instruction or the at least one program segment is loaded and executed by a processor to implement the above-described method.

[0009] In addition, the present invention provides an electronic device including a processor and the aforementioned non-transitory computer-readable storage medium.

[0010] The present invention has at least the following beneficial effects: This invention provides a general method, electronic device, and storage medium for merging coverage data. By loading a mapping file including module mappings and instance mappings, when the abstract syntax tree (API) structures of the modules to which the second instance and the first instance belong are the same, coverage data are merged if the full path names are identical or if the instance mapping determines that instance-level merging conditions are met, thus supporting instance-level merging scenarios. When the API structures are different, coverage data are merged if the module names meet module-level merging conditions and are identical, thus supporting instance-level merging scenarios. This method simultaneously fulfills the requirement of being general and supporting both instance-level and module-level merging scenarios, and improves the flexibility and efficiency of verification analysis. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart of a general method for merging coverage data provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the steps for determining whether the abstract syntax tree structures of the modules provided in this embodiment of the invention are the same. Detailed Implementation

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

[0014] Unless otherwise defined, all technical and scientific terms used in the embodiments of this invention have the same meaning as commonly understood by those skilled in the art.

[0015] Please see Figure 1 This invention provides a flowchart of a general method for merging coverage data, the method comprising the following steps: S100, Load the mapping file, which includes module mapping and instance mapping.

[0016] In this context, a module refers to a reusable functional or design unit in a Hardware Description Language (HDL) design, consisting of a set of logic circuits and interface definitions. A module is a static template for the design, defining the structure, ports, and behavior of that functional unit; it does not participate in simulation execution itself.

[0017] An instance is a single instantiation of a module. Each instance has a unique full path name within the design abstract syntax tree structure, identifying its position in the design tree. During coverage analysis, each instance independently collects its internal coverage information, generating corresponding coverage data.

[0018] The mapping files include module mappings and instance mappings. The module mapping includes a list of module names, declaring modules whose instance data should be merged during the merging process. This instructs the system to merge the coverage data of all instances for each module name in the module mapping across different coverage data files. For example, if the module mapping includes mod1, and mod1 is instantiated as instance inst1 in design 1, and two instances inst2 and inst3 are instantiated in design 2, then during the merging process, the coverage data of all instances inst1, inst2, and inst3 instantiated under the name mod1 needs to be merged. The instance mapping includes multiple mapping entries. Each entry declares the full path name of the second instance belonging to the second database that should be merged during the merging process, as well as the full path name of the first instance belonging to the first database after the merge. This instructs the system to merge the coverage data of all second instance full path names in each list item of the instance mapping into the coverage data of the first instance full path names. For example, in an instance mapping, there is a mapping item {{top.inst1,top.inst2},sub.b1}, where top.inst1 and top.inst2 are the full path names of the second instance belonging to the second database, and sub.b1 is the full path name of the first instance belonging to the first database after merging. Then, during the merging process, the coverage data of top.inst1 and top.inst2 need to be merged into sub.b1.

[0019] In one implementation, the instance mapping in S100 includes multiple mapping items, each including at least one full path name of a second instance, the full path name of a first instance, and the name of its corresponding module; wherein the second instance is a target to be merged in the second database, and the first instance is a target to be merged in the first database. The module mapping includes multiple module names. S100 further includes: calculating the full path name checksum of each second instance, the full path name checksum of each first instance, and the module name checksum for each instance in the instance mapping. The module name checksum is calculated separately for each module name in the module mapping.

[0020] It should be noted that "first database" and "second database" are used only to distinguish between different databases, and "first instance" and "second instance" are used only to distinguish between instances within different databases, and should not be interpreted as a restriction on the order, priority, or data weight of the databases or instances. "First instance" refers to the instance from the first database, and "second instance" refers to the instance from the second database. Similarly, for ease of understanding and description, "first design module," "first coverage data file," and "first specified file" will be used to refer to the design module, coverage data, and specified file in the first database, and "second design module," "second coverage data file," and "second specified file" will be used to refer to the design module, coverage data, and specified file in the second database.

[0021] The full path name of an instance is a name constructed by concatenating the names from top to bottom, starting from the top-level node. As an example, if the name of an instance is inst1-1-1, its parent node is the intermediate node inst1-1, and the parent node of inst1-1 is the top-level node inst1. Therefore, the full path name of the instance inst1-1-1 is inst1.inst1-1.inst1-1-1.

[0022] The instance full path name checksum is a unique checksum generated based on the instance's full path name. When the instance's name and / or hierarchy changes, its full path name changes accordingly, and consequently, the full path name checksum changes as well. Therefore, the instance's full path name checksum can be used to verify whether the instance's name and / or hierarchy has changed.

[0023] In one implementation, the instance full path name checksum is obtained by calculating the hash value of the full path name. Other methods for verifying whether instance full path names are the same, and methods for obtaining checksums, also fall within the scope of protection of this invention.

[0024] The module name checksum is a unique checksum generated based on the module name. When the module name changes, the checksum changes accordingly. This checksum is used to verify whether the module name has changed. It's important to note that the module name is different from the full path module name. As an example, when the full path module name is mod1.mod1-1.mod1-1-1, the module name of the leaf node is mod1-1-1.

[0025] In one implementation, the module name checksum is obtained by calculating the hash value of the module name. Other methods for verifying whether module names are the same, and methods for obtaining checksums, also fall within the scope of protection of this invention.

[0026] There is one and only one first database, which is used to receive the databases to be merged and merge the coverage data from the databases to be merged into the first database.

[0027] The second database is the database to be merged. It must include at least one second database to be merged.

[0028] It should be noted that the merge target is used to receive the coverage data from the second instance and merge it with its own already stored coverage data. During the merge process, the coverage data obtained from each instance test is used as the basic unit for merging.

[0029] In one embodiment, S100 further includes: loading a first specified file in a first database, the first specified file including an abstract syntax tree structure check code of a first design module, a module name check code of the first design module, an instance full path name check code of a first instance, and its first coverage data.

[0030] Specifically, a designated file is used to store the abstract syntax tree structure checksum, module name checksum, instance full path name checksum, and their coverage data. This eliminates the need to load the design model file and / or design file when merging coverage data from the database. Furthermore, this technology bypasses the traditional steps of parsing and reconstructing the original coverage data. In essence, it avoids parsing and segmenting the continuous binary data stream of the simulation output according to its corresponding coverage domains and coverage items, and it also eliminates the need to re-instantiate and reconstruct a complete data structure object for the entire coverage model in memory. Therefore, it reduces the amount of data loaded and memory overhead, thereby improving loading and merging efficiency.

[0031] In one implementation, the first designated file comprises a first coverage data file and a first design information file. The first coverage data file includes first coverage data, and the first design information file includes an abstract syntax tree structure checksum for the first design module, a module name checksum for the first design module, and a full path name checksum for the first instance. The first coverage data file also includes a unique identifier for the first instance; the first design information file also includes a unique identifier for each design module, a unique identifier for each first instance, and a unique identifier for its respective design module. It should be noted that the second designated file has the same structure as the first designated file, and will not be described again. Compared to the traditional method of loading a design model information file (items) containing structured information for each coverage metric, the method provided in this embodiment significantly reduces the amount of data loaded. Furthermore, it bypasses the steps of parsing and reconstructing the original coverage data in the traditional process. Specifically, it eliminates the need to parse and segment the continuous binary data stream output by simulation according to its corresponding coverage domain and coverage item structures, and it also eliminates the need to re-instantiate and construct a complete data structure object for the entire coverage model in memory, thus reducing memory overhead. It should be noted that traditional design model information files include structured information for each coverage metric. For example, the structured information includes structured information for each covered object: the type, name, unique identifier, and unique identifier of its parent node.

[0032] In one implementation, the first designated file is a first coverage data file, which includes the abstract syntax tree structure checksum of the first design module, the module name checksum of the first design module, the full path name checksum of the first instance, and its first coverage data. It should be noted that the second designated file has the same structure as the first designated file, and will not be described again. During merging, only all coverage data files need to be loaded; there is no need to load the traditional design information files and design model information files containing information about the design modules and their instances. This significantly reduces the amount of data loaded, resulting in higher loading efficiency. Furthermore, it eliminates the need to segment the continuous data stream of simulation output according to the coverage model structure and construct corresponding memory data structures for the coverage model, reducing memory overhead and making the search process simpler and more efficient. It should be noted that the traditional design information file includes information about the design modules and their instances.

[0033] It should be noted that any method of saving the relevant information to a file other than the design model information file to form a specified file falls within the protection scope of this invention.

[0034] In one implementation, the method further includes: S200, if the coverage data of the second instance in the second database to be merged has the same data width as the coverage data of the first instance in the first database, then S300 is executed; if the data widths are different, then S300 is not executed and is skipped directly. Step S200 is an optimization step, which can filter out instances that cannot be merged in advance based on the data width, reducing the probability of merging errors and improving merging efficiency.

[0035] S300, determine whether the abstract syntax tree structure of the module to which the first instance belongs in the first database is the same as the abstract syntax tree structure of the module to which the second instance belongs in the second database to be merged.

[0036] In one implementation, please refer to [reference needed]. Figure 2 It illustrates the steps for determining whether the abstract syntax tree structures of the modules are the same. S300 also includes: S301, Obtain the abstract syntax tree structure check code of the first design module to which the first instance belongs in the first database; S302, Obtain the abstract syntax tree structure check code of the second design module to which the second instance in the second database to be merged belongs; S303, when the abstract syntax tree structure check code of the first design module is the same as the abstract syntax tree structure check code of the second design module, it is determined that the abstract syntax tree structures of the modules to which the first instance of the first database and the second instance of the second database belong are the same; otherwise, they are not the same.

[0037] It should be noted that other methods for determining whether the definitions of the modules to which two instances belong are the same also fall within the scope of protection of this invention.

[0038] The definition of a design module includes its internal attributes and sub-design elements. Internal attributes are metadata or declarative characteristics inherent to the module itself, excluding its substructures. Examples include the module name, associated signal list, and input parameter list. Sub-design elements are the lower-level structures or statements contained within the module that constitute its functional logic. They are components of the module's functionality and typically exist as child nodes of module nodes in the abstract syntax tree (AST). Sub-design elements include instantiation statements, signal connection relationships, continuous assignment statements, and procedural blocks. Each input parameter in the input parameter list is defined by its name and data type and is abstracted into a structured object during the parsing phase. During object instantiation, the system constructs an in-memory data structure based on this structured object. This in-memory data structure is the abstract syntax tree (AST), which retains only core information relevant to simulation execution and coverage collection, such as parameter names, types, instance paths, and connection relationships. Redundant information unrelated to execution, such as comments, blank lines, and formatted whitespace, is actively removed by the parser and not included in the final in-memory representation.

[0039] Furthermore, based on the judgment result, execute the following S310 or S320: S310, when they are the same, obtain the full path name verification codes of the first instance and the second instance respectively; if the full path name verification codes of the first instance and the second instance are the same, or if the first instance and the second instance are determined to meet the instance-level merging condition according to the instance mapping in the mapping file, then merge the coverage data of the second instance in the second coverage data file into the coverage data of the first instance in the first coverage data file.

[0040] It should be noted that when the two instances to be merged belong to modules with the same abstract syntax tree structure, there are two scenarios: one is merging the coverage data of instances with the same full path name, and the other is merging the coverage data of instances with the full path name specified by the user in the instance mapping. This can solve the problem of instance-level merging scenarios. When the two instances to be merged belong to modules with different abstract syntax tree structures, but the module name of the second instance is the module name specified by the user in the module mapping, and the module names of the first and second instances are the same, then their coverage data will be merged. This can solve the problem of module-level merging scenarios.

[0041] In one implementation, in step S310, the instance-level merging condition is: the instance mapping includes a mapping relationship between the full path name checksums of the first instance and the second instance. Specifically, step S310 further includes the step of determining whether the first instance and the second instance meet the instance-level merging condition based on the instance mapping in the mapping file: querying the instance mapping based on the full path name checksums of the first instance and the second instance; if there is a mapping relationship between the full path name checksum of the second instance and the checksum of the full path instance name of the first instance, then it is determined that the first instance and the second instance meet the instance-level merging condition.

[0042] As an example, when the full path name of the second instance to be merged is top.inst1 and the full path name of the first instance is sub.b1, if a user-specified mapping item in the instance mapping is {{top.inst1,top.inst2},sub.b1}, that is, there is a mapping relationship between top.inst1 and sub.b1 in the instance mapping, the coverage data of top.inst1 and sub.b1 will be merged.

[0043] S330, when they are different, if the first instance and the second instance satisfy the module-level merging condition according to the module mapping in the mapping file, then the coverage data of the second instance in the second coverage data file is merged into the coverage data of the first instance in the first coverage data file.

[0044] It should be noted that if two instances belong to modules with different abstract syntax trees, but their module names are the same and are module names in the module mapping, then their coverage data can be merged. Note that this refers to the same module name, not the fully qualified path of the module.

[0045] In one implementation, in step S330, the module-level merging condition is: the module name of the design module to which the second instance belongs is matched in the module mapping, and the module name checksum of the design module to which the second instance belongs is the same as the first module name checksum of the design module to which the first instance belongs. Specifically, S330 further includes the step of determining whether the first instance and the second instance meet the module-level merging condition based on the module mapping in the mapping file: when the corresponding module name is matched in the module mapping based on the module name of the design module to which the second instance belongs, and the first module name checksum of the design module to which the first instance belongs is the same as the second module name checksum of the design module to which the second instance belongs, then it is determined that the first instance and the second instance meet the module-level merging condition.

[0046] In one implementation, the operation of merging the coverage data of the second instance into the coverage data of the first instance is performed using a bitwise OR operation to preserve the bit information that has been covered in either instance.

[0047] In summary, this invention provides a general method for merging coverage data. By loading a mapping file including module mappings and instance mappings, when the abstract syntax tree structures of the modules to which the second instance and the first instance belong are the same, the coverage data are merged if the full path names are the same or if the instance mapping determines that the instance-level merging conditions are met, thus supporting instance-level merging scenarios. When the abstract syntax tree structures are different, if the module names meet the module-level merging conditions and are the same, the coverage data are merged, thus supporting instance-level merging scenarios. This method simultaneously fulfills the requirements for supporting both instance-level and module-level merging scenarios and improves the flexibility and efficiency of verification analysis.

[0048] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0049] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0050] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0051] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0052] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of this invention is defined by the appended claims.

Claims

1. A general method for merging coverage data, characterized in that, The method includes the following steps: S100, Load the mapping file, which includes module mapping and instance mapping; S300, determine whether the abstract syntax tree structure of the module to which the first instance belongs in the first database is the same as the abstract syntax tree structure of the module to which the second instance belongs in the second database to be merged, and perform the following steps: S310, when they are the same, obtain the full path name verification codes of the first instance and the second instance respectively; if the full path name verification codes of the first instance and the second instance are the same, or if the first instance and the second instance are determined to meet the instance-level merging conditions according to the instance mapping in the mapping file, then merge the coverage data of the second instance in the second coverage data file into the coverage data of the first instance in the first coverage data file. S330, when they are different, if the first instance and the second instance satisfy the module-level merging condition according to the module mapping in the mapping file, then the coverage data of the second instance in the second coverage data file is merged into the coverage data of the first instance in the first coverage data file. In S310, the instance-level merging condition is: the instance mapping includes the mapping relationship between the full path name check codes of the first instance and the second instance; In S330, the module-level merging condition is: the module name of the design module to which the second instance belongs is matched in the module mapping, and the module name verification code of the design module to which the second instance belongs is the same as the first module name verification code of the design module to which the first instance belongs.

2. The method according to claim 1, characterized in that, The following are included after S100 and before S300: S200: If the coverage data of the second instance in the second database to be merged has the same data width as the coverage data of the first instance in the first database, then execute S300; if the data widths are different, then do not execute S300.

3. The method according to claim 1, characterized in that, The S300 also includes: S301, Obtain the abstract syntax tree structure check code of the first design module to which the first instance belongs in the first database; S302, Obtain the abstract syntax tree structure check code of the second design module to which the second instance in the second database to be merged belongs; S303, when the abstract syntax tree structure check code of the first design module is the same as the abstract syntax tree structure check code of the second design module, it is determined that the abstract syntax tree structures of the modules to which the first instance of the first database and the second instance of the second database belong are the same; otherwise, they are not the same.

4. The method according to claim 1, characterized in that, In S100, the instance mapping includes multiple mapping items, each mapping item including at least one full path name of a second instance, the full path name of a first instance and the name of its module; wherein, the second instance is the target to be merged in the second database, and the first instance is the target to be merged in the first database; The module mapping includes multiple module names; S100 further includes: calculating the instance full path name check code, the instance full path name check code, and the module name check code for each second instance in the instance mapping; and calculating the module name check code for each module in the module mapping.

5. The method according to claim 1, characterized in that, S100 further includes: S110, loading a first specified file in the first database, the first specified file including the abstract syntax tree structure check code of the first design module, the module name check code of the first design module, the full path name check code of the first instance and its first coverage data.

6. The method according to claim 5, characterized in that, The first specified file is a first coverage data file and a first design information file, wherein the first coverage data file includes first coverage data, and the first design information file includes an abstract syntax tree structure check code of the first design module, a module name check code of the first design module, and a full path name check code of the first instance; Alternatively, the first specified file may be a first coverage data file, which includes the abstract syntax tree structure check code of the first design module, the module name check code of the first design module, the full path name check code of the first instance, and its first coverage data.

7. A non-transitory computer-readable storage medium, wherein the storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the method as described in any one of claims 1-6.

8. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 7.

Images