Method, electronic device and storage medium for locating errors in a logic system design

Abstract

This application relates to a method, electronic device, and storage medium for locating errors in a logic system design. The method includes: testing the logic system design using multiple test cases; dividing the multiple test cases into a pass case group and a fail case group based on the test results, the test results including coverage data of the multiple test cases; determining multiple key features based at least on the coverage data of the test cases in the fail case group; and locating the error in the logic system design based on the multiple key features. This method can reduce error location time and accurately pinpoint the source of errors in the logic system design.

Description

Technical Field

[0001] This application relates to the field of error debugging technology, and in particular to a method, electronic device, and storage medium for locating errors in a logic system design. Background Technology

[0002] With the rapid development of computer technology, error debugging has become increasingly important in chip development and simulation testing. In error debugging, error localization is one of the most expensive and time-consuming activities.

[0003] Currently, error localization is typically done manually by developers, using techniques such as running the software, stepping through code, and code reviews. However, when dealing with large amounts of code and complex logic, this manual error localization method by developers is extremely time-consuming.

[0004] Furthermore, when an error occurs in a case study, the location of the error may affect the corresponding functions in other parts of the case study, causing those functions to malfunction as well. This results in low accuracy in error localization and makes it impossible to determine the source of the error. Moreover, current error localization methods heavily rely on the individual skills of the developers. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, electronic device, and storage medium for locating errors in logic system design that reduces error location time and accurately determines the source of errors in logic system design, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a method for locating errors in the design of a logic system. The method includes:

[0007] The logical system design was tested using multiple test cases.

[0008] Based on the test results, the multiple test cases are divided into a pass case group and a fail case group, and the test results include the coverage data of the multiple test cases;

[0009] At least several key features are determined based on the test case coverage data in the failed case group; and

[0010] Errors in the logic system design can be located based on the aforementioned key features.

[0011] In one embodiment, the multiple test cases have the same test pattern.

[0012] In one embodiment, determining multiple key features based at least on the coverage data of test cases in the failed case group further includes:

[0013] Determine the coverage data for multiple coverage points in the logical system design;

[0014] Several key features are determined based on the changes in coverage data of the multiple coverage points.

[0015] In one embodiment, determining multiple key features based at least on the coverage data of test cases in the failed case group further includes:

[0016] Determine multiple first features of the successful case group and multiple second features of the failed case group;

[0017] The plurality of key features are determined based on the plurality of first features and the plurality of second features.

[0018] In one embodiment, locating errors in the logic system design based on the plurality of key features further includes:

[0019] Determine multiple ranges for the logic system design corresponding to the multiple key features;

[0020] Errors in the logic system design are located based on the multiple ranges.

[0021] In one embodiment, locating errors in the logic system design based on the plurality of ranges further includes:

[0022] Determine at least one overlapping range among multiple ranges;

[0023] The error in the logic system design is located based on the overlapping range.

[0024] In one embodiment, the differences in coverage data among the plurality of test cases are within a preset first range.

[0025] In one embodiment, the data type of the coverage data includes at least: code coverage data or functional coverage data, and the code coverage includes at least: line coverage data, branch coverage data, assertion data, assignment inversion rate data or conditional assignment coverage data.

[0026] Secondly, this application also provides an electronic device. The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above-described method.

[0027] Thirdly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.

[0028] This application proposes a method, electronic device, and storage medium for locating errors in a logic system design. The method involves testing the logic system design using multiple test cases, obtaining test results, and distinguishing between a pass case group and a fail case group based on the test results. Furthermore, key features can be determined based on the coverage data of the test cases in the fail case group. Code coverage is commonly used as a metric for evaluating test quality. Therefore, when dealing with large amounts of code data and complex logic, coverage can accurately pinpoint the location of key features, thereby locating errors in the logic system design. Since code coverage is typically obtained during code coverage testing, it can be obtained during logic system testing without additional testing or manual analysis by developers, reducing the time required to locate errors. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0030] Figure 1 This is a schematic diagram of the device in the embodiments of this application;

[0031] Figure 2A This is a schematic diagram of the debugging system in an embodiment of this application;

[0032] Figure 2B This is a schematic diagram of the test environment designed for the logic system in the embodiments of this application;

[0033] Figure 3A This is a schematic diagram illustrating the grouping of multiple test cases in the embodiments of this application;

[0034] Figure 3B This is a schematic diagram illustrating the design scope in the embodiments of this application;

[0035] Figure 3C This is a schematic diagram of the overlapping range in the embodiments of this application;

[0036] Figure 4 This is a flowchart illustrating a method for locating errors in the logic system design in an embodiment of this application. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0038] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings herein are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0039] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0040] Logic system design (e.g., chip design) is primarily written in hardware programming languages ​​(e.g., Verilog, VHDL, SystemC, or SystemVerilog), but may also include some software programming languages ​​(e.g., C, C++).

[0041] Before a logic system design is finalized for production use, it requires multiple simulation tests and debugging based on the simulation results. Simulation testing of the logic system design can be achieved by using one or more Field Programmable Gate Arrays (FPGAs). The logic design system running the simulation on the FPGA provides simulation logs for users to view the simulation results. It is understood that simulation testing of the logic system design can also be performed in software using a digital simulator.

[0042] Currently, code coverage is typically calculated during simulations. Code coverage refers to the percentage of lines of code, functions, or branches executed after a simulation test of a logical system design, relative to the total lines of code, all functions, or all branches. Generally, cases that pass simulation tests have high coverage because all tests have passed. However, during the execution of simulations (software or hardware), errors or exceptions inevitably occur, causing simulation tests to fail. In cases that fail simulation tests, certain functions or modules cannot run, resulting in a decrease in the amount of code executed, and consequently, a significant reduction in code coverage.

[0043] When simulation tests fail, users (usually verification engineers) are currently required to retrieve simulation errors from the simulation logs and then trace the errors back to the logic system design to pinpoint the design flaws. However, some design errors can generate thousands or even tens of thousands of simulation errors, leading to low accuracy in error location and wasting a significant amount of time.

[0044] In view of the above problems, some embodiments of this application provide a method, electronic device, and storage medium for locating errors in a logic system design, intended to solve the above problems.

[0045] Figure 1 A schematic diagram of a device 100 according to an embodiment of this application is shown. Figure 1 As shown, device 100 may include: processor 102, memory 104, network interface 106, peripheral interface 108, and bus 110. The processor 102, memory 104, network interface 106, and peripheral interface 108 are interconnected within device 100 via bus 110.

[0046] Processor 102 may be a central processing unit (CPU), image processor, neural network processor, microcontroller, programmable logic device, digital signal processor, application-specific integrated circuit (ASIC), or one or more integrated circuits. Processor 102 can be used to perform functions related to the techniques described in this application. In some embodiments, processor 102 may also include multiple processors integrated as a single logic component. Figure 1 As shown, processor 102 may include multiple processors 102a, 102b and 102c.

[0047] Memory 104 can be configured to store data (e.g., instruction sets, computer code, intermediate data, coverage data, and test cases). For example, Figure 1 As shown, the stored data may include program instructions (e.g., program instructions for implementing the techniques of this application) and test results (e.g., memory 104 may store coverage data obtained from code coverage calculation). Processor 102 may also access the stored program instructions and coverage data, and execute the program instructions to operate on the coverage data. Memory 104 may include a non-transitory computer-readable storage medium, such as a volatile storage device or a non-volatile storage device. In some embodiments, memory 104 may include random access memory (RAM), read-only memory (ROM), optical disk, magnetic disk, hard disk, solid-state drive (SSD), flash memory, memory stick, etc.

[0048] Network interface 106 can be configured to enable device 100 to communicate with one or more other external devices via a network. This network can be any wired or wireless network capable of transmitting and / or receiving data. For example, the network can be a wired network, a local wireless network (e.g., Bluetooth, WiFi, Near Field Communication (NFC), etc.), a cellular network, the Internet, or a combination thereof. It is understood that the type of network is not limited to the specific examples described above. In some embodiments, network interface 106 may include any combination of any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, etc.

[0049] The peripheral interface 108 can be configured to connect the device 100 to one or more peripheral devices to enable information input and output. For example, peripheral devices may include input devices such as keyboards, mice, touchpads, touch screens, microphones, and various sensors, as well as output devices such as displays, speakers, vibrators, and indicator lights.

[0050] Bus 110 can be configured to transfer information between various components of device 100 (e.g., processor 102, memory 104, network interface 106, and peripheral interface 108), and can be, for example, an internal bus (e.g., processor-memory bus), an external bus (USB port, PCI-E bus), etc.

[0051] In some embodiments, except Figure 1 In addition to the processor 102, memory 104, network interface 106, peripheral interface 108, and bus 110 shown and described above, device 100 may also include one or more other components necessary for normal operation and / or one or more other components necessary for implementing the solutions of the embodiments of this application. In some embodiments, device 100 may not include Figure 1 One or more components as shown.

[0052] It should be noted that although the above-described architecture of device 100 only shows processor 102, memory 104, network interface 106, peripheral interface 108, and bus 110, in specific implementations, the architecture of device 100 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the architecture of device 100 may only include the components necessary for implementing the embodiments of this application, and does not necessarily include all the components shown in the figures.

[0053] Figure 2A A schematic diagram of an exemplary debugging system according to an embodiment of this application is shown. The debugging system may include a simulation tool 202 and a debugging tool 200. The simulation tool 202 and the debugging tool 200 may be computer programs running on the device 100.

[0054] In the field of chip design, simulation tools are typically used to simulate a design. One example of such a tool is GalaxSim, produced by Chipown Technology Co., Ltd. Figure 2A The exemplary simulation tool 202 shown may include a compiler 120 and a simulator 220. The compiler 120 can compile the logic system design 203 into object code 204, and the simulator 220 can perform simulation based on the object code 204 and output the simulation results 206. For example, the simulation tool 202 can output the simulation results 206 (e.g., a simulation log in text form obtained through regression analysis) via... Figure 1 The peripheral interface 108 outputs to an output device (e.g., displayed on a monitor).

[0055] In some embodiments, simulation results 206 may also include coverage data of the logic system design 203. The data types of coverage data include at least: code coverage data, or functional coverage data, etc. Code coverage includes at least: line coverage data, branch coverage data, assertion data, assignment inversion rate data, or conditional assignment coverage data, etc.

[0056] Among these, row coverage data generally refers to the coverage of assignment lines within the logic system design. Branch coverage data refers to the coverage of if...else... branches within the logic system design. Assertion data refers to the assertion data within the logic system design. Assignment toggle rate data refers to the assignment toggle rate of ports and signals within the logic system design (e.g., 0->1, 1->0). Conditional assignment coverage data refers to the conditional assignment coverage within the logic system design.

[0057] To obtain coverage data, coverage testing needs to be performed simultaneously during simulation testing. In coverage testing, for different monitored objects, code coverage testing is typically achieved by inserting relevant coverage statistics code at the points in the source code of the logical system design that need to be monitored. The location where the coverage statistics code is inserted can be called a coverage point. Coverage can be expressed as the ratio of the number of coverage points executed in a single test case to the total number of coverage points; that is, the coverage of the logical system design. Alternatively, coverage can be expressed as the ratio of the number of times a coverage point is executed across multiple test cases to the total number of test cases; that is, the coverage of a single coverage point.

[0058] The debugging tool 200 can also read simulation results 206. For example, the debugging tool 200 can read simulation results 206 containing coverage data for debugging purposes. The debugging tool 200 can also read the description of the logic system design 203 (typically SystemVerilog and Verilog code) and display it (e.g., via...). Figure 1 The debugging tool 200 can also generate various graphical interfaces to facilitate the user's debugging work. The user can issue a debugging command 208 to the debugging tool 200 (for example, run the verification system 210 to a certain point), and the debugging tool 200 will then apply the debugging command to the simulation tool 202 to execute accordingly.

[0059] Understandably, in addition to connecting to software simulation tools (e.g., Galaxsim), the debugging tool 200 can also connect to hardware simulation tools (emulator) for debugging.

[0060] Figure 2B A schematic diagram of the test environment for the logic system design 203 according to an embodiment of this application is shown.

[0061] In some embodiments, a testbench 207 may be provided for testing the logical system design 203. The logical system design 203 under test may also be referred to as the design under test 203. The test environment 207 may be a UVM (universal verification methodology) environment. The test environment 207 may provide multiple test cases 210 to comprehensively test the design under test 203.

[0062] In some embodiments, the simulation tool 202 can use multiple test cases 210 to test the logic system design 203 (as described above for simulation and coverage testing), obtaining test results (as described above for simulation results 206). Before testing the logic system design 203, the simulation tool 202 can group the multiple test cases 210 according to their test modes, thereby grouping test cases with the same or similar test modes into one group, and using multiple test cases 210 in the same group to test the logic system design 203. The test mode can be the content of the test. For example, one group of test cases can all be used to test memory read and write, another group of test cases can all be used to test bus address allocation, yet another group of test cases can all be used to perform communication protocol execution, or there may be a group of cases that can perform addition tests, etc. This application does not limit the content of the test. By using multiple test cases 210 with the same test mode, it is helpful to extract features from the simulation results 206.

[0063] In some embodiments, each test case 210 may include multiple sub-test cases. The simulation results 206 may include coverage data corresponding to each test case. The simulation tool 202 sends the test results to the debugging tool 200.

[0064] The debugging tool 200 divides multiple test cases 210 into a pass case group (simulation test passed) and a fail case group (simulation test failed) based on the simulation results 206 in the test results. The pass case group and fail case group are typically determined directly based on the test results when testing the logic system design. The debugging tool 200 can determine multiple key features based at least on the simulation results 206 (e.g., coverage data) corresponding to the test cases in the fail case group of the multiple test cases 210. For example, the logic system design 203 is tested with 100 test cases for testing memory read and write operations, and coverage data for multiple coverage points in the logic system design 203 is determined.

[0065] Assume that the logic system design 203 passes simulation in 60 test cases and has a coverage of more than 90%, while it fails simulation in 40 test cases and has a coverage of only 50%. Figure 3A A schematic diagram of grouping 300 of multiple test cases according to an embodiment of this application is shown. Figure 3A As shown, test cases that pass the simulation are grouped into pass case group 302, and test cases that fail are grouped into failure case group 304. At this time, the debugging tool 200 can read the coverage data corresponding to pass case group 302 and failure case group 304 respectively.

[0066] The debugging tool 200 can extract features of the pass case group 302 and the failure case group 304 based on the coverage data corresponding to the pass case group 302 and the failure case group 304.

[0067] For example, debugging tool 200 can extract coverage data from test case group 302 and determine the coverage points that were tested in all 60 test cases based on the coverage data. Since the coverage points tested in all 60 test cases were executed, the design scope corresponding to the coverage points selected based on the coverage data can be considered the correct design scope. It is understood that a logic system design may include multiple design scopes from top to bottom. The correct design scope can be extracted as a feature of test case group 302.

[0068] Similarly, debugging tool 200 can extract coverage data for failure case group 304 and determine coverage points that were not tested in all 40 test cases based on the coverage data. Since the untested coverage points were not run in any of the 40 test cases, the design scope corresponding to the coverage points selected based on the coverage data can be considered an incorrect design scope. The aforementioned incorrect design scope can be extracted as a feature of failure case group 304.

[0069] Based on the characteristics of the passed case group 302 and the failed case group 304 described above, the debugging tool 200 can determine the key features of the faulty design scope, and thus determine at least one candidate faulty design scope. These key features can be the faulty design scope other than the design scope shared by the passed case group 302 and the failed case group 304.

[0070] It is understood that the features determined in the embodiments of this application are not limited to the examples described above. Those skilled in the art can use artificial intelligence to extract features from the successful and failed case groups. In this case, the feature is not necessarily a concrete concept, but rather a mathematical concept. Artificial intelligence methods can include, for example, feature engineering.

[0071] In some embodiments, the debugging tool 200 can determine key features based on changes in coverage data for multiple coverage points in the failure case group 304. These key features can be changes in the coverage of multiple coverage points. Since a correctly designed scope (e.g., a module) can typically be executed during testing, the coverage points within that scope should be executable in multiple test cases. Conversely, a flawed design scope may cause one or more coverage points within that scope to fail to execute. In coverage testing, this manifests as some coverage points being uncovered in multiple test cases, resulting in low coverage.

[0072] Therefore, for a coverage point that is repeatedly executed in multiple test cases (i.e., the coverage rate of this coverage point is greater than or equal to the first threshold), we can consider that the design scope associated with this coverage point does not have a design error. For a coverage point that is frequently not executed in multiple test cases (i.e., the coverage rate of this coverage point is less than or equal to the second threshold), we can consider that the design scope associated with this coverage point has a design error. It is understood that the first threshold is usually greater than the second threshold, and those skilled in the art can choose to set the first and second thresholds according to the actual needs of designing the test logic system. In some embodiments of this application, the range of the first and second thresholds is not limited.

[0073] Figure 3B A schematic diagram of design scope 310 according to an embodiment of this application is shown. Figure 3B As shown, design scope 310 is a higher-level module and includes sub-modules 312 and 314. These modules can be used interchangeably with the design scope. Coverage points 3102, 3122, and 3142 are set in design scopes 310, 312, and 314, respectively. Debugging tool 200 has extracted coverage data of the logic system design containing design scope 310 in multiple failed test cases and extracted the following features: the coverage rates (i.e., the proportion covered in multiple test cases) of coverage points 3102 and 3142 are greater than 90%, while the coverage rate of coverage point 3122 is less than 30%. Thus, debugging tool 200 can initially consider design scope 312 to be a design scope containing design errors and a candidate for error localization. Design scope 312 can also be considered a key feature.

[0074] Understandably, by using the above method, debugging tool 200 can determine multiple candidate design ranges.

[0075] When multiple candidate design scopes exist, the debugging tool 200 can locate errors in the logic system design based on the overlap between the multiple design scopes. The overlap between multiple design scopes can include: multiple design scopes overlapping completely and multiple design scopes partially overlapping.

[0076] Figure 3C A schematic diagram of the overlapping range 320 according to an embodiment of this application is shown. Figure 3CAs shown, the multiple design scopes 312 include a first design scope 3122, a second design scope 3124, and a third design scope 3126. The overlapping scopes of the first design scope 3122, the second design scope 3124, and the third design scope 3126 include overlapping scopes 322, 324, 326, and 328. Specifically, overlapping scope 322 is the overlapping portion between the first design scope 3122 and the second design scope 3124. Overlapping scope 324 is the overlapping portion between the first design scope 3122 and the third design scope 3126. Overlapping scope 326 is the overlapping portion between the second design scope 3124 and the third design scope 3126. Overlapping scope 328 is the overlapping portion between the first design scope 3122, the second design scope 3124, and the third design scope 3126. Errors in the logic system design can be located based on any one of the overlapping scopes 322, 324, 326, or 328.

[0077] In some embodiments, since the overlapping range 328 is the overlapping portion between the first design range 3122, the second design range 3124 and the third design range 3126, the overlapping range 328 can usually identify errors in the logic system design more quickly. Therefore, errors in the logic system design can usually be located based solely on the overlapping range 328 (i.e., multiple design ranges).

[0078] In some embodiments, the plurality of test cases 210 have the same test mode, and under the same test mode, the difference between the coverage data of the plurality of test cases is within a preset first range.

[0079] Furthermore, multiple test cases 210 share the same test mode. The test mode could be that all test cases perform addition tests, or that all test cases test a specific module within the logic system design (e.g., one set of test cases could all be used to test memory read / write, another set could all be used to test bus address allocation, and yet another set could all be used to test communication protocol execution, etc.). Therefore, the coverage data between multiple test cases 210 with the same test mode shows relatively small differences, and the differences in coverage data between multiple test cases 210 are typically within a preset first range. This preset first range can be a range that determines a small difference in coverage data, such as a difference within 10%, 5%, etc. It is understood that the above first range is merely illustrative, and those skilled in the art can set the first range according to actual circumstances. The specific value of the first range is not limited in this application.

[0080] Figure 4 A flowchart of a method 400 for correcting errors in a positioning logic system design according to an embodiment of this application is shown. Method 400 can be derived from, for example... Figure 1 The device 100 shown performs the operation. More specifically, it can be performed by the debugging tool 200 on the device 100. The method includes the following steps:

[0081] In step S402, the debugging tool 200 (e.g., Figure 2A The debugging tool 200 in the system can use multiple test cases (e.g., Figure 2A , Figure 2B Test case 210 in the document is used to test the logical system design (e.g., Figure 2A (Logical system design in 203).

[0082] Among them, the debugging tool 200 can use simulation tools (e.g., Figure 2A The simulation tool 202 in the software is used for testing. After the test, the results can be obtained (e.g., ...). Figure 2A Simulation result 206), simulation result 206 can be stored in memory (e.g., Figure 1 In the memory 104).

[0083] In step S404, the debugging tool 200 can, based on the results of the test (e.g., Figure 2A The simulation results 206) divide the multiple test cases into case groups (e.g., Figure 3A 302) and failure case groups (e.g., Figure 3A (304 in the original text), the test results include coverage data of the multiple test cases.

[0084] In some embodiments, multiple test cases (e.g., Figure 2A and Figure 2B Test case 210 in the dataset has the same test pattern. The differences in coverage data between multiple test cases are within a preset first range.

[0085] By analyzing test cases with the same testing pattern together, and then locating key features, errors generated during the design of the logic system can be accurately identified, ensuring that different test cases do not affect the test results of the logic system.

[0086] In step S406, the debugging tool 200 determines the failure case group (e.g., Figure 3A The coverage data of test cases in 304) are used to determine several key features.

[0087] In some other embodiments, the debugging tool 200 determines several key features based at least on the test case coverage data in the failed case group, further including: the debugging tool 200 can determine the passed case group (e.g., Figure 3AThe multiple first features of the passed case group 302 (e.g., the passed design scope) and the failed case group (e.g., Figure 3A The debugging tool 200 can determine the plurality of key features (e.g., candidate faulty design ranges) based on the plurality of first features and the plurality of second features. For a detailed description of this embodiment, please refer to [link to relevant documentation]. Figure 3A and Figure 3B The description.

[0088] In some other embodiments, the debugging tool 200 determines multiple key features based at least on the coverage data of test cases in the failed case group, further including: the debugging tool 200 can identify multiple coverage points in the logic system design (e.g., Figure 3B Coverage data for coverage points 3102, 3122, and 3142. The debugging tool 200 can determine multiple key features (e.g., ...) based on changes in the coverage data of multiple coverage points. Figure 3B (Coverage rates of coverage points 3102 and 3142 in the example). For a detailed description of this embodiment, please refer to the above embodiments.

[0089] In this way, multiple key features can be determined in two ways (based on coverage data and design scope). The appropriate method can be selected according to different actual situations, which can improve the speed of determining key features and thus improve the speed of error detection in the positioning logic system design.

[0090] In step S408, the debugging tool 200 locates errors in the logic system design based on the multiple key features.

[0091] In some embodiments, the debugging tool 200 locating errors in the logic system design based on the plurality of key features further includes: the debugging tool 200 determining a plurality of ranges of the logic system design corresponding to the plurality of key features (e.g., Figure 3B (Design scope 312). Debugging tool 200 can locate errors in the logic system design based on the multiple scopes. For a detailed description of this embodiment, please refer to the embodiments described above.

[0092] In some embodiments, the debugging tool 200 locating errors in the logic system design based on the plurality of ranges further includes: the debugging tool 200 can determine a plurality of ranges (e.g., Figure 3C At least one overlapping range (e.g., among the first design range 3122, the second design range 3124, and the third design range 3126) in the design scope. Figure 3C The overlapping ranges are 322, 324, 326, and 328. The debugging tool 200 can adjust the parameters based on these overlapping ranges (e.g., ...). Figure 3C Errors in the logic system design are located within the overlapping ranges 322, 324, 326, and 328. For a detailed description of this embodiment, please refer to [link to relevant documentation]. Figure 3C The description.

[0093] In this way, the logical system design is tested through multiple test cases, and the test results are used to distinguish between pass and fail case groups. Then, the key features can be identified based on the coverage data of the test cases in the fail case group. Code coverage is often used as a metric for measuring the quality of testing. Therefore, when the code volume is large and the logic is complex, coverage can accurately pinpoint the location of key features, and thus locate errors in the logical system design. Code coverage is usually obtained during code coverage testing, so it can be obtained during the testing of the logical system without additional testing or manual analysis by developers, reducing the time spent locating errors.

[0094] This application also provides an electronic device that may include a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement a method for erroneous location logic system design consistent with this application, such as one of the exemplary methods described above (e.g., Figure 4 Method 400 shown.

[0095] This application also provides a computer-readable storage medium on which a computer program can be stored. When executed by a processor, the computer program implements a method for locating errors in a logic system design consistent with this application, such as one of the exemplary methods described above (e.g.,...). Figure 4 Method 400 shown.

[0096] This application also provides a computer program product that may include a computer program. When executed by a processor, this computer program implements a method for locating errors in a logic system design consistent with this application, such as one of the exemplary methods described above (e.g., Figure 4 Method 400 shown.

[0097] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0098] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0099] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for locating errors in the design of a logic system, characterized in that, The method includes: The logical system design was tested using multiple test cases. Based on the test results, the multiple test cases are divided into a pass case group and a fail case group, and the test results include the coverage data of the multiple test cases; At least several key features are determined based on the coverage data of test cases in the failed case group. These key features include design ranges or coverage points that are not covered or have coverage below a preset threshold; and Errors in the logic system design can be located based on the aforementioned key features.

2. The method as described in claim 1, characterized in that, The multiple test cases share the same test pattern.

3. The method as described in claim 1, characterized in that, The determination of multiple key features based at least on the coverage data of test cases in the failed case group further includes: Determine the coverage data for multiple coverage points in the logical system design; Several key features are determined based on the changes in coverage data of the multiple coverage points.

4. The method as described in claim 1, characterized in that, The determination of multiple key features based at least on the coverage data of test cases in the failed case group further includes: Determine multiple first features of the successful case group and multiple second features of the failed case group; The plurality of key features are determined based on the plurality of first features and the plurality of second features.

5. The method as described in claim 3 or 4, characterized in that, The step of locating errors in the logic system design based on the multiple key features further includes: Determine multiple ranges for the logic system design corresponding to the multiple key features; Errors in the logic system design are located based on the multiple ranges.

6. The method as described in claim 5, characterized in that, The step of locating errors in the logic system design based on the multiple ranges further includes: Determine at least one overlapping range among multiple ranges; The error in the logic system design is located based on the overlapping range.

7. The method as described in claim 2, characterized in that, The differences in coverage data among the multiple test cases are within a preset first range.

8. The method as described in claim 1, characterized in that, The data types of the coverage data include at least: code coverage data or functional coverage data, and the code coverage includes at least: line coverage data, branch coverage data, assertion data, assignment inversion rate data, or conditional assignment coverage data.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images