A coverage database merging method, electronic equipment and storage medium

Abstract

The present application relates to the technical field of electronic automation design, in particular to a coverage database merging method, an electronic device and a storage medium, a first specified file in a first database and a second specified file in a second database are loaded; the coverage data of a first instance in the first specified file is taken as an outer loop, the coverage data of a second instance in the second specified file is taken as an inner loop, if the full path name check code of the first instance and the full path name check code of the second instance are the same and the abstract syntax tree structure check code of the first design module to which the first instance belongs and the abstract syntax tree structure check code of the second design module to which the second instance belongs are the same, the coverage data of the second instance is merged into the coverage data of the first instance. It only needs to load specified files, and the required data has been stored in the corresponding specified files, not only greatly reducing the memory occupation, but also greatly improving the loading efficiency and merging efficiency of the database.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic automation design, in particular to a merging method of coverage database, an electronic device and a storage medium. BACKGROUND

[0002] In the modern very large scale integrated circuit design verification process, coverage as a key indicator to measure the completeness of verification, its data collection and merging is the core link in the verification closed loop. The merging of coverage database usually refers to the aggregation analysis of the coverage data generated by multiple independent simulation test cases according to a unified design model structure, so as to generate a global coverage statistical report. The current mainstream merging method depends on a preloaded design model information reconstruction process: before the merging operation is started, the hierarchical structure, signal and instance model information of the design must be completely loaded and parsed to build a model structure tree in memory. Then, the system reads the coverage data files of each test case in turn, divides the original coverage data in them into fine-grained data blocks according to the aforementioned model structure, and maps them to the corresponding nodes in the model structure tree. On this basis, the coverage data of each node is merged and counted one by one, and finally a unified coverage database is generated.

[0003] However, this method faces significant performance bottlenecks when faced with large-scale complex designs. First, the real design is large in scale, and the design model information is huge in volume. The process of preloading and building the model structure tree consumes a large amount of memory resources and computing time, becoming the bottleneck of the merging process. Secondly, the division of coverage data, the dynamic creation and maintenance of memory objects further aggravate the memory occupation, especially when dealing with a large number of test cases, the system resource consumption grows nonlinearly. The above problems together cause the existing method to perform poorly in merging large-scale coverage databases, severely restricting the verification iteration efficiency. Therefore, an urgent need exists for a method that can avoid full model preloading, reduce memory overhead and improve merging efficiency. SUMMARY

[0004] In view of the above technical problems, the technical solution adopted by the present application is: a merging method of coverage database, the method comprising the following steps:

[0005] S100, loading a first specified file of the first database including the abstract syntax tree structure check code of the first design module, the full path name check code of the first instance and the first coverage data thereof.

[0006] S200, loading one or more second specified files of the second database including the abstract syntax tree structure check code of the second design module, the full path name check code of the second instance and the second coverage data thereof.

[0007] S300, merging the coverage data of each second instance in the second specified file into the coverage data of each first instance in the first specified file; wherein the following steps are sequentially performed for the coverage data of each first instance:

[0008] S310, obtaining the coverage data of each second instance, and merging the coverage data of the second instance into the coverage data of the first instance if the full path name check code of the first instance and the full path name check code of the second instance are the same and the abstract syntax tree structure check code of the first design module to which the first instance belongs and the abstract syntax tree structure check code of the second design module to which the second instance belongs are the same.

[0009] In addition, the present application also provides a non-transitory computer readable storage medium, wherein at least one instruction or at least one program is stored, the at least one instruction or the at least one program is loaded and executed by a processor to implement the above method.

[0010] In addition, the present application also provides an electronic device comprising a processor and the above non-transitory computer readable storage medium.

[0011] The present application has at least the following beneficial effects:

[0012] The embodiment of the present application provides a merging method of a coverage database, an electronic device and a storage medium, which loads a first specified file and a second specified file, and merges the coverage data of two instances with the same full path name and the same definition of the module to which the instance belongs, stores the abstract syntax tree structure check code, the module name check code, the instance full path name check code and the coverage data thereof in the specified file, and further makes it no longer load the design model file when merging the coverage data of the database, and only needs to load the specified file, bypasses the step of parsing and structuring reconstruction of the original coverage data in the traditional process. Specifically, it does not need to parse and split the continuous binary data stream output by simulation according to the corresponding coverage domain and coverage item structure, and does not need to re-instantiate the entire coverage model in the memory and construct a complete data structure object. Therefore, the method provided by the embodiment of the present application reduces the data amount and memory overhead of loading, and greatly improves the loading efficiency and merging efficiency. Moreover, the data required to be compared in the traversal process of the method provided by the embodiment of the present application has been stored in the corresponding specified file, which further improves the loading efficiency and merging efficiency of the database. BRIEF DESCRIPTION OF DRAWINGS

[0013] In order to make the technical solutions in the embodiments of the present application clearer, the accompanying drawings needed in the embodiments will be briefly introduced below. Obviously, the accompanying drawings in the following description only show some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative effort based on these drawings.

[0014] Figure 1 A flow chart of a merging method of a coverage database is provided in the embodiments of the present application. DETAILED DESCRIPTION

[0015] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall into the scope of the present application.

[0016] Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meanings as commonly understood by those skilled in the art.

[0017] Please refer to Figure 1 The merging method of a coverage database includes the following steps:

[0018] S100, loading a first designated file in a first database, the first designated file including an abstract syntax tree structure check code of a first design module, a first instance full path name check code and first coverage data of the first design module.

[0019] The first database is a basic database, and all coverage data in the second databases needs to be merged into the first database.

[0020] The abstract syntax tree structure check code has uniqueness. A unique abstract syntax tree structure check code is generated for each design module in the designated file. The abstract syntax tree structure check code is generated based on the abstract syntax tree structure of the compiled design module. If the definition of the design module changes, the value of the abstract syntax tree structure check code will also change. Therefore, the abstract syntax tree structure check code can be used to verify whether the definition of the design module changes. It should be noted that the abstract syntax tree structure check code is generated based on the definition content of the design module, not the name of the design module, nor the full path name of the design module.

[0021] In an embodiment, the definition of the design module includes internal attributes and sub-design elements of the design module, wherein the internal attributes are meta-information or declarative features of the module itself, not including sub-structures thereof. For example, the internal attributes include a module name, a list of associated signals, and a list of input parameters. The sub-design elements are lower-level structures or statements included in the module and constituting a function logic of the module, and are constituent parts of the function implementation of the module, and are usually present as child nodes of a module node in an abstract syntax tree. The sub-design elements include instantiation statements, signal connection relationships, continuous assignment statements, process blocks, and the like. Each input parameter in the list of input parameters is defined by a name and a data type thereof, and is abstracted as a structured object in a parsing phase. In an object instantiation process, a system constructs a corresponding memory data structure based on the structured object. The memory data structure is an abstract syntax tree, which only retains core information related to simulation execution and coverage collection, such as parameter names, types, instance paths, and connection relationships. In the construction process, redundant information in the source code that is irrelevant to execution, such as comments, blank lines, and formatted whitespaces, is actively removed by a parser and is not included in the final memory representation. In this way, the generated memory structure has higher storage and access efficiency, which is conducive to improving the model loading performance in the subsequent coverage database merging process. Therefore, when a signal name in the definition of the design module is changed, the abstract syntax tree structure verification code is also changed.

[0022] In an embodiment, S100 further includes a step of obtaining an abstract syntax tree structure verification code of the first design module:

[0023] S110, compiling the design source code to generate an abstract syntax tree representing a module hierarchy.

[0024] S120, serializing the abstract syntax tree into a data stream, and calculating a hash value based on the data stream; the hash value is an abstract syntax tree structure verification code of the first design module.

[0025] In an embodiment, in the process of obtaining the abstract syntax tree structure verification code, serialization has I / O overhead, which is generally completed together with the incremental compilation function. The verification code can also be calculated based on the abstract syntax tree structure in the memory. Therefore, the step of obtaining the abstract syntax tree structure verification code of the first design module:

[0026] S101, compiling the design source code to generate an abstract syntax tree representing a module hierarchy.

[0027] S102, traversing the abstract syntax tree of the module; during the traversing, adding the internal attributes and child design elements of the module to a verification context in sequence; after the traversing is completed, calculating a hash value based on the verification context; the hash value is the abstract syntax tree structure verification code of the first design module.

[0028] The full path name verification code is also unique. A unique full path name verification code is generated for each instance in a specified file. The full path name verification code is generated based on the full path name of the instance. The full path name of the instance is a name obtained by concatenating from top to bottom and layer by layer starting from a top node. When the name and / or hierarchical structure of the instance changes, the full path name of the instance changes, and thus the full path name verification code changes. Therefore, the full path name verification code of the instance can be used to verify whether the name and / or hierarchical structure of the instance changes. As an example, when the name of the instance is inst1-1-1, the full path name of the instance is inst1.inst1-1.inst1-1-1, where inst1 is a top node, inst1-1 is a child node of the top node, and inst1-1-1 is a child node of the intermediate node inst1-1.

[0029] In an embodiment, the full path name verification code of the first instance is calculated in the form of calculating a hash value of the full path name of the first instance, and the hash value is the full path name verification code of the first instance.

[0030] It should be noted that the "first" and "second" in the "first specified file" and the "second specified file" are only used to distinguish the specified files in different databases, and should not be understood as a limitation on the order, priority or data weight of the files. Among them, the "first specified file" refers to the specified file from the first database, and the "second specified file" refers to the specified file from the second database. Similarly, for the convenience of understanding and description, the "first design module", "first instance" and "first coverage data" are used to refer to the design module, instance and coverage data in the first specified file. The "second design module", "second instance" and "second coverage data" are used to refer to the design module, instance and coverage data in the second specified file.

[0031] Among them, the specified file can be a coverage data file, that is, the abstract syntax tree structure verification code of the design module, the full path name verification code of the instance and the coverage data thereof are stored in the coverage data file. The specified file can also be a combination of the coverage data file and the design information file, that is, the abstract syntax tree structure verification code of the design module and the full path name verification code of the instance are stored in the design information file, and the coverage data is stored in the coverage data file.

[0032] In an embodiment, the first specified file and the second specified file are both coverage data files. In the coverage data files, only abstract syntax tree structure check codes of design modules, full path name check codes of instances, and coverage data of the instances are included. When merging the coverage data in the first database and the second database, all coverage data files need to be loaded, and no additional design information files and design model information files in the first database and the second database need to be loaded, so that the loading efficiency is higher, and the searching process is simpler and more efficient.

[0033] In an embodiment, the first specified file includes a first coverage data file storing coverage data, and a first design information file storing abstract syntax tree structure check codes of the first design module and full path name check codes of the first instance. The first coverage data file further includes a unique identity of the first instance, and the first design information file further includes a unique identity of each design module, a unique identity of each first instance, and a unique identity of a design module to which each first instance belongs. The second specified file includes a second coverage data file storing coverage data, and a second design information file storing abstract syntax tree structure check codes of the second design module and full path name check codes of the second instance. The second coverage data file further includes a unique identity of the second instance, and the second design information file further includes a unique identity of each design module information, a unique identity of each second instance, and a unique identity of a design module to which each second instance belongs.

[0034] It should be noted that in the scheme in which the specified file includes the coverage data file and the design information file, there is no redundant information in the coverage data file, and the file is the smallest. However, compared with the scheme in which the specified file is the coverage data file, the design information files in the first database and the second database need to be loaded additionally. The loading method of the specified file provided in the embodiment of the present application greatly reduces the data amount of the loaded file and the memory cost compared with the traditional method of loading the design model information file, and the data needs to be divided and the memory object needs to be established. It should be noted that the traditional design information file includes related information of the design module and the instance, such as the name of the design module, the name of the instance, the hierarchical structure of the instance tree, and the mapping relationship between the design module and the instance. The traditional design model information file includes structured information of each coverage index, such as structured information of each coverage object: the type, the name, the unique identity of the current coverage object, and the unique identity of the parent node to which the current coverage object belongs.

[0035] S200, loading a second specified file in one or more second databases including an abstract syntax tree structure check code of a second design module, a full path name check code of a second instance and second coverage data thereof.

[0036] Wherein, the loading of the first specified file and the second specified file is not dependent on a specific order, and the loading order can be dynamically determined according to system resources or a scheduling strategy.

[0037] S300, merging the coverage data of each second instance in the second specified file into the coverage data of each first instance in the first specified file. Wherein, the coverage data of each first instance is sequentially executed the following steps:

[0038] S310, obtaining the coverage data of each second instance, and if the full path name check code of the first instance and the full path name check code of the second instance are the same and the abstract syntax tree structure check code of the first design module to which the first instance belongs and the abstract syntax tree structure check code of the second design module to which the second instance belongs are the same, merging the coverage data of the second instance into the coverage data of the first instance.

[0039] It should be noted that the full path name check code of the second instance and the first instance being the same indicates that they are the same instance, and when the abstract syntax tree structure check code of the second instance and the first instance is the same, it indicates that the definitions of the design modules to which they belong are the same, that is, not only the definitions of the design modules on which they are based are the same, but also they are different test data of the same instance, so the coverage data of the two can be merged.

[0040] In an embodiment, the operation of merging the coverage data of the second instance into the coverage data of the first instance adopts a bitwise OR operation to retain the bit information that has been covered in any instance. Specifically, the first instance is a holding node of the reference coverage data, and the coverage data thereof is stored in the form of a bit vector; the second instance is a source of coverage data to be merged. The system performs a bitwise OR operation on the coverage bit vector of the second instance and the corresponding bit vector of the first instance, and updates the operation result to the coverage data of the first instance. The bitwise OR operation ensures that as long as a code position or a branch path is triggered to execute in any test case, the corresponding coverage bit is set to 1, and this state is retained after merging. Therefore, this merging strategy can accurately reflect the requirement of at least one coverage, avoid the loss of historical coverage information due to sequential loading or coverage, and improve the integrity and reliability of coverage statistics.

[0041] In an embodiment, when the specified file is a coverage data file, the coverage data in the coverage data file is associated with the full path name check code of the instance and the abstract syntax tree structure check code of the design module respectively. Therefore, S310 further comprises: when obtaining the coverage data of each instance, directly obtaining the full path name check code of the instance and the abstract syntax tree structure check code of the design module associated with the coverage data.

[0042] In an embodiment, when the specified file comprises a coverage data file and a design information file, the coverage data is stored in the coverage data file, and the full path name check code of the instance and the abstract syntax tree structure check code of the design module are stored in the design information file. Therefore, S310 further comprises the steps of obtaining the abstract syntax tree structure check code of the first design module and the full path name check code of the first instance:

[0043] S311, according to the unique identity of the first instance, searching the design information file to obtain the unique identity of the design module to which the first instance belongs and the full path name check code of the first instance.

[0044] S312, according to the unique identity of the design module to which the first instance belongs, searching the design information file again to obtain the abstract syntax tree structure check code of the first design module.

[0045] In summary, the embodiment of the present application provides a merging method of a coverage database, which loads a first specified file and a second specified file, and takes the coverage data of a first instance in the first specified file as an outer loop and takes the coverage data of a second instance in the second specified file as an inner loop, and merges the coverage data of two instances with the same full path name of the instance and the abstract syntax tree structure of the module to which the instance belongs. During this period, only the specified file needs to be loaded, without loading other files, greatly reducing the amount of data loaded and the memory occupied, and the data required for comparison in the traversal process has been stored in the corresponding specified file, greatly improving the merging efficiency. Therefore, the merging method of the coverage database provided by the present application not only greatly reduces the memory occupation, but also greatly improves the loading efficiency and merging efficiency of the database compared with the traditional scheme.

[0046] The embodiment of the present application also provides a non-transitory computer readable storage medium, which can be arranged in an electronic device to save at least one instruction or at least one program related to a method in the method embodiment. The at least one instruction or the at least one program is loaded and executed by the processor to realize the method provided by the above-mentioned embodiment.

[0047] The embodiment of the present application also provides an electronic device comprising a processor and the aforementioned non-transitory computer readable storage medium.

[0048] Embodiments of the application also provide a computer program product comprising program code for causing an electronic device to perform the steps of the methods according to various exemplary embodiments of the application described above when said program product is run on the electronic device.

[0049] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the above-described functions.

[0050] Although some specific embodiments of the application have been described in detail above, those skilled in the art should understand that the above examples are only for illustration, not for limiting the scope of the application. 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 application. The scope of the present application is defined by the appended claims.

Claims

1. A method for merging coverage databases, characterized in that, The method includes the following steps: S100, Load the first specified file in the first database, which includes the abstract syntax tree structure check code of the first design module, the full path name check code of the first instance, and its first coverage data; S200, load one or more second specified files from a second database, including the abstract syntax tree structure checksum of the second design module, the full path name checksum of the second instance, and its second coverage data; S300, merge the coverage data of each second instance in the second specified file into the coverage data of each first instance in the first specified file; wherein, for each coverage data of the first instance, the following steps are performed sequentially: S310, obtain the coverage data of each second instance. If the full path name check code of the first instance is the same as the full path name check code of the second instance, and the abstract syntax tree structure check code of the first design module to which the first instance belongs is the same as the abstract syntax tree structure check code of the second design module to which the second instance belongs, then merge the coverage data of the second instance into the coverage data of the first instance.

2. The method according to claim 1, characterized in that, Both the first specified file and the second specified file are coverage data files.

3. The method according to claim 2, characterized in that, When obtaining coverage data for each instance, directly obtain the full path name checksum of the instance associated with the coverage data and the abstract syntax tree structure checksum of the design module.

4. The method according to claim 1, characterized in that, The first specified file includes a first coverage data file storing coverage data, and a first design information file storing the abstract syntax tree structure check code of the first design module and the full path name check code of the first instance; wherein, the first coverage data file also includes a unique identifier of the first instance, and the first design information file also includes a unique identifier of each design module, a unique identifier of each first instance and the unique identifier of the design module to which it belongs; The second specified file includes a second coverage data file storing coverage data, and a second design information file storing the abstract syntax tree structure checksum of the second design module and the full path name checksum of the second instance; wherein, the second coverage data file also includes a unique identifier of the second instance; the second design information file also includes a unique identifier of each design module information; and a unique identifier of each second instance and the unique identifier of its respective design module.

5. The method according to claim 3, characterized in that, S310 also includes steps for obtaining the abstract syntax tree structure checksum of the first design module and the full path name checksum of the first instance: S311, Search the design information file based on the unique identifier of the first instance, and obtain the unique identifier of the design module to which the first instance belongs and the full path name verification code of the first instance; S312, based on the unique identifier of the design module to which the first instance belongs, search the design information file again to obtain the abstract syntax tree structure check code of the first design module.

6. The method according to claim 1, characterized in that, S100 also includes: the step of obtaining the abstract syntax tree structure checksum of the first design module: S110, compiles the design source code to generate an abstract syntax tree representing the module hierarchy; S120, the abstract syntax tree is serialized into a data stream, and a hash value is calculated based on the data stream; the hash value is the check code of the abstract syntax tree structure of the first design module; Alternatively, S100 may further include: the step of obtaining the abstract syntax tree structure checksum of the first design module: S101, compile the design source code to generate an abstract syntax tree representing the module hierarchy; S102, Traverse the abstract syntax tree of the module; during the traversal, add the module's internal attributes and sub-design elements to the verification context in sequence; after the traversal is completed, calculate the hash value based on the verification context; the hash value is the verification code of the abstract syntax tree structure of the first design module.

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

8. The method according to claim 1, characterized in that, The full path name verification code of the first instance is calculated by calculating the hash value of the full path name of the first instance, and the hash value is the full path name verification code of the first instance.

9. 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-8.

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

Images