Code coverage rate processing method, electronic equipment and medium

By setting up an API interface in the EDA system to obtain and parse the information of the code coverage object and generate a multi-dimensional database, the problems of low code coverage processing efficiency and high resource consumption are solved, and efficient code coverage processing is achieved.

CN120561019APending Publication Date: 2025-08-29METAX INTEGRATED CIRCUITS (SHANGHAI) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510726847.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-06-03
Publication Date
2025-08-29

AI Technical Summary

Technical Problem

The existing electronic design automation (EDA) system cannot effectively retain historical data of code coverage, resulting in low code coverage processing efficiency and high resource consumption.

Method used

By setting a preset API interface, obtaining text information of the code coverage object, analyzing attribute information and operation information, generating metadata, and storing it in a script file, building the first, second and third databases to merge the coverage information in different dimensions, and finally displaying the form of code coverage based on these databases.

Benefits of technology

It improves the processing efficiency of code coverage, reduces resource consumption, and achieves fast and efficient code coverage processing.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120561019A_ABST
    Figure CN120561019A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of chips, in particular to a code coverage rate processing method, electronic equipment and a medium, and the method comprises the steps: S1, designing a test case in a running regression test based on a to-be-tested chip, and obtaining text information corresponding to each code coverage object; s2, analyzing the attribute information, obtaining chip level information and code coverage rate types corresponding to each code coverage object, analyzing the operation information, and obtaining a regression test sequence number, regression test time and an operation result corresponding to each code coverage object; s3, generating metadata corresponding to each code coverage object, and storing the metadata in a preset script file; s4, analyzing metadata in a preset script file to generate a first database, a second database and a third database; and S5, displaying the form of the code coverage rate. The processing efficiency of the code coverage rate is improved, and resource consumption in the processing process of the code coverage rate is reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of chip technology, and in particular to a method for processing code coverage, an electronic device, and a medium. Background Art

[0002] Code coverage is a key indicator for measuring test adequacy, and is used to help ensure that different aspects of hardware design are fully tested. Existing Electronic Design Automation (EDA) does not provide relevant interfaces and cannot retain historical data on code coverage. It can only generate a corresponding HyperText Markup Language (HTML) file based on the code coverage generated each time, and then use professional tools to open the HTML file to obtain the code coverage for processing. The process of processing code coverage is slow and requires a lot of resources. Therefore, how to improve the processing efficiency of code coverage and reduce resource consumption in the process of code coverage processing has become a technical problem that needs to be solved urgently. Summary of the Invention

[0003] The present invention aims to provide a method, electronic device and medium for processing code coverage, thereby improving the processing efficiency of code coverage and reducing resource consumption during the processing of code coverage.

[0004] According to a first aspect of the present invention, a method for processing code coverage is provided, comprising:

[0005] Step S1: Run the test cases in the regression test based on the chip design under test, and obtain the text information corresponding to each code coverage object through a preset API interface. The text information corresponding to the code coverage object includes attribute information and operation information corresponding to the code coverage object;

[0006] Step S2: parse the attribute information corresponding to each code coverage object, obtain the chip level information and code coverage type corresponding to each code coverage object, parse the running information corresponding to each code coverage object, obtain the regression test sequence number, regression test time and running result corresponding to each code coverage object, and the code coverage types include code line, branch, state machine and assertion;

[0007] Step S3: Generate metadata corresponding to each code coverage object based on the regression test serial number, regression test time, chip level information, code coverage type, and running results corresponding to each code coverage object, and store the metadata corresponding to each code coverage object in a preset script file;

[0008] Step S4: Parse the metadata in the preset script file to generate a first database, a second database, and a third database. The first database is used to store coverage information corresponding to each coverage object. The second database is used to store coverage information after coverage objects are merged in the time dimension. The third database is used to store coverage information after coverage objects are merged in the spatial dimension.

[0009] Step S5: Display the form of code coverage based on the first database, the second database, and the third database.

[0010] According to a second aspect of the present invention, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to execute the method described in the first aspect of the present invention.

[0011] According to a third aspect of the present invention, a computer-readable storage medium is provided, storing computer-executable instructions, wherein the computer instructions are used to execute the method according to the first aspect of the present invention.

[0012] The present invention has significant advantages and beneficial effects compared to the prior art. By utilizing the above technical solution, the code coverage processing method, electronic device, and medium provided by the present invention can achieve considerable technological advancement and practicality, and have wide industrial application value, and at least have the following beneficial effects:

[0013] The present invention obtains the text information corresponding to each code coverage object by setting a preset API interface, then extracts metadata based on the text information corresponding to each code coverage object to generate a preset script file, generates databases of different dimensions based on the preset script file, and displays the form of code coverage based on the databases of different dimensions. The present invention processes code coverage by constructing a database, thereby improving the processing efficiency of code coverage and reducing resource consumption in the processing process of code coverage. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0015] Figure 1 Flowchart of a method for processing code coverage provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0016] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making any creative efforts shall fall within the scope of protection of the present invention.

[0017] The embodiment of the present invention provides a method for processing code coverage, such as Figure 1 Shown, including:

[0018] Step S1: Based on the test cases in the regression test run of the chip under test, the text information corresponding to each code coverage object is obtained through a preset application program interface (API). The text information corresponding to the code coverage object includes attribute information and operation information corresponding to the code coverage object.

[0019] The attribute information corresponding to the code coverage object includes the chip-level information and code coverage type corresponding to the code coverage object. The operation information corresponding to the code coverage object includes the regression test sequence number, regression test time, and operation result corresponding to the code coverage object. The embodiment of the present invention obtains the text information corresponding to each code coverage object by setting a preset API interface, and then generates a database by processing the text information corresponding to each code coverage object.

[0020] Step S2: parse the attribute information corresponding to each code coverage object, obtain the chip level information and code coverage type corresponding to each code coverage object, parse the running information corresponding to each code coverage object, obtain the regression test serial number, regression test time and running results corresponding to each code coverage object, and the code coverage types include code lines, branches, state machines and assertions.

[0021] The running results include pass, fail and uncertain.

[0022] Step S3: Generate metadata corresponding to each code coverage object based on the regression test serial number, regression test time, chip level information, code coverage type and running results corresponding to each code coverage object, and store the metadata corresponding to each code coverage object in a preset script file.

[0023] It is understood that the metadata corresponding to each code coverage object includes the regression test sequence number, regression test time, chip-level information, code coverage type, and run results of the code coverage object, stored in a format recognizable by a preset script format. Preset script types can include Python, Perl, Ruby, Rust, Ymal, etc.

[0024] Step S4: parse the metadata in the preset script file to generate a first database, a second database, and a third database. The first database is used to store the coverage information corresponding to each coverage object, the second database is used to store the coverage information of the coverage objects after being merged in the time dimension, and the third database is used to store the coverage information of the coverage objects after being merged in the spatial dimension.

[0025] Step S5: Display the form of code coverage based on the first database, the second database, and the third database.

[0026] It should be noted that databases based on different dimensions can generate code coverage in different dimensions for display.

[0027] As an implementation, step S1 includes:

[0028] Step S11: Obtain the chip design code to be tested and target test case reconstruction information, wherein the target test case reconstruction information includes user identification, configuration information of the design to be tested, operating parameters, number of cycles, test case group and operating time.

[0029] Step S12: Generate test cases required for chip regression testing based on the target test case reconstruction information.

[0030] Step S13: compile the chip design code to generate an executable file of the chip design to be tested.

[0031] Step S14: Run the test cases required for chip regression testing in parallel based on the executable file of the chip to be tested, and generate a test case running record. The test case running record includes a running log and a running result. The running result is generated based on the running log, and the running result includes success, failure and uncertainty.

[0032] As an embodiment, in step S11, the target test case reconstruction information is {C0, (C1, B1), (C2, B2), ..., (C n ,B n ),...,(C N ,B N )}, C0 is the shared test case configuration information corresponding to the chip design under test, C nThe shared test case configuration information corresponding to the nth sub-design of the chip under test, B n The nth group of test case reconstruction information list for the chip under test design, n ranges from 1 to N, N is the total number of sub-designs of the chip under test design, B n ={F1 n ,F2 n ,...,F i n ,...,F a(n) n}, F i n Reconstruct the information of the i-th test case in the n-th test case reconstruction information list. The value of i ranges from 1 to a(n), and a(n) is B n The total number of corresponding test case reconstruction information.

[0033] As an example, each F i n Including one or more of user identification, configuration information of the design to be tested, operating parameters, number of cycles, test case group and running time; C0, C n Including one or more of the design configuration information to be tested, operating parameters, number of cycles and running time. It should be noted that the user identifier and test case group are maintained separately for each test case reconstruction information. The design configuration information to be tested, operating parameters, number of cycles and running time can be used as shared test case configuration information, that is, the design configuration information to be tested, operating parameters, number of cycles and running time of the test cases can be set in batches through the test case configuration information. Among them, the number of cycles is set according to the specific test regression requirements, for example, it is set to 10 times or 20 times. The running time can be specifically set to execute within a preset time interval or once every preset time period. The preset time interval can specifically be daytime period, nighttime period, morning period, afternoon period, etc. The preset time period can specifically be one day, one week, etc.

[0034] As an embodiment, the configuration information of the design to be tested is used to set the composition form of each component of the chip design to be tested, and the composition form includes a first form and a second form, the first form is a form including component ports and internal logic, and the second form is a form including only component ports. Taking the design to be tested as an example including the first component, the second component, the third component and the fourth component, assuming that the object to be verified is the first component, then the corresponding configuration information of the design to be tested is to set the first component to the first form, and the second component, the third component and the fourth component to the second form. Assuming that the verification object is the interaction between the first component and the second component, then the first component and the second component are set to the first form, and the third component and the fourth component are set to the second form.

[0035] As an embodiment, the design configuration information to be tested includes master configuration information and multiple slave configuration information. The master configuration information is the configuration information with the highest frequency of use. When no information is specified in the design configuration information to be tested, the master configuration information is set by default. When slave configuration information needs to be set, the corresponding slave configuration information needs to be specified in the design configuration information to be tested. By setting the master configuration information and multiple slave configuration information, the default configuration can be directly used in most scenarios, further improving the efficiency of constructing the target test case reconstruction structure, thereby improving the efficiency of test case generation.

[0036] As an embodiment, the operating parameters include environment variables, variables required by the preset script, and options that need to be passed to the electronic design automation (EDA) tool during the chip test case running process, wherein the environment variables can specifically be Linux environment variables, the preset script is a script for executing the chip test case, and the script type can specifically be Python, Perl, Ruby, Rust, Ymal, etc.

[0037] As an embodiment, the test case group includes at least one test case, and the test case group is divided based on chip functional characteristics or based on running time period. Based on chip functional characteristics, test cases that verify the same chip functional characteristics under the same design configuration information to be tested can be divided into one test case group. In order to improve resource utilization, it is also possible to divide the test cases with the same or similar running time into one test case group based on running time period.

[0038] As an embodiment, the test case group further includes a first identifier and a second identifier. If the first identifier is set, the current regression test process needs to generate test cases in the test case group. If the second identifier is set, the current regression test process does not need to generate test cases in the test case group. By setting the test case group identifier, flexible configuration of regression testing can be achieved. When a test case group does not need to participate in the current regression, the test case group can be set to the second identifier without deleting the test case group. When the test case group is needed in a subsequent regression test process, the test case group only needs to be set to the first identifier.

[0039] It should be noted that multi-level shared test case configuration information is set in the target test case reconstruction structure, which reduces the maintenance amount of test case configuration information and facilitates global changes of the same test case configuration information, thereby reducing the error rate.

[0040] As an embodiment, step S12 includes:

[0041] Step S121: parse the target test case reconstruction structure to obtain C0, and then obtain each C in parallel. n and B n .

[0042] It should be noted that, by reconstructing the structure based on the target test case, the shared test case configuration information only needs to be parsed once and can maintain consistency, which improves the efficiency of test case construction and avoids errors.

[0043] Step S122, parallel analysis of each B n , get each F i n .

[0044] Step S123: Based on each F i n 、F i n Corresponding C n , C0 generates all chip test cases for the chip design to be tested.

[0045] As an embodiment, step S123 includes:

[0046] Step S1231: Get F i n Corresponding user ID and test case group {T1 in ,T2 in ,...,T j in ,,...,T b(in) in}, T j inF i n The corresponding j-th test case information, j ranges from 1 to b(in), b(in) is F i n The number of test cases in the corresponding test case group.

[0047] It is understandable that when i and n take different values, the corresponding value of b(in) may also be different.

[0048] Step S1232: If F i n If there are preset parameters in the i n The preset parameters in are determined as T j in Corresponding target parameters, otherwise, execute step S1233, the preset parameters are the design configuration information to be tested, operating parameters, number of cycles, test case group or running time.

[0049] It should be noted that each F i n The user ID and test case group must be set. The design configuration information to be tested, running parameters, number of cycles, test case group or running time can be set or not. If not set, it will be generated based on the shared test case configuration information.

[0050] Step S1233: If C n If there are preset parameters in the n The preset parameters in are determined as T j in Corresponding target parameters, otherwise, execute step S1234.

[0051] Step S1234: If a preset parameter is set in C0, the preset parameter of C0 is determined as T j in If the target parameter is correct, execute step S1235; otherwise, generate a prompt message and end the process.

[0052] Through steps S1232 to S1234, when F i n When preset parameters are set in F i n Set the preset parameters as target parameters. The preset parameters can be one or more of the following: the configuration information of the design to be tested, the operating parameters, the number of cycles, the test case group, and the operating time. i n If there is no preset parameter in the n Find the corresponding preset parameters in C, if they exist,n The preset parameters in are determined as the corresponding target parameters. n If it does not exist in C0, the preset parameters corresponding to the settings in C0 are determined as the target parameters. It can be seen that the preset parameters that work on the global design under test are set in C0, and the preset parameters that work on the sub-design of the design under test are set in C n In the test case reconstruction information of each group of personalized i n In , multi-level configuration of test case reconstruction information is implemented.

[0053] Step S1235: Based on each T j in , each T j in The corresponding user ID and each T j in All target parameters corresponding to each T j in Corresponding test cases.

[0054] As an embodiment, step S14 includes:

[0055] Step S141: Test cases required for chip regression testing x Assign the corresponding number of CPUs P x And memory storage space Q x , the value of x ranges from 1 to X, where X is the total number of test cases required for chip regression testing.

[0056] Step S142: Design an executable file based on the chip to be tested and run all t x , generating each run t x The corresponding test case running record, the running log includes the actual number of CPUs required for running P1 x And the actual memory storage space required Q1 x .

[0057] Step S143: When t x When the corresponding test case running records reach R, get the R records closest to the current one. x P1 in the corresponding test case run record x The data P2 after rounding the mean x and Q1 x The mean of the rounded data Q2 x , P x Updated to P x =P2 x +P0 x , Q x Updated to Qx =Q2 x +Q0 x , P0 x Q0 is the preset CPU quantity adjustment value. x is the preset memory storage space adjustment value, and R is the preset test case running record accumulation threshold.

[0058] Through steps S141 to S143, the resources allocated to the test case can be dynamically adjusted based on the actual running status of the test case, thereby avoiding resource waste and improving resource utilization.

[0059] The step S14 further includes:

[0060] Step C141: Get test case t x In the corresponding run log text information, the value of x ranges from 1 to X, where X is the total number of test cases.

[0061] Step C142: In the order from front to back, x Read the G1 line text information from the corresponding running log text information, parse the currently read G1 line text information to obtain t x Corresponding test information, G1 is the preset first read row number.

[0062] It should be noted that the test information is usually located at the head of the log text information, and the number of G1 lines can cover t x Corresponding test information, so first follow the order from front to back from t x Read G1 lines of text information from the corresponding operation log text information. The information containing the operation results is usually located at the back of the operation log text, so the text is subsequently read from the back to the front for analysis. However, if the number of log text lines is less than or equal to G1, all the operation log text information has been read out in step C142. It can be understood that when the number of log text lines is less than or equal to G1, step C142 will read t x All lines of the corresponding run log text information are read out.

[0063] As an example, t x The corresponding test information includes t x The corresponding chip design name to be tested, t x The corresponding chip design configuration and t x The corresponding test case name.

[0064] Step C143: Determine the current t xCheck whether there are any unread text lines in the corresponding operation log text information. If so, execute step C144. Otherwise, use the currently read G1 line of text information as the current text to be analyzed and execute step C145.

[0065] It should be noted that when the number of log text information lines is less than or equal to G1, the G1 line text information currently read refers to all text line information corresponding to the running log text information.

[0066] Step C144: In order from back to front, x Read G2 lines of text information from the unread text lines in the corresponding operation log text information, take the currently read G2 lines of text information as the current text to be analyzed, and execute step C145, where G2 is a preset second number of read lines.

[0067] It should be noted that if the number of unread text lines in the running log text information is greater than or equal to G2, the text information of line G2 currently read is t x The corresponding running log text information is read from the back to front in the unread text line G2 line text information. If the number of unread text lines in the running log text information is less than G2, the currently read G2 line text information is t x All remaining text lines in the corresponding run log text information. G2 and G1 may be equal or unequal. The specific data is set according to the specific application scenario.

[0068] Step C145: Scan the current text to be analyzed line by line in the order from back to front. If a preset failed text mark appears, determine t x If the result of the operation is not passed, then execute step C146.

[0069] Step C146: Determine the current t x Check whether there is any unread text line in the corresponding operation log text information. If so, return to step C144. Otherwise, determine t x The result of running is passed.

[0070] Steps C141 to C146 of the embodiment of the present invention do not need to obtain the file size of the operation log text information, and obtain test information by reading the operation log text information from front to back, and obtain the preset failure text identifier by reading the operation log text information from back to front. For most operation log text information files, there is no need to obtain the entire operation log text information file, and the operation result can be accurately and quickly determined to be a failure.

[0071] As an embodiment, step C145 includes:

[0072] Step C1451: Set the line number g to be processed as g = 1, and the total number of lines of the current text to be analyzed is G3.

[0073] It can be understood that in different cases, the total number of lines of the current text to be analyzed may be different, it may be G1, or it may be G2, or it may be less than G1, or it may be less than G2.

[0074] Step C1452: Obtain the g-th line text in the current text to be analyzed in the reverse order, perform word segmentation on the g-th line text to obtain the word segmentation corresponding to the g-th line text. If there is a word segmentation with a preset failure text identifier, determine that x the running result is not passed; otherwise, execute Step C1453.

[0075] Among them, the word segmentation with the preset failure text identifier can be specifically set to "error". It should be noted that in the application scenario of this embodiment of the present invention, as long as the word segmentation with the preset failure text identifier appears in the running log text information, it can be determined that the running result is not passed.

[0076] Step C1453: Compare g and G3. If g = G3, execute Step C146; if g < G3, set g = g + 1 and return to Step C1452.

[0077] In some cases, the word segmentation with the preset failure text identifier may be distributed in two lines. In this case, the word segmentation with the preset failure text identifier cannot be recognized only through Steps C1451 - Step C1453, which may lead to misjudgment. To avoid the above situation, as an embodiment, Step C145 includes:

[0078] Step D1451: Based on the preset failure text identifier, set the candidate word segmentation combinations {(A1, D1), (A2, D2),..., (A z , D z ),..., (A Z , D Z )}, (A z , D z ) is the z-th group of candidate word segmentation combinations, the value range of z is from 1 to Z, Z is the total number of candidate word segmentation combinations, the total number of characters of the preset failure text identifier is Z + 1, A z and D z are spliced to form the preset failure text identifier, set the line number g to be processed as g = 1, and the total number of lines of the current text to be analyzed is G3.

[0079] Among them, taking the word segmentation with the preset failure text identifier set as "error" as an example, {(A1, D1), (A2, D2),..., (A z , D z ),..., (A Z,D Z )} is {(e,rror),(er,ror),(err,or),(erro,r)}.

[0080] Step D1452: Obtain the g-th line text in the currently to-be-analyzed text in reverse order, perform word segmentation on the g-th line text to obtain the word segmentation corresponding to the g-th line text. If there is a word segmentation with a preset failure text identifier, determine that t x The running result is not passed. Otherwise, execute step D1453.

[0081] Step D1453: Determine whether the first word segmentation is one of {(A1,D1),(A2,D2),...,(A z ,D z ),...,(A Z ,D Z )} where D z , if so, set this D z as the target D z , set the A z corresponding to the target D z as the target A z , set g = g + 1, execute step D1454. Otherwise, execute step D1455.

[0082] Step D1454: If g ≤ G3, obtain the g-th line text in the currently to-be-analyzed text in reverse order. If g = G3 + 1, obtain the first unread text line in the running log text information corresponding to the current t x as the g-th line text, perform word segmentation on the g-th line text to obtain the word segmentation corresponding to the g-th line text. If the last word segmentation corresponding to the g-th line text is the target A z and / or there is a word segmentation with a preset failure text identifier in the g-th line text, determine that t x The running result is not passed. Otherwise, execute step D1455.

[0083] Step D1455: Compare g and G3. If g = G3, execute step C146. If g < G3, set g = g + 1 and return to step D1452.

[0084] It should be noted that through steps D1451 - D1455, all the word segmentations with preset failure text identifiers in the currently to-be-analyzed text can be accurately analyzed, improving the accuracy of running result recognition.

[0085] As an embodiment, in step S4, parse the metadata in the preset script file to generate a first database, including:

[0086] Step S41: Generate a test record corresponding to each code coverage object based on the regression test serial number, regression test time, chip level information corresponding to the code coverage object, code coverage type, and running result corresponding to each code coverage object.

[0087] Step S42: Store the test records corresponding to all code coverage objects in the first database in sequence.

[0088] It should be noted that the first database stores test records from the dimension corresponding to each coverage object.

[0089] As an embodiment, the chip under test design includes multiple component modules, where the component modules are SOC (System on Chip) top layers or IP (Intellectual Property), and the SOC chip is composed of the SOC top layer and multiple IPs. In the second database, a storage area is set for each set of regression sequence number, component module, and code coverage type. In step S4, generating the second database includes:

[0090] Step C41: Get the test record corresponding to the newly added code coverage object in the first database. y ,TD y ,TH y ,TY y ,TE y}, where TR y The regression test number corresponding to the newly added code coverage object, TD y The regression test time corresponding to the newly added code coverage object, TH y The chip level information corresponding to the newly added code coverage object, TY y The code coverage type corresponding to the newly added code coverage object, TE y is the running result corresponding to the newly added code coverage object, the value range of y is 1 to Y, and Y is the total number of test records corresponding to the code coverage object in the first database.

[0091] Step C42: Analyze TH y , determine TH y Corresponding component module IQ y , based on TR y TY y and I.Q. y Determine the target storage area.

[0092] It should be noted that, since a storage area is set for each set of regression sequence number, component module and code coverage type in the second database, step C42 can be based on TR y TY yand IQ y Determine the target storage area.

[0093] Step C43: Obtain the records to be stored currently in the target storage area {TR y , TD y , SA y , SC y , SE y}, where SA y is the cumulative number of passed coverage items corresponding to the current target area, SC y is the total number of coverage items corresponding to the current target area, SE y is the code coverage rate corresponding to the current target area, SE y = SA y / SC y , if TE y is passed, then SA y = SA y-1 + 1, if TE y is not passed, then SA y = SA y-1 , SA y-1 is the cumulative number of passed coverage items in the previous stored record in the target storage area.

[0094] It should be noted that SE y corresponds to the merged (merge) coverage rate of the coverage items corresponding to each group of regression serial numbers, component modules, and code coverage types, and shows the merged coverage information in the time dimension.

[0095] Step C44: Store {TR y , TD y , SA y , SC y , SE y} into the target storage area. If y < Y, then return to Step C41. If y = Y, then generate the second database.

[0096] As an embodiment, in the step S4, generating the third database includes:

[0097] Step D41: Initially set the regression test serial number value f = 2.

[0098] Step D42: Obtain the component module coverage information {SOC y = f, in the second database when TR y = f - 1 corresponding to f-1 , IP1 f-1 , IP2 f-1 ,..., IP w f-1,...IP W f-1}, SOC f-1 To measure the code coverage corresponding to each code coverage type for the f-1th regression test of the SOC top layer in the chip design, IP w f-1 To measure the code coverage corresponding to each code coverage type for the f-1th regression test of the wth IP in the chip design, where the value range of w is from 1 to W, and W is the total number of IPs in the chip design.

[0099] It should be noted that {SOC f-1 , IP1 f-1 , IP2 f-1 ,..., IP w f-1 ,... IP W f-1} shows the merged coverage information in the spatial dimension.

[0100] Step D43: If f = 2, then directly store {SOC f-1 , IP1 f-1 , IP2 f-1 ,..., IP w f-1 ,... IP W f-1} into the third database. If f > 2, then execute step D44.

[0101] Step D44: Update SOC f-1 to the result of the merger of SOC f-1 and SOC f-2 , update IP w f-1 to the result of the merger of IP w f-1 and IP w f -2 Store the updated {SOC f-1 , IP1 f-1 , IP2 f-1 ,..., IP w f-1 ,... IP W f-1} into the third database.

[0102] Step D45: If f = F, then generate the third database. If f < F, then set f = f + 1, and return to execute step D42, where F is the total number of regression tests.

[0103] As an embodiment, the step S5 includes:

[0104] Step S51: Based on the data in the second database, with time as the horizontal axis and the code coverage corresponding to the target component module under the target regression sequence as the vertical axis, a coverage change curve of the target component module under the target regression sequence is constructed on a preset display interface.

[0105] It should be noted that the coverage variation trend of the target component module can be obtained in real time through the coverage variation curve of the target component module under the target regression sequence number.

[0106] As an embodiment, step S5 includes:

[0107] Step C51: Based on the data in the second database, the code coverage corresponding to at least one target component module is displayed in real time on a preset display interface under a target regression sequence number.

[0108] It should be noted that, through step C51 , the code coverage corresponding to each target component module can be displayed in real time.

[0109] Step C52: Compare the code coverage corresponding to the displayed target component module with the corresponding code coverage threshold, and highlight the code coverage corresponding to the target component module that is lower than the corresponding code coverage threshold.

[0110] It should be noted that the code coverage threshold is set according to specific application requirements. The code coverage corresponding to the target component module below the corresponding code coverage threshold can be highlighted in a form such as highlighting or using a special color.

[0111] As an embodiment, step S5 includes:

[0112] Step D51 : Based on the data in the third database, the code coverage of each component module of the chip design under test is displayed in real time on a preset display interface according to the component architecture of the chip design under test.

[0113] As an embodiment, based on any of the above code coverage display processes, step S5 includes:

[0114] Step E51 : Based on the displayed code coverage, at least one of the regression number to be analyzed, the component module to be analyzed, the time to be analyzed, and the coverage type to be analyzed is selected.

[0115] Step E52: query the first database based on the selected information to perform code coverage analysis.

[0116] It should be noted that the first database stores test records corresponding to all code coverage objects. Therefore, based on the displayed form of the code coverage, one of the regression number to be analyzed, the component module to be analyzed, the time to be analyzed, and the coverage type to be analyzed can be selected as the index object, or based on the displayed form of the code coverage, a group of multiple components of the regression number to be analyzed, the component module to be analyzed, the time to be analyzed, and the coverage type to be analyzed can be selected as the index object. Based on the index object, the first database is queried to obtain the test records corresponding to the code coverage objects in the corresponding first database to determine the problem points.

[0117] It should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of the steps can be performed in parallel, concurrently, or simultaneously. In addition, the order of the steps can be rearranged. A process can be terminated when its operation is completed, but can also have additional steps not included in the accompanying drawings. A process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0118] An embodiment of the present invention also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are configured to execute the method described in the embodiment of the present invention.

[0119] An embodiment of the present invention further provides a computer-readable storage medium storing computer-executable instructions, wherein the computer instructions are used to execute the method described in the embodiment of the present invention.

[0120] The embodiment of the present invention obtains the text information corresponding to each code coverage object by setting a preset API interface, and then extracts metadata based on the text information corresponding to each code coverage object to generate a preset script file, generates databases of different dimensions based on the preset script file, and displays the form of code coverage based on the databases of different dimensions. The present invention processes code coverage by constructing a database, thereby improving the processing efficiency of code coverage and reducing resource consumption in the process of processing code coverage.

[0121] The above description is merely a preferred embodiment of the present invention and does not constitute any form of limitation to the present invention. Although the present invention has been disclosed as a preferred embodiment, it is not intended to limit the present invention. Any technician familiar with the present profession can make slight changes or modifications to equivalent embodiments using the technical contents disclosed above without departing from the scope of the technical solution of the present invention. However, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention are still within the scope of the technical solution of the present invention.

Claims

1. A method for processing code coverage, characterized in that: Including: Step S1: Design and run test cases in regression testing for the chip under test, and obtain the text information corresponding to each code coverage object through a preset API interface. The text information corresponding to the code coverage object includes the attribute information and running information corresponding to the code coverage object. Step S2: Analyze the attribute information corresponding to each code coverage object to obtain the chip hierarchy information and code coverage type corresponding to each code coverage object. Analyze the running information corresponding to each code coverage object to obtain the regression test serial number, regression test time, and running result corresponding to each code coverage object. The code coverage type includes code lines, branches, state machines, and assertions. Step S3: Generate metadata corresponding to each code coverage object based on the regression test serial number, regression test time, chip hierarchy information corresponding to the code coverage object, code coverage type, and running result, and store the metadata corresponding to each code coverage object in a preset script file. Step S4: Analyze the metadata in the preset script file to generate a first database, a second database, and a third database. The first database is used to store the coverage information corresponding to each coverage object. The second database is used to store the coverage information merged by the coverage objects in the time dimension. The third database is used to store the coverage information merged by the coverage objects in the space dimension. Step S5: Display the form of the code coverage rate based on the first database, the second database, and the third database.

2. The method according to claim 1, wherein in step S4, analyzing the metadata in the preset script file to generate a first database includes: Step S41: Generate a test record corresponding to the code coverage object based on the regression test serial number, regression test time, chip hierarchy information corresponding to the code coverage object, code coverage type, and running result. Step S42: Store the test records corresponding to all code coverage objects in the first database in sequence.

3. The method according to claim 1, wherein the design of the chip under test includes multiple component modules, and the component modules are the SOC top layer or IP. In the second database, a storage area is set for each set of regression serial numbers, component modules, and code coverage types. In step S4, generating the second database includes: Step C41: Get the test record corresponding to the newly added code coverage object in the first database. y ,TD y ,TH y ,TY y ,TE y }, where TR y The regression test number corresponding to the newly added code coverage object, TD y The regression test time corresponding to the newly added code coverage object, TH y The chip level information corresponding to the newly added code coverage object, TY y The code coverage type corresponding to the newly added code coverage object, TE y is the running result corresponding to the newly added code coverage object, the value of y ranges from 1 to Y, and Y is the total number of test records corresponding to the code coverage object in the first database; Step C42: Analyze TH y , determine TH y Corresponding component module IQ y , based on TR y TY y and I.Q. y Determine the target storage area; Step C43: Get the current record to be stored in the target storage area. y ,TD y ,SA y ,SC y ,SE y }, where SA y The cumulative number of coverage items corresponding to the current target area passed, SC y is the total number of coverage items corresponding to the current target area, SE y is the code coverage corresponding to the current target area, SE y =SA y / SC y , if TE y If it is passed, then SA y =SA y-1 +1 if TE y If it fails, SA y =SA y-1 , SA y-1 The cumulative number of coverage items in the last stored record in the target storage area; Step C44: Store {TR y , TD y , SA y , SC y , SE y} in the target storage area. If y < Y, return to Step C41. If y = Y, generate the second database.

4. The method according to claim 1, wherein in step S4, generating the third database includes: Step D41: Initially set the regression test serial number value f = 2. Step D42: Get the current TR y =f, TR in the second database y =f-1 corresponding component module coverage information {SOC f-1 ,IP1 f-1 ,IP2 f-1 ,...,IP w f-1 ,...IP W f-1 }, SOC f-1 The code coverage of each code coverage type corresponding to the f-1 regression test of the SOC top layer for the test chip design, IP w f-1 The code coverage of each code coverage type corresponding to the f-1 regression test of the w-th IP in the test chip design. The value of w ranges from 1 to W, where W is the total number of IPs in the test chip design. Step D43: If f=2, then directly convert {SOC f-1 ,IP1 f-1 ,IP2 f-1 ,...,IP w f-1 ,...IP W f-1 } is stored in the third database. If f>2, step D44 is executed; Step D44: SOC f-1 Update to SOC f-1 With SOC f-2 After the merger, IP w f-1 Update to IP w f-1 with IP w f-2 The merged result will be the updated {SOC f-1 ,IP1 f-1 ,IP2 f-1 ,...,IP w f-1 ,...IP W f-1 }Stored in the third database; Step D45: If f = F, generate the third database. If f < F, set f = f + 1, and return to execute step D42. F is the total number of regression tests.

5. The method according to claim 1, wherein step S5 includes: Step S51: Based on the data in the second database, with time as the horizontal axis and the code coverage rate corresponding to the target component module under the target regression serial number as the vertical axis, construct a coverage rate change curve of the target component module under the target regression serial number on a preset display interface.

6. The method according to claim 1, characterized in that The step S5 comprises: Step C51: Based on the data in the second database, display the code coverage corresponding to at least one target component module in real time on a preset display interface under the target regression sequence number; Step C52: Compare the code coverage corresponding to the displayed target component module with the corresponding code coverage threshold, and highlight the code coverage corresponding to the target component module that is lower than the corresponding code coverage threshold.

7. The method according to claim 1, characterized in that The step S5 comprises: Step D51 : Based on the data in the third database, the code coverage of each component module of the chip design under test is displayed in real time on a preset display interface according to the component architecture of the chip design under test.

8. The method according to claim 1, characterized in that The step S5 comprises: Step E51: Select at least one of the regression number to be analyzed, the component module to be analyzed, the time to be analyzed, and the coverage type to be analyzed based on the displayed code coverage form; Step E52: query the first database based on the selected information to perform code coverage analysis.

9. An electronic device, characterized in that: include: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are configured to execute the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that The computer-executable instructions are stored, and the computer-executable instructions are used to execute the method according to any one of the preceding claims 1 to 8.