A method for compressing and storing row coverage data, an electronic device, and a storage medium.

Abstract

This invention relates to the field of electronic design automation (EDA), and in particular to a method for compressing and storing line coverage data, an electronic device, and a storage medium. The method involves compressing and storing the i-th line record of an executable statement within a module and writing it into a line data block. The steps include: obtaining fields with default values ​​from the i-th line record; when there are n consecutive line records with default values ​​for their line offsets, filtering out fields with default values ​​from all n line records; writing the remaining fields into arrays corresponding to each field in the order of the line records; and writing all arrays into a single line data block shared by the n line records; when there are no consecutive n line records with default values ​​for their line offsets, filtering out fields with default values ​​from the i-th line record; and writing the remaining fields into the line data block of the i-th line record. This method effectively reduces the storage space occupied by line coverage data while ensuring the integrity and resolvability of the coverage data.

Description

Technical Field

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

[0002] In chip design verification, code coverage is a crucial metric for measuring verification completeness. Line coverage, a key component of code coverage, is used to statistically analyze the execution status of each line of executable code in the hardware description language source code. Current mainstream coverage databases adhere to the UCIS (Unified Coverage Interoperability Standard), creating a structured record for each line of executable code, including a unique identifier (ID), line type, source file location information, line start and end numbers, and column start and end numbers. While this storage method fully preserves the semantic information of coverage data and supports cross-tool data exchange and visualization analysis, it suffers from high data redundancy and significant storage overhead. Especially in modern complex chip design scenarios, design scale continues to grow, with individual design projects often containing millions or even tens of millions of lines of code, resulting in a massive number of line record entries to maintain in the coverage database. Even if a single record occupies relatively little space, the accumulated storage demand still grows linearly or even superlinearly, significantly increasing disk space usage and impacting the efficiency of archiving, transmission, and merging coverage data. Furthermore, coverage data typically needs to be continuously accumulated across multiple simulation rounds, further exacerbating space pressure with long-term storage. Although existing technologies use general compression algorithms to perform post-compression on coverage databases, their compression efficiency is limited due to the redundancy of the original data structure, and the decompression overhead is large, making it difficult to meet the dual requirements of storage performance and access efficiency in large-scale verification environments.

[0003] Therefore, how to effectively reduce the storage space occupied by row coverage data while ensuring the integrity and resolvability of coverage data has become a pressing technical problem to be solved in current coverage data storage. Summary of the Invention

[0004] To address the aforementioned technical problems, the present invention adopts the following technical solution: a method for compressing and storing row coverage data, the method comprising the steps of performing row compression storage on the i-th row record of an executable statement within a module and writing it into a row data block, wherein i is greater than 0, and including:

[0005] S100, retrieve the field with the default value from the i-th row record; the field with the default value includes one or more of the row offset and cross-row identifier.

[0006] S200: When there are n consecutive rows with the row offset set to the default value, filter out the fields in the n rows where all values ​​are set to the default value, where n is greater than 1; write the unfiltered fields into the arrays corresponding to each field in the order of the row records, and write all arrays into a row data block shared by the n rows.

[0007] S300, when there are no consecutive n row records with the default row offset, filter out the fields with the default value in the i-th row record, where n is greater than 1; write the unfiltered fields into the row data block of the i-th row record.

[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:

[0011] The embodiments of this invention provide a method, electronic device, and storage medium for compressing and storing row coverage data. This method compresses data through methods such as row offset, cross-row identifier, column offset, omitting fields with default values, and single-record storage and shared storage for multiple records, significantly reducing the storage space occupied by the stored data. It effectively reduces the storage space occupied by row coverage data while ensuring the integrity and resolvability of the coverage data. Attached Figure Description

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

[0013] Figure 1 This is a flowchart of a row coverage data compression and storage method provided in an embodiment of the present invention. Detailed Implementation

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

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

[0016] Please see Figure 1 The flowchart illustrates a method for compressing and storing row coverage data. The method includes the steps of performing row compression storage on the i-th row record of an executable statement within a module and writing it into a row data block, where i is greater than 0. The method includes:

[0017] S100, retrieve the field with the default value from the i-th row record; the field with the default value includes one or more of the row offset and cross-row identifier.

[0018] In this context, a module refers to an independent, named structural unit in a design that encapsulates related functions, data, or logic. It can typically be instantiated, connected, or simulated as a whole. Modules are the basic building blocks for hardware description and verification. In line coverage analysis, coverage focuses on the specific executable structures within a module, such as statements, expressions, or branches. Only when the simulation executes the code within a module is the corresponding behavior recorded as executed.

[0019] In this context, executable lines of code within a module refer to statements located between the `module` and `endmodule` keywords that will be executed during simulation. These statements include, but are not limited to: assignment statements (continuous assignment, procedural assignment), conditional statements (if / else), loop statements (for, while), procedural blocks (always, initial), and task and function calls. They are the primary targets for code coverage statistics (such as line coverage, condition coverage, and branch coverage). Blank lines, comment lines, and static structural descriptions such as module port declarations and variable definitions are not executable code and are typically not included in executable line coverage statistics.

[0020] In the row coverage database, the data is organized in a hierarchical structure: the top level contains multiple modules, each module further contains multiple corresponding executable code line records, and each line record corresponds to an executable code line in the source code and contains multiple fields describing the characteristics of that executable code line. These fields may include: row offset, column start position, column offset, etc.

[0021] It should be noted that existing row coverage databases store data block fields including a unique executable identifier (stmtid) for the contiguous region, coverage item type, absolute start row number, absolute end row number of the current row record, column start position, and column end position. Each field occupies a significant amount of storage space. This invention, however, compresses storage by modifying, omitting, and using fields with default values.

[0022] The line offset can be the difference between the absolute line number of the current executable line and the absolute line number of the line containing the module itself, or the difference between the absolute line number of the current executable line and the absolute line number of the previous executable line. Replacing the absolute starting line number in existing solutions with line offsets results in a smaller storage space usage compared to absolute starting line numbers.

[0023] The column offset is the offset relative to the starting position of a column in the same executable line of code.

[0024] The cross-line identifier indicates whether the current executable line occupies two or more consecutive lines. It's important to note that in most cases, the beginning and end lines of an executable line have the same line number, eliminating the need to record duplicate line numbers for every line. Therefore, replacing the absolute end line number in the existing solution with a cross-line identifier requires less storage space compared to using absolute end line numbers.

[0025] In one implementation, each row record includes the following fields: row offset, crossover identifier, column start position, and column offset. Common values ​​for the row offset, crossover identifier, and override type are set to default values. A field is considered a default value field when its row offset is set to the default value; otherwise, it is not. For example, if the row offset is the difference between the absolute line number of the previous executable line and the absolute line number of the previous executable line, and the majority of row offset values ​​are 1, then 1 is set as the default value for the row offset. If the crossover identifier equals 1 to indicate a crossover and equals 0 to indicate no crossover, and the majority of crossover identifier values ​​are 0, then 0 is set as the default value for the crossover identifier. The override type has a value of 24 in the UCIS standard, so 24 is set as the default value.

[0026] It should be noted that column offsets further reduce the amount of storage space used.

[0027] It should be noted that other types of fields with default values ​​also fall within the scope of protection of this invention.

[0028] In one implementation, before performing row-compressed storage on the i-th line record of the executable statements within the module, the method further includes:

[0029] S10: Parse the executable lines of the design source code to obtain multiple executable lines of code from each module. It should be noted that a design source code may contain multiple modules, and each module may contain multiple executable lines of code.

[0030] S20, in each module, the executable code lines are arranged in ascending order of absolute line number to generate a line record sequence.

[0031] In one implementation, before performing row compression storage on the i-th row record of the executable statement within the module, the method further includes: S30, traversing the row record sequence, wherein the row offset is the difference between the absolute row number of the i-th row record and the absolute row number of the previous row record; wherein, when i=1, the row offset of the first row record is equal to the difference between its absolute row number and the row number of the module itself.

[0032] In one implementation, S10 further includes: acquiring and writing the absolute line number and other fields of the module into the module data block of each module. It should be noted that the module data block is a component of the line coverage database. The line coverage database includes the module data block of each module and the line data block of each executable line of code within each module.

[0033] S200: When there are n consecutive rows with the row offset set to the default value, filter out the fields in the n rows where all values ​​are set to the default value, where n is greater than 1; write the unfiltered fields into the arrays corresponding to each field in the order of the row records, and write all arrays into a row data block shared by the n rows.

[0034] It's important to note that each executable line corresponds to one record. Even if the executable lines are physically contiguous, this still incurs some overhead. For example, if there are 100 consecutive executable lines, since the line numbers increment, only the offset of the starting line and the number of consecutive lines need to be recorded. This means that 2 bytes of data can replace the previous 100 bytes of line number information. These 100 lines of data can be compressed into a single data block. Although the column start position and column offset cannot be compressed, optimizing `stmtid` can compress the original three attribute values ​​into two attributes. The compression ratio increases with the number of consecutive lines. For example, row offset, column start position, and column offset can be compressed into column start position and column offset. Furthermore, filtering out fields with default values—that is, omitting fields with default values ​​in the data block—further reduces storage space usage, achieving compressed storage.

[0035] As an example, when the coverage database is stored in text format, assuming that the row offsets of three consecutive row records are the default values ​​and the cross-row identifiers are also the default values, the column start position of the first row record is 8 and the column offset is 92; the column start position of the second row record is 12 and the column offset is 108; the column start position of the third row record is 12 and the column offset is 98; then the row data block shared by these three row records is "cols:[8,12,12],rcol_offsets:[92,108,98]", which includes two sets of key-value pairs. One set is an array "cols" with the key as the column start position field and its value "[8,12,12]", and the other set is an array "rcol_offsets" with the key as the column offset field and its value "[92,108,98]".

[0036] In one implementation, the filtered fields also include the unique identifier of the executable statement (stmtid). According to SystemVerilog semantics, a single line of source code may contain multiple executable statements, such as using begin-end blocks or statement delimiters; therefore, the same line of code may be associated with multiple different stmtids. It should be noted that for line coverage data, the line can be uniquely identified by the file's unique identifier, the module's absolute line number, and the line offset of the executable code line; therefore, the stmtid attribute can be further optimized away.

[0037] S300, when there are no consecutive n row records with the default row offset, filter out the fields with the default value in the i-th row record, where n is greater than 1; write the unfiltered fields into the row data block of the i-th row record.

[0038] It should be noted that when there are no consecutive n row records and the row offset is the default value, it is a single row record, and the corresponding data block is a single row record data block.

[0039] Similarly, filtering out fields that take default values ​​can further reduce the storage space occupied, achieving compressed storage.

[0040] As an example, when the coverage database is stored in text format, assuming the row offsets between the current row and the rows before and after it differ, a single row record is used. If the current row has a row offset of 2, spans multiple rows, has a column start position of 16, and a column offset of 184, then the data block for the current row is "line_offset:2,col:16, rline_offset:1,rcol_offset:184". This includes four key-value pairs: one pair with the row offset "line_offset" and its value "2", one pair with the column start position "col" and its value "16", one pair with the row span identifier "rline_offset" and its value "1", and one pair with the column offset "rcol_offset" and its value "184". When the row span identifier has a default value of 0, the row span identifier field can be omitted, and the data block after omission is "line_offset:2,col:16,rcol_offset:184".

[0041] It should be noted that for row coverage databases, all coverage item types are the same, and the value of the coverage item type is set to the default value, so the coverage item type can be directly omitted.

[0042] In one embodiment, the method further includes: S400, where the module data blocks and row data blocks of each module form a compressed and stored row coverage database.

[0043] In summary, the embodiments provided by this invention compress data by means of row offset, cross-row identifier, column offset, omitting fields with default values, compressing consecutive rows, storing single records, and sharing storage for multiple records. This significantly reduces the storage space occupied by the stored data, reduces the size of the row coverage database, solves the problem of excessive data storage space for row coverage data, and thus improves the efficiency of generating and loading the coverage database.

[0044] It's important to note that in the current scheme, the size of a field is globally defined as occupying K bytes of unsigned integer data. This results in even smaller data values ​​occupying K bytes of space, leading to some waste. For example, considering that absolute row numbers can be very large, the current scheme defines the row number data type as occupying 4 bytes of unsigned integer data. This also results in even smaller row numbers occupying 4 bytes of space, causing waste. Instead of using a generic data type, different data types should be used to store different data. By dynamically adjusting the required data type, storage space can be allocated as needed, reducing unnecessary overhead.

[0045] In one implementation, when the row coverage database is stored in binary format, the data type of each field is controlled by a control word, thereby further compressing the data volume on the basis of the already compressed storage.

[0046] In one implementation, when the storage format of the row coverage data is binary, S200 further includes: S210, adding a control word to a row data block shared by the n row records, the control word including a flag bit for the multi-row record format, a flag bit for the data type of each element in the array, and a flag bit for the data type of the number of elements in each array.

[0047] As an example, this control word occupies one byte, with the 0th bit serving as a record type flag, occupying 1 bit. A record type flag of 0 indicates a single-line record format, while a value of 1 indicates a multi-line record format. The data type of the elements in the column start array and column offset array is determined by a type flag, occupying 1 bit: when the flag is 0, the array element data type is an 8-bit unsigned integer, with a size of 1 byte; when the flag is 1, the array element data type is a 16-bit unsigned integer, with a size of 2 bytes. The data type representation of the array element count is also determined by a type flag, occupying 1 bit: when the flag is 0, the element count field data type is an 8-bit unsigned integer, with a size of 1 byte; when the flag is 1, the element count field data type is a 16-bit unsigned integer, with a size of 2 bytes.

[0048] In one implementation, when the storage format of the row coverage data is binary, S300 further includes: S310, adding a control word to the row data block of the i-th row record, the control word including a flag bit for single-row record format, a flag bit for the data type of each field in the row data block, and a flag bit for whether fields that can take default values ​​take default values.

[0049] In one implementation, in S310, the fields in the row data block include row offset, whether the current row record spans multiple rows, column start position, and column offset.

[0050] As an example, each field in the row data block includes a row offset field, a column start field, and a column offset field. Fields with default values ​​include whether to include a cross-row field and whether to include a row offset field. The whether to include a cross-row field and whether to include a row offset field each occupy 1 bit. For the whether to include a cross-row field, a bit value of 0 indicates that the current record does not have a row offset, and a bit value of 1 indicates that the current record does have a row offset. For the include row offset field, a bit value of 0 indicates that the current record does not have a cross-row identifier, and a bit value of 1 indicates that the current record includes a cross-row identifier. The data type of the row offset field is determined by a type flag bit, which occupies 2 bits: when the flag bit is 00, the data type of the array element is an 8-bit unsigned integer, and the size is 1 byte; when the flag bit is 01, the data type of the array element is a 16-bit unsigned integer, and the size is 2 bytes; when the flag bit is 10, the data type of the array element is a 64-bit unsigned integer, and the size is 4 bytes; when the flag bit is 11, the data type of the array element is a 128-bit unsigned integer, and the size is 8 bytes. The data type of the column start bit and column offset are each determined by a type flag bit, each occupying 1 bit. When the corresponding flag bit is 0, the data type of the column start bit or column offset is an 8-bit unsigned integer, and the size is 1 byte; when the corresponding flag bit is 1, the data type of the column start bit or column offset is a 16-bit unsigned integer, and the size is 2 bytes.

[0051] By using control words to precisely control the data type of each field, the storage space occupied by each row of data blocks can be precisely controlled, significantly reducing the storage space occupied and achieving the goal of compressing stored data.

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

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

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

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

[0056] 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 compressing and storing row coverage data, characterized in that, The method includes the steps of performing row compression storage on the i-th line record of the executable statement within the module and writing it into a row data block, where i is greater than 0, including: S100, retrieve the field with the default value from the i-th row record; the field with the default value includes one or more of the row offset and cross-row identifier; S200, when there are n consecutive rows with the row offset set to the default value, filter out the fields in the n rows where all values ​​are set to the default value, where n is greater than 1; write the unfiltered fields into the arrays corresponding to each field in the order of the row records, and write all arrays into a row data block shared by the n rows; S300, when there are no consecutive n row records with the default row offset, filter out the fields with the default value in the i-th row record, where n is greater than 1; write the unfiltered fields into the row data block of the i-th row record.

2. The method according to claim 1, characterized in that, Before performing row-compressed storage on the i-th line record of the executable statements within the module, the following is also included: S10, parse the executable lines of the design source code and obtain multiple executable lines of code in each module; S20, in each module, the executable code lines are arranged in ascending order of absolute line number to generate a line record sequence.

3. The method according to claim 2, characterized in that, Before performing row-compressed storage on the i-th line record of the executable statements within the module, the following is also included: S30, Traverse the row record sequence, where the row offset is the difference between the absolute row number of the i-th row record and the absolute row number of the previous row record; wherein, when i=1, the row offset of the 1st row record is equal to the difference between its absolute row number and the row number of the module itself.

4. The method according to claim 2, characterized in that, S10 further includes: obtaining and writing the absolute line number and other fields of the module into the module data block of each module respectively; the method further includes: S400, the module data blocks and their row data blocks of each module form a compressed and stored row coverage database.

5. The method according to claim 1, characterized in that, When the row coverage data is stored in binary format, the data type of each field is controlled by control words.

6. The method according to claim 1, characterized in that, When the row coverage data is stored in binary format, S200 also includes: S210, add a control word to a row data block shared by the n row records. The control word includes a flag bit for the multi-row record format, a flag bit for the data type of each element in the array, and a flag bit for the data type of the number of elements in each array.

7. The method according to claim 6, characterized in that, When the row coverage data is stored in binary format, S300 also includes: S310, add a control word to the row data block of the i-th row record. The control word includes a flag bit for single-row record format, a flag bit for the data type of each field in the row data block, and a flag bit for whether fields with default values ​​are set to default values.

8. The method according to claim 7, characterized in that, In S310, the fields in the row data block include row offset, whether the current row record spans multiple rows, column start position, and column offset.

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