Management methods, devices, and storage media for coverage-based indexed databases

Abstract

This invention relates to the field of electronic design automation technology, and in particular to a management method, device, and storage medium for a coverage-based index database. It loads the raw coverage data from the coverage database into memory and constructs a coverage data structure, while simultaneously extracting design hierarchy information from the coverage database to create an index database composed of multiple index tables. When the visualization query window initiates a query request, the index database retrieves the identifier of the target object based on the query request. The identifier is then processed within the coverage data structure, and the target window of the coverage visualization system is updated. This significantly improves search efficiency and achieves real-time search functionality.

Description

Technical Field

[0001] This invention relates to the field of electronic design automation technology, and in particular to a method, device and storage medium for managing a coverage-based index database. Background Technology

[0002] In chip functional verification, code coverage is a crucial metric for measuring verification completeness. Coverage databases are typically organized and managed using a hierarchical structure, consisting of multiple levels, primarily including modules, scopes, and cover items. Each level's nodes, from root to leaf, sequentially comprise modules, scopes, and cover items, with modules serving as root nodes, cover items as leaf nodes, and scopes as intermediate nodes. A cover item is the smallest basic unit for measuring coverage; the coverage status of all cover items constitutes the coverage of the corresponding parent node's scope. This pattern continues, with the coverage of all direct child scopes and child cover items of a root node constituting the coverage of that root node. This hierarchical structure effectively organizes massive amounts of coverage data, facilitating layered statistical analysis from the system level to the module level.

[0003] In actual verification and debugging processes, verification engineers often need to quickly locate specific coverage items based on test cases or assertion trigger information to analyze the reasons for their uncovering. Traditional coverage query methods rely on traversing the hierarchical structure layer by layer, starting from the top-level module, sequentially traversing the lower-level coverage domains, and then delving into the specific coverage item until a target identifier or attribute is matched. This method has significant performance bottlenecks when facing large-scale designs, especially complex chip verification scenarios containing hundreds of modules and tens of thousands of coverage items. Because each query requires traversing the potential complete hierarchical path, the search path is lengthy, intermediate nodes are accessed frequently, and the search range covers the entire relevant subtree, making accurate and rapid location impossible. Especially when the target coverage item is located in a deep node, the traversal process introduces significant delays, severely impacting debugging efficiency. Therefore, existing query mechanisms based on layer-by-layer traversal suffer from problems such as an excessively large search range and low search efficiency leading to slow response times, making it difficult to meet the needs of efficient verification iteration. Therefore, an efficient search method is urgently needed. Summary of the Invention

[0004] To address the aforementioned technical problems, the present invention adopts the following technical solution: a management method for an index database based on coverage, the method comprising the following steps:

[0005] S100, Obtain the coverage database, which stores the raw coverage data generated by the simulation tool.

[0006] S200, the original coverage data in the coverage database is loaded into the running memory of the coverage visualization system, and a coverage data structure is constructed in the running memory.

[0007] S300, extract the design hierarchy information from the coverage database, and establish an index database based on the extracted design hierarchy information. The index database includes a design module index table and a coverage domain index table for N different types of coverage indicators. The design hierarchy information includes index information for modules and instances, and index information for coverage domains of different types of coverage indicators.

[0008] S400, the coverage visualization system includes a visualization query window. When the visualization query window initiates a query request, the index database retrieves the identifier of the target object according to the query request, processes the identifier in the coverage data structure, and updates the target window of the coverage visualization system.

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

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

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

[0012] This invention provides a method, device, and storage medium for managing a coverage-based index database. It loads raw coverage data from the coverage database into memory and constructs a coverage data structure. Simultaneously, it extracts design hierarchy information from the coverage database to create an index database composed of multiple index tables. When a user initiates a query request in a visual query window, the corresponding coverage domain identifier is first obtained from the index database. Then, the database is searched based on the coverage domain identifier, and the final result is displayed visually. The use of index tables for different types of coverage metrics not only narrows the search scope but also allows for parallel execution of searches for different coverage metrics, significantly improving search efficiency and reducing latency; thus achieving real-time searching. Attached Figure Description

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

[0014] Figure 1 A flowchart illustrating a coverage-based index database management method provided in this embodiment of the invention. Detailed Implementation

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

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

[0017] Please see Figure 1 It illustrates a method for managing a coverage-based indexed database, the method comprising the following steps:

[0018] S100, Obtain the coverage database, which stores the original coverage data set generated by the simulation tool.

[0019] The coverage database includes coverage data files, which consist of coverage metric files, coverage data files, index files, and mapping files corresponding to different types of coverage metrics. These database files record complete design hierarchy information for each design module, coverage domain, and coverage item, as well as hierarchical information between instances. The design hierarchy information includes the identity, type, bound nodes, and coverage data of each layer node. Each layer node, from the root node to the leaf nodes, includes modules, coverage domains, and coverage items, where modules are the root nodes, coverage items are the leaf nodes, and coverage domains are the intermediate nodes. A coverage item is the smallest basic unit for measuring coverage. The coverage status of all coverage items constitutes the coverage of the corresponding parent node's coverage domain, and so on. The coverage of all direct child coverage domains and child coverage items of the root node constitutes the coverage of a root node.

[0020] The different types of coverage metrics include row coverage, condition coverage, finite state machine coverage, flip coverage, and assertion coverage.

[0021] S200, the original coverage data in the coverage database is loaded into the running memory of the coverage visualization system, and a coverage data structure is constructed in the running memory.

[0022] It's important to note that raw coverage data is typically in text or compact binary format, unsuitable for direct use in fast queries or rendering. The system performs syntax parsing on the read raw data to extract structured information. A hierarchical in-memory data structure is then built in runtime memory for efficient storage and access to the parsed coverage information. This structure can be a hash table, linked list, or array. This new structure is the core model the system truly uses for visualization.

[0023] In one implementation, the original coverage data is not aggregated. Therefore, when constructing the coverage data structure, the coverage of the module and the coverage of each coverage area are aggregated and stored based on the original coverage data.

[0024] S300, extract the design hierarchy information from the coverage database, and establish an index database based on the extracted design hierarchy information. The index database includes a design module index table and a coverage domain index table for various coverage metrics. The design hierarchy information includes index information for modules and instances, and index information for coverage domains of different coverage metrics.

[0025] In one implementation, the established design module index table includes the full name of the module, the type identifier of the design module, and the globally unique identifier of the design module. The full name of the instantiated module includes the hierarchical structure of the instances, with each level separated by a preset character. In one implementation, the preset character is ".", for example, the full name of the instance is top.inst.subinst, where top is the name of the top level, inst is the name of the middle level, and subinst is the name of the bottom level. Using other types of separators in the full name also falls within the scope of protection of this invention. In one implementation, the type of the design module includes modules, instances, interfaces, etc.

[0026] In one implementation, the established coverage index table includes a row coverage index table, a condition coverage index table, a finite state machine coverage index table, a flip coverage index table, and an assertion coverage index table.

[0027] In one implementation, the established row coverage index table includes a globally unique identifier for the design module, a globally unique identifier for the original design file, the line number of the row coverage field in the original design file, and the identifier of the row coverage field. The globally unique identifier of the original design file can uniquely locate information such as the filename and file path of the original design file.

[0028] In one implementation, the established condition coverage domain index table, finite state machine coverage domain index table, and flip coverage domain index table have the same structure, each including a globally unique identifier for the design module, a coverage domain name, and an identifier for the coverage domain. That is, the condition coverage domain index table includes the globally unique identifier for the design module, the condition coverage domain name, and the identifier for the condition coverage domain. The finite state machine coverage domain index table includes the globally unique identifier for the design module, the finite state machine coverage domain name, and the identifier for the finite state machine coverage domain. The flip coverage domain index table includes the globally unique identifier for the design module, the flip coverage domain name, and the identifier for the flip coverage domain.

[0029] In one implementation, the established assertion coverage index table includes the assertion coverage name, assertion type, and assertion coverage identifier. It should be noted that, since the number of coverage items under an assertion coverage is small, and the corresponding coverage item names are predefined and fixed, after finding the assertion coverage identifier, there is no need to perform a secondary search in memory for the corresponding coverage item; instead, multiple coverage items are directly presented in the graphical interface.

[0030] In one implementation, in each index table, the full name and the name are both of string data type. The identifier and the row number are both of positive integer data type.

[0031] S400, the coverage visualization system includes a visualization query window. When a user initiates a query request through the visualization query window, the index database retrieves the identifier of the target object according to the query request, processes the identifier in the coverage data structure, and updates the target window of the coverage visualization system.

[0032] In one implementation, the target window and the visual query window can be the same window or different windows.

[0033] In one implementation, a thread pool is created, with different threads processing different index files. In this embodiment of the invention, coverage domain index tables for different coverage metrics are stored in separate files to support concurrent index file generation and retrieval.

[0034] It should be noted that when a user locates or excludes a target object through a visual window, the search scope is first narrowed down using the index database. Then, based on the narrowed scope, processing is performed using the coverage data structure, achieving the goal of quickly finding and locating covered objects. Unlike previous methods that directly searched in memory using regular expressions, this embodiment of the invention creates an index database and centralizes all functions related to coverage domain searching at this index database layer. Furthermore, the index database is created only for coverage domains, excluding covered items. Since the number of covered items is quite large, creating an index for each covered item would significantly slow down the creation speed of the index database, and the resulting index file would be enormous. Therefore, the index is created only for the coverage domains. The corresponding coverage domain is first found in the index database, and then the covered item is searched in memory by traversing all covered items under that coverage domain. The index tables for different types of coverage metrics not only narrow the search scope but also allow for parallel execution of searches for different coverage metrics, significantly improving search efficiency and reducing latency; thus achieving the goal of real-time searching.

[0035] In one implementation, the visualization window searches for and locates the coverage of design modules and coverage areas based on user needs, excludes target objects, searches for the coverage of specific coverage items by including both the full name of the coverage area and the full name of the coverage item, or by using a partial name containing wildcards, locates the coverage of the query row, or directly obtains the coverage based on the target object selected by the user. Other types of search, location, or exclusion operations also fall within the protection scope of this invention.

[0036] It should be noted that coverage can be searched by module name or coverage domain name. This can be used when annotating validation plans, searching for corresponding modules by name in a coverage visualization system, searching for corresponding instances by name in an instance hierarchy, or in other application scenarios where it's necessary to locate the coverage of a target object. The target object can be a module, row coverage domain, conditional coverage domain, finite state machine coverage domain, and / or flipped coverage domain.

[0037] In one implementation, in step S400, the query condition is a location condition, which is any one of the following: the full name of the module and the type of the design module; the globally unique identifier of the design module and the name of the coverage area; the name of the coverage area and the type of the coverage area. S400 also includes a step for finding and locating the coverage of the design module and the coverage area:

[0038] S410, the user-inputted location conditions are obtained through the visual query window, and the location conditions are sent to the index database.

[0039] S420, the index database finds the identifier of the target object according to the positioning conditions, the target object being a design module or a coverage area; and sends the identifier of the target object to the coverage data structure.

[0040] S430, the coverage data structure updates the highlight attribute bound to the target window to the identifier of the target object; and triggers an update of the coverage of the target object highlighted in the target window.

[0041] It should be noted that in the coverage data structure, each target object has been bound to a corresponding coverage rate, and the target object and its bound corresponding coverage rate data will be directly displayed in the target window.

[0042] As an example, in the visual query window, entering the instance name "inst*" and type identifier "4" for the target object will return a globally unique identifier "1" for the design module after searching the index database. The corresponding instance object can then be obtained from the memory coverage data structure using "1". It should be noted that when the visual query window is a hierarchical interface, the type identifier "4" will be automatically appended to the query conditions, eliminating the need for manual input. As another example, entering the name "IDLE" for the target object and the globally unique identifier "1" for the design module in the visual query window will return a finite state machine coverage domain identifier "29" after searching the index database. The corresponding finite state machine coverage domain object can then be obtained from memory using "29".

[0043] In one implementation, when searching for a module to be excluded, a row coverage area, a conditional coverage area, a finite state machine coverage area, a flip coverage area, or an assertion coverage area by name in exclusion mode, S430 further includes: the coverage data structure updates the exclusion attribute bound to the target window to the identifier of the target object, so that it displays the exclusion option on the target object in the target window when the update is triggered.

[0044] It should be noted that users can search for the coverage status of a specific coverage item by its full name. The full names of coverage fields and coverage items include the hierarchical structure between them, with each level separated by a preset delimiter. In one embodiment, the preset character is "#", but other types of characters used as delimiters in the full names also fall within the scope of protection of this invention.

[0045] In one implementation, when a user needs to find the coverage status of a specific coverage item, the search is performed based on the full name of the coverage item entered by the user. The index database can narrow down the search range based on the coverage field in the full name of the coverage item, and then search for the coverage item in memory based on the narrowed range. That is, when the query condition in S400 includes both the coverage field and the full name of the coverage item, S400 also includes a coverage rate lookup step for the coverage item:

[0046] S401, after obtaining the query conditions input by the user through the visual query window, the query conditions are split into a coverage domain name part and a coverage item name part; and the coverage domain name part is sent to the index database, while the coverage item name part is sent to the coverage data structure.

[0047] It's important to note that the "overriding domain name" and "overriding item name" refer to the fully qualified name or a partial name of the overriding domain name and overriding item name, respectively. In addition to fully qualified name searches, the search function also supports wildcard searches. For example, inputting `fsm_var*::state*` will match `fsm_var_1::state_1`, `fsm_var_1::state_2`, `fsm_var_2::state_1`, and `fsm_var_2::state_2`, where `fsm_var*` is the overriding domain name and `state*` is the overriding item name. Each part can be either a fully qualified name or a partial name.

[0048] S402, the index database searches for the index identifier of the coverage field based on the coverage field name part, and sends the index identifier of the coverage field to the coverage data structure.

[0049] S403, the coverage data structure locates the corresponding target memory data structure according to the index identifier of the coverage field, and traverses the target memory data structure to search for the coverage item name part. When a matching coverage item name is found, the identifier of the coverage item is obtained; the highlight attribute bound to the target window is updated to the identifier of the coverage item; and the coverage rate of the coverage item is highlighted in the target window is triggered to be updated.

[0050] It should be noted that the system supports scenarios where users can enter only keywords in the query window to query coverage, in which case the row coverage can be retrieved.

[0051] In one implementation, S400 further includes a row coverage lookup step:

[0052] S41, based on the keywords entered by the user in the visual query window, find the original design file containing the keywords, its unique identifier, and the line number where the keywords are located in the original design file; send the unique identifier and line number of the original design file to the index database.

[0053] S42, the index database finds the identifier of the row coverage field based on the unique identifier and line number of the original design file, and sends the identifier of the row coverage field to the coverage data structure.

[0054] S43, the coverage data structure updates the highlight attribute bound to the target window to the identifier of the row coverage area; and triggers an update of the coverage of the highlighted row coverage area in the target window.

[0055] It should be noted that users can directly select the target object in the source code window to check the coverage.

[0056] In one implementation, S400 further includes the step of directly obtaining the coverage based on the target object selected by the user in the source code window:

[0057] S4100: Obtain the line number of the target object selected by the user in the source code window in the original design file and the unique identifier of the current original design file; send the unique identifier and line number of the original design file to the index database.

[0058] S4200, the index database finds the identifier of the row coverage field based on the unique identifier and line number of the original design file, and sends the identifier of the row coverage field to the coverage data structure.

[0059] S4300, the coverage data structure updates the highlight attribute bound to the target window to the identifier of the row coverage area; and triggers an update of the coverage of the highlighted row coverage area in the target window.

[0060] In summary, this invention provides a method for managing a coverage-based index database. It loads the raw coverage data from the coverage database into the runtime memory of the coverage visualization system and constructs a coverage data structure. Simultaneously, it extracts design hierarchy information from the coverage database to create an index database composed of multiple index tables. When a user initiates a query request in the visualization query window, the corresponding coverage domain identifier is first obtained from the index database. Then, the search scope is narrowed using these coverage domain identifiers, and the final result is displayed visually. The index tables for different types of coverage metrics not only narrow the search scope but also allow for parallel execution of searches for different coverage metrics, significantly improving search efficiency and reducing latency; thus achieving real-time search functionality.

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

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

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

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

[0065] 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 method for managing an index database based on coverage, characterized in that, The method comprises the following steps: S100, obtaining a coverage database storing original coverage data generated by a simulation tool; S200, loading the original coverage data in the coverage database into a running memory of a coverage visualization system, and constructing a coverage data structure in the running memory; wherein, when constructing the coverage data structure, the coverage of each module and the coverage of each coverage domain are aggregated and stored according to the original coverage data; S300, extracting design hierarchy information in the coverage database, and establishing an index database according to the extracted design hierarchy information, the index database comprising a design module index table and N coverage domain index tables of different coverage indicators; wherein, the design hierarchy information comprises index information of modules and instances, and index information of coverage domains of different coverage indicators; wherein, each coverage domain index table of each coverage indicator established does not comprise an identifier of a coverage item; wherein, the design module index table comprises a full name of a module, a type identifier of a design module, and a globally unique identifier of the design module; wherein, the N coverage domain index tables of different coverage indicators comprise a line coverage domain index table, a conditional coverage domain index table, a finite state machine coverage domain index table, a flip coverage domain index table, and an assertion coverage domain index table; the line coverage domain index table comprises a globally unique identifier of a design module, a globally unique identifier of an original design file, a line number of a line coverage domain in the original design file, and an identifier of the line coverage domain; the conditional coverage domain index table, the finite state machine coverage domain index table, and the flip coverage domain index table have the same structure, and each comprises a globally unique identifier of a design module, a coverage domain name, and an identifier of the coverage domain; the assertion coverage domain index table comprises an assertion coverage domain name, an assertion type, and an identifier of the assertion coverage domain; S400, the coverage visualization system comprises a visualization query window, when the visualization query window initiates a query request, the index database queries a target object identifier according to the query request, processes in the coverage data structure according to the identifier, and updates a target window of the coverage visualization system; wherein, the target object is a module or a coverage domain; wherein, the query request is generated according to a query condition input by a user in the visualization query window, and the query condition is an instance name; or, a globally unique identifier of a design module and a name of a coverage domain; the step of processing in the coverage data structure according to the identifier and updating the target window of the coverage visualization system in S400 further comprises: the coverage data structure updates a highlight attribute bound to the target window to the identifier of the target object, and triggers updating of coverage of the target object highlighted in the target window; wherein, in an exclusion mode, the coverage data structure updates an exclusion attribute bound to the target window to the identifier of the target object, so that an exclusion option is displayed on the target object in the target window when the updating is triggered.

2. The method of claim 1, wherein, In S400, the query condition is a coverage item search condition, and the coverage item search condition is a full name including a coverage domain part and a coverage item part; S400 further includes a coverage rate search step of a coverage item: S401, after obtaining the coverage item search condition input by the user through the visual query window, the coverage item search condition is split into a coverage domain name part and a coverage item name part; The coverage domain name part is sent to the index database, and the coverage item name part is sent to the coverage rate data structure; S402, the index database searches according to the coverage domain name part to obtain the index identification of the coverage domain, and sends the index identification of the coverage domain to the coverage rate data structure; S403, the coverage rate data structure locates the corresponding target memory data structure according to the index identification of the coverage domain, and searches the coverage item name part in the target memory data structure, and obtains the identification of the coverage item when the matching coverage item name is found; the highlight attribute bound to the target window is updated to the identification of the coverage item; and the coverage rate of the coverage item highlighted in the target window is triggered to be updated.

3. The method of claim 1, wherein, S400 further includes a line coverage search step: S41, according to the keyword input by the user in the visual query window, the original design file including the keyword and its unique identification and the line number of the keyword in the original design file are found; The unique identification and line number of the original design file are sent to the index database; S42, the index database searches according to the unique identification and line number of the original design file to obtain the identification of the line coverage domain, and sends the identification of the line coverage domain to the coverage rate data structure; S43, the coverage rate data structure updates the highlight attribute bound to the target window to the identification of the line coverage domain; And the coverage rate of the line coverage domain highlighted in the target window is triggered to be updated.

4. The method of claim 1, wherein, S400 further includes a step of directly obtaining the coverage rate according to the target object selected by the user: S4100, obtaining the line number of the target object selected by the user in the source code window in the original design file and the unique identification of the original design file at present; The unique identification and line number of the original design file are sent to the index database; S4200, the index database searches according to the unique identification and line number of the original design file to obtain the identification of the line coverage domain, and sends the identification of the line coverage domain to the coverage rate data structure; S4300, the coverage rate data structure updates the highlight attribute bound to the target window to the identification of the line coverage domain; And the coverage rate of the line coverage domain highlighted in the target window is triggered to be updated.

5. A non-transitory computer-readable storage medium having stored therein at least one instruction or at least one piece of program, characterized in that, The at least one instruction or the at least one program is loaded and executed by the processor to realize the method of any one of claims 1-4.

6. An electronic device, comprising: The processor and the non-transitory computer readable storage medium of claim 5 are included.

Images