Coverage determination method, device, medium, and program product in chip testing
By implementing hierarchical management of chip test code, dividing the code into hierarchical blocks and comparing them during updates, the problem of inefficient coverage convergence in chip testing is solved, achieving efficient and stable coverage determination.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI ENFLAME INTELLIGENCE TECH CO LTD
- Filing Date
- 2026-04-20
- Publication Date
- 2026-07-21
AI Technical Summary
In chip testing, traditional methods are inefficient in determining coverage and prone to human error, making it difficult to achieve high coverage targets efficiently. This is especially true in chip designs with complex heterogeneous IP cores, where code changes can cause coverage data to become invalid, requiring a lot of repetitive troubleshooting and updates.
By dividing the chip test code into hierarchical structures, multiple code level blocks are obtained, the test coverage of each block is determined, and the coverage is compared and updated on a block-by-block basis when the code is updated, identifying the content and type of changes, thus achieving efficient coverage determination.
It improves the efficiency of coverage determination in chip testing, reduces repetitive work, lowers the risk of human error, and ensures stable convergence of coverage.
Smart Images
Figure CN122431963A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of chip testing technology, and in particular to a method, device, medium, and program product for determining coverage in chip testing. Background Technology
[0002] With the rapid development of artificial intelligence (AI) technology, AI chips are evolving towards larger scale and stronger computing power. The highly specialized functional modules (IP cores) integrated inside the chips, such as memory management units (MMUs) and tensor processors, are becoming increasingly complex in structure, and the degree of heterogeneous integration is constantly deepening.
[0003] This complexity not only manifests in chip design but also places unprecedented pressure on subsequent chip testing and verification. The chip development cycle is constantly being compressed, demanding that every stage of chip design and verification pursue extreme efficiency. However, sharply contradicting these tight deadlines are the ever-increasing demands on chip test and verification coverage (code coverage or functional coverage). High chip test coverage is an uncompromising cornerstone for ensuring the correctness, reliability, and high-quality delivery of chips. Achieving high coverage is exceptionally challenging for heterogeneous IP cores with complex structures and large state spaces.
[0004] Traditional chip design verification methods follow a dynamic process of "developing, verifying, and converging simultaneously." In accelerating chip development, chip test code often requires necessary local optimizations and modifications in the later stages of verification. Each modification risks invalidating the earlier coverage data. Chip verification engineers are forced to spend a significant amount of time on repetitive troubleshooting, updating, and re-convergence, resulting in inefficient chip verification coverage determination and an increased susceptibility to human error. Summary of the Invention
[0005] This invention provides a method, device, medium, and program product for determining coverage in chip testing, which restricts code changes to code-level blocks and achieves efficient coverage determination in chip testing.
[0006] According to one aspect of the present invention, a method for determining coverage in chip testing is provided, the method comprising: Obtain the chip test code and divide the chip test code into hierarchical structures to obtain multiple code hierarchical blocks; In chip testing, the chip test code is run and the test coverage of each code level block is determined; When the chip test code is updated, obtain the current version and the previous version of the chip test code; Using each code level block as a unit, the code content of the current version is compared with that of the previous version to determine the target code level block that has been modified and the modified content. Update the coverage in chip testing based on the target code level block, the modified content, and the test coverage of each code level block.
[0007] According to another aspect of the present invention, a coverage determination apparatus for chip testing is provided, the apparatus comprising: The hierarchical structure partitioning module is used to acquire chip test code and partition the chip test code into a hierarchical structure to obtain multiple code hierarchical blocks; The hierarchical block test coverage determination module is used to run the chip test code and determine the test coverage of each code hierarchical block during chip testing. The code version acquisition module is used to acquire the current version and the previous version of the chip test code when the chip test code is updated. The code content comparison module is used to compare the code content of the current version with that of the previous version, taking each code level block as a unit, to determine the target code level block that has been modified and the modified content. The chip test coverage determination module is used to update the coverage in chip testing based on the target code level block, the modified content, and the test coverage of each code level block.
[0008] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to said at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the coverage determination method in chip testing according to any embodiment of the present invention.
[0009] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the coverage determination method in chip testing according to any embodiment of the present invention.
[0010] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the coverage determination method in chip testing as described in any embodiment of the present invention.
[0011] The technical solution of this invention obtains chip test code and divides it into hierarchical blocks. During chip testing, the chip test code is run, and the test coverage of each code block is determined. When the chip test code is updated, the current and previous versions are obtained. The code content of each code block is compared with the previous version to identify the target code block with changes and the changes themselves. Based on the target code block, the changes, and the test coverage of each code block, the coverage in chip testing is updated. This solves the problem of inefficient coverage convergence in chip testing. By managing the test code hierarchically, code changes can be restricted to code blocks, thereby achieving efficient coverage determination in chip testing.
[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description
[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0014] Figure 1 This is a flowchart of a method for determining coverage in chip testing according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of a method for determining coverage in chip testing according to Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of a coverage determination device in chip testing according to Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the coverage determination method in chip testing according to an embodiment of the present invention. Detailed Implementation
[0015] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention 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 of the invention 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 non-exclusive inclusion; for example, a process, method, system, product, or apparatus 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 apparatus.
[0017] Example 1 Figure 1 This is a flowchart of a coverage determination method in chip testing according to Embodiment 1 of the present invention. This embodiment is applicable to situations where coverage is determined for each iteration of chip testing. The method can be executed by a coverage determination device in chip testing, which can be implemented in hardware and / or software and can be configured in electronic devices such as computers or chip testing machines. Figure 1 As shown, the method includes: Step 110: Obtain the chip test code and divide the chip test code into hierarchical structures to obtain multiple code hierarchical blocks.
[0018] Chip test code can be code that describes the hardware circuitry of a chip. For example, chip test code can be Register Transfer Level (RTL). The hierarchical division of chip test code refers to dividing the code into layers and blocks based on its function and interface during the initial coding phase. Clear boundaries and control logic can be defined for each code layer (block).
[0019] Optionally, the chip test code can be hierarchically divided to obtain multiple code hierarchical blocks, including: dividing the chip test code hierarchically based on the functional logic independence of the chip test code, the size of a single functional logic code, and the functional heterogeneous circuits in the chip to obtain multiple code hierarchical blocks.
[0020] For example, an independent functional logic segment in chip test code can be considered as a code hierarchy block. When the size of an independent functional logic code segment is large, it can be split into multiple code hierarchy blocks. For instance, the hierarchical structure can be divided based on the control logic within the functional logic segment to obtain multiple code hierarchy blocks. Furthermore, in the hierarchical division of chip test code, heterogeneous circuits can be considered, and the portions containing heterogeneous circuits can be split into code hierarchy blocks to improve the reuse efficiency of test code. In chip design, heterogeneous circuits refer to the same circuit with functional differences in different locations on the chip due to chip requirements. For example, in chip design, to consider the area occupied by the designed circuit within the chip, when reusing a specific functional circuit, the circuit is adjusted to form a similar but different circuit; the circuits before and after the adjustment constitute a heterogeneous circuit.
[0021] Step 120: In chip testing, run the chip test code and determine the test coverage of each code level block.
[0022] In chip testing, functional coverage and code coverage can be collected in parallel for each independent block. The test coverage of each code-level block can be determined using chip testing tools. Furthermore, exemption files for each block can be generated based on points within each block that are confirmed to be non-coverable or temporarily uncoverable.
[0023] By determining test coverage in chip testing by taking each code level block as a unit, changes to the test code can be limited to a single block, thereby avoiding the high complexity of chip test coverage determination caused by local changes leading to global maintenance.
[0024] Step 130: When the chip test code is updated, obtain the current version and the previous version of the chip test code.
[0025] In chip testing, due to local optimizations or modifications during the later stages of verification, the RTL code may be altered, resulting in multiple versions of chip test code. To determine the corresponding test coverage for the current version of the chip test, we can obtain the chip test code for both the current and previous versions, and efficiently update the coverage by comparing the two versions.
[0026] Step 140: Compare the code content of the current version with the previous version, taking each code level block as a unit, to determine the target code level block that has been modified and the modified content.
[0027] In each version of the chip test code, corresponding code hierarchical blocks are generated through a hierarchical structure. Code content comparison can be performed on a block-by-block basis, comparing the current version with the previous version. This allows for the identification of changes within each code hierarchical block and the target code hierarchical block where the changes occurred. Code content comparison can be achieved by adding code inspection to the code, checking the location of script changes, the corresponding code hierarchical blocks, and the involved control logic, interfaces, and line numbers. Alternatively, specialized code comparison tools (such as those similar to `git diff`) can be used to automatically compare and determine the changes and scope between the current and previous versions.
[0028] Step 150: Update the coverage in chip testing based on the target code level blocks, the modified content, and the test coverage of each code level block.
[0029] In the current version, the test coverage of code blocks that have not been modified can maintain the test coverage value of the previous version. When the target code block is modified, the test coverage of the target code block can be updated. Updating the test coverage of the target code block can be done by rerunning the tests corresponding to the target code block. Alternatively, before rerunning the tests corresponding to the target code block, the type of modification to the target code block can be determined, and the test coverage of the target code block can be updated based on the type of modification.
[0030] Optionally, the coverage in chip testing is updated based on the target code level blocks, the modified content, and the test coverage of each code level block, including: determining the modification type of the target code level blocks based on the target code level blocks and the modified content; and updating the coverage in chip testing based on the modification type and the test coverage of each code level block.
[0031] For example, if the change to the target code block is of a type that does not affect test coverage, it is not necessary to retest; the test coverage from the previous version of the target code block can be reused. If the change to the target code block is of a type that affects test coverage, the target code block can be retested to update the test coverage.
[0032] The type of change to a target code block can be determined by the content of the change. For example, when the change involves control logic, addition or deletion of functions, changes to interface signals, or refactoring of state machines, it can be identified as a type that affects test coverage, i.e., the change is a major change. When the change only involves non-functional code style adjustments, comment modifications, or equivalent transformations of internal logic, it can be identified as a type that does not affect test coverage, i.e., the change is a minor change.
[0033] By combining the type of change when updating test coverage at the target code level, we can avoid rerunning tests for all changes to update coverage to some extent, thus improving coverage update efficiency and saving computing power. Chip test coverage is a value obtained by integrating the test coverage of each target code level block.
[0034] The technical solution of this embodiment obtains chip test code and divides it into hierarchical blocks. During chip testing, the chip test code is run, and the test coverage of each code block is determined. When the chip test code is updated, the current version and the previous version of the chip test code are obtained. The code content of the current version and the previous version are compared on a per-code-block basis to determine the target code block with changes and the changes themselves. Based on the target code block, the changes, and the test coverage of each code block, the coverage in chip testing is updated. This solves the problem of inefficient coverage convergence in chip testing. By managing the test code hierarchically, code changes can be restricted to code blocks, thereby achieving efficient coverage determination in chip testing.
[0035] Example 2 Figure 2 This is a flowchart of a method for determining coverage in chip testing according to Embodiment 2 of the present invention. This embodiment is a further addition and refinement of the above technical solution, and the technical solution in this embodiment can be combined with various optional solutions in one or more of the above embodiments. Figure 2 As shown, the method includes: Step 210: Obtain the chip test code, and divide the chip test code into hierarchical structures according to the functional logic independence, the size of a single functional logic code, and the functional heterogeneous circuits in the chip, to obtain multiple code hierarchical blocks.
[0036] Step 220: In chip testing, run the chip test code and determine the test coverage of each code level block.
[0037] Step 230: When the chip test code is updated, obtain the current version and the previous version of the chip test code.
[0038] Step 240: Compare the code content of the current version with the previous version, taking each code level block as a unit, to determine the target code level block that has been modified and the modified content.
[0039] Step 250: Determine the type of change to the target code hierarchy block based on the target code hierarchy block and the content of the changes.
[0040] Optionally, based on the target code level block and the modified content, the modification type of the target code level block is determined, including: when the modification involves the control logic or interface of the target code level block, the modification type is determined to be the first type of modification; when the modification does not involve the control logic or interface of the target code level block, the amount of modification is obtained; when the amount of modification is greater than the preset amount of code, the modification type is determined to be the first type of modification; otherwise, the modification type is determined to be the second type of modification.
[0041] The first type of change is those that affect test coverage, meaning the changes are significant. The second type of change is those that do not affect test coverage, meaning the changes are minor. For example, when the change involves control logic or interfaces, it is classified as a significant change. When the amount of change is large, exceeding the preset code size, it is classified as a significant change. When the change does not involve control logic or interfaces, it is classified as a minor change. For example, when the change only involves non-functional code style adjustments, comment modifications, or equivalent transformations of internal logic, it can be classified as a minor change. When the amount of change is small, less than or equal to the preset code size, it is classified as a minor change.
[0042] Step 260: Update the coverage in chip testing based on the type of change and the test coverage of each code level block.
[0043] Optionally, the coverage in chip testing is updated based on the type of change and the test coverage of each code level block, including: when the change type is type 1, running the current version of the chip test code corresponding to the target code level block and resetting the current test coverage of the target code level block; updating the test coverage of each code level block based on the current test coverage to obtain the coverage in chip testing; when the change type is type 2, updating the test coverage of each code level block to the coverage in chip testing.
[0044] When the change type is a major change, the current version chip test code corresponding to the target code level block can be run to reset the current test coverage of the target code level block. When the change type is a minor change, the historical test coverage of the target code level block can be merged and reused to reduce the computing power required for coverage determination and improve the efficiency of coverage determination.
[0045] Step 270: Identify the repeating instance groups in the chip design and the number of instances of the repeating instance groups.
[0046] A repeating instance group can be a data group formed by reusing circuit instances in chip design. For example, a repeating instance can refer to the reuse of one or more code level blocks. Repeating instance groups can be identified based on the naming of functional circuits in the chip design, or by identifying circuit connections and interface names. For example, in chip design, to standardize the design, repeating instances can be named using the same script name prefix plus a version number suffix. In this case, if the script name prefixes of the functional circuits in the code level blocks are the same, they can be considered as repeating instance groups. The maximum value of the version number suffix can be used as the instance count.
[0047] In chip design, the reuse of functional circuits such as processing units or cache units may result in heterogeneity. For example, considering factors such as area and performance in chip layout, a particular instance might have 1024 instances during circuit placement, while in an area-constrained region, it might only have 256 instances, forming heterogeneous circuits. To ensure the correctness of the exemption file generation when applying instances, the number of instances is identified simultaneously during duplicate instance group identification. Instances in different regions can be distinguished by type.
[0048] Step 280: Select a representative instance from the duplicate instance group and generate exemption rules based on the representative instance.
[0049] Exemption rules can be formed based on issues that do not require testing in a representative instance. There are several ways to generate exemption rules. For example, a representative instance can be displayed using a human-computer interaction interface, allowing engineers to determine the exemption rules for that instance. Alternatively, tests associated with the representative instance can be identified, and uncovered test issues can be determined based on these tests. These uncovered test issues can then be displayed, allowing engineers to select exemptable tests from them and generate exemption rules. Alternatively, engineers can also add exemptable tests based on the uncovered test issues to generate exemption rules.
[0050] Step 290: Apply the exemption rules uniformly according to the number of instances in the duplicate instance group to generate the chip test exemption file.
[0051] Exemption rules can be reused based on the number of instances to generate exemption files (EL). By identifying duplicate instance groups and uniformly applying exemption rules to generate exemption files, engineers can avoid repeatedly generating exemption files, improving the efficiency and accuracy of exemption file generation, and ensuring the simplicity and efficiency of the exemption files.
[0052] Optionally, based on the above implementation method, after updating the coverage in chip testing according to the target code level block, the modified content, and the test coverage of each code level block, the method further includes: when the coverage in chip testing does not reach the preset coverage target, performing gap analysis based on the coverage and generating targeted test stimuli; updating the chip test code based on the targeted test stimuli, and returning to the step of obtaining the current version and the previous version of the chip test code when there are updates to the chip test code, so as to update the coverage in chip testing.
[0053] Gap analysis involves comparing the test requirements in chip testing with the actual tests performed to identify uncovered test scenarios. Gap analysis can further eliminate scenarios from exemption documents. Based on the results of gap analysis, targeted test stimuli can be generated to perform targeted testing on uncovered scenarios, improving test coverage. In targeted testing, the chip test code can be updated according to the targeted test stimuli. The updated chip test code is used as the current version, and the changes in the previous version of the test code are compared to update the coverage in chip testing.
[0054] For example, chip test coverage can be determined to have converged when the chip test coverage reaches a first preset coverage rate and the test coverage rate of critical code level blocks reaches a second preset coverage rate. For instance, the first preset coverage rate may be the same as or different from the second preset coverage rate. For example, the first preset coverage rate may be 99%, and the second preset coverage rate may be 99.5%.
[0055] The technical solution of this invention involves acquiring chip test code and, based on the functional logic independence, individual functional logic code size, and heterogeneous circuits within the chip, dividing the chip test code into hierarchical blocks to obtain multiple code hierarchical blocks. During chip testing, the chip test code is run, and the test coverage of each code hierarchical block is determined. When the chip test code is updated, the current version and the previous version of the chip test code are obtained. For each code hierarchical block, the code content of the current version and the previous version is compared to determine the target code hierarchical block with modifications and the modified content. Based on the target code hierarchical block and the modified content, the modification type of the target code hierarchical block is determined. Finally, based on the modification type and the test coverage of each code hierarchical block... This system achieves coverage testing and updates coverage in chip testing; identifies duplicate instance groups in chip design and the number of instances applied to these groups; selects representative instances from the duplicate instance groups and generates exemption rules based on these representative instances; uniformly applies the exemption rules to the duplicate instance groups according to the number of instances, generating exemption files for chip testing. This solves the problem of inefficient coverage convergence in chip testing. By implementing layered management of test code, code changes can be restricted to code level blocks, thus achieving efficient coverage determination in chip testing. Type identification of changes improves the efficiency of coverage determination and saves computational power. Uniform application of exemption rules to duplicate instance groups reduces redundant and repetitive work, improving the efficiency and accuracy of exemption file writing.
[0056] One application example of the technical solution provided in this invention is as follows: In the verification of the Memory Management Unit (MMU) of an AI chip, structured planning is performed during the design phase. That is, in the early stages of RTL encoding of the MMU, it is proactively planned and divided into multiple logically independent code hierarchical blocks with clear interfaces based on its functions, such as the Level 1 Address Translation Buffer (L1 TLB) lookup module, the Page Table Traversal (PTW) state machine module, and the Physical Address Translation module, etc., and the scope and control logic of the code hierarchical blocks are clearly defined, laying the foundation for subsequent verification. Layered coverage collection and exemptions are performed on the MMU; that is, after the RTL is stabilized, coverage convergence is initiated. Verification environments are established for the top layer (mmu_top) and each code hierarchical block (such as ptw_fsm), and coverage is collected using code hierarchical blocks as independent units. Engineers can analyze the coverage reports of each code hierarchical block and record points confirmed as not requiring coverage (such as some physically unreachable states) in the corresponding code hierarchical block-level exemption file (.el). In subsequent iterations, for example, when the PTW state machine module undergoes code changes due to performance optimization, the version control system automatically identifies the RTL changes in that module and triggers the change impact analysis process. The electronic device can analyze the changes to the PTW module, determining that they are internal logic optimizations but the interfaces and functions remain unchanged, falling under the category of "minor compatibility changes," or the second type of change. Subsequently, the coverage data generated by the new simulation can be automatically merged with the historical database to generate an updated merge report, without needing to rerun the entire MMU test. For multiple TLB entries instantiated in the MMU with identical structures, the duplicate instance group is identified by running an automated script. The script automatically generates exemption rules for one representative instance and applies them in batches to all similar instances, eliminating the need for engineers to manually write duplicate exemptions. The merged and optimized coverage report is analyzed. If the PTW module coverage reaches 99.5%, but the L1 TLB query module coverage is only 95%, targeted tests can be generated for the gap in the L1 TLB query module, and a new round of targeted verification iterations can be performed. This process is repeated until the coverage of all code levels and the top-level code consistently exceeds the target threshold of 99%, at which point convergence is considered complete.
[0057] The technical solution of this invention provides an ideal, loosely coupled foundation for subsequent layered exemption management and intelligent merging by clearly layering and decoupling functions into independent code blocks, and designing, verifying, and managing them at the "block" granularity. This improves the maintainability and efficiency of verification from the source. This approach avoids the problems of traditional design methods that pile all functions into a single module, leading to high internal coupling and mixed functional logic, resulting in logical redundancy, high maintenance costs, and unpredictable chain reactions from any changes, leading to low coverage convergence efficiency and easily invalidated exemption files. The technical solution of this invention achieves a stable and efficient high coverage convergence target and completes chip testing within a tight development cycle.
[0058] Example 3 Figure 3 This is a schematic diagram of a coverage determination device for chip testing according to Embodiment 3 of the present invention. Figure 3 As shown, the device includes: a hierarchical structure partitioning module 310, a hierarchical block test coverage determination module 320, a code version acquisition module 330, a code content comparison module 340, and a chip test coverage determination module 350. Wherein: The hierarchical structure partitioning module 310 is used to acquire chip test code and partition the chip test code into a hierarchical structure to obtain multiple code hierarchical blocks; The hierarchical block test coverage determination module 320 is used to run chip test code and determine the test coverage of each code hierarchical block during chip testing. The code version acquisition module 330 is used to obtain the current version and the previous version of the chip test code when there are updates to the chip test code; The code content comparison module 340 is used to compare the code content of the current version with that of the previous version, taking each code level block as a unit, to determine the target code level block that has been modified and the modified content. The chip test coverage determination module 350 is used to update the coverage in chip testing based on the target code level blocks, the modified content, and the test coverage of each code level block.
[0059] Optionally, the chip test coverage determination module 350 includes: The modification type determination unit is used to determine the modification type of the target code level block based on the target code level block and the modification content; The chip test coverage determination unit is used to update the coverage in chip testing based on the type of change and the test coverage of each code level block.
[0060] Optional, the modification type determination unit is specifically used for: When the changes involve control logic or interfaces of the target code level block based on the content of the changes, the change type is determined to be the first type of change; When it is determined from the changes that the changes do not involve the control logic or interface of the target code level block, obtain the amount of change to the changes. If the amount of modification exceeds the preset amount of code, the modification type is determined to be the first type of modification; otherwise, the modification type is determined to be the second type of modification.
[0061] Optionally, a chip test coverage determination unit is used specifically for: When the modification type is Type 1, run the current version chip test code corresponding to the target code level block and reset the current test coverage of the target code level block; The test coverage of each code level block is updated based on the current test coverage to obtain the coverage in chip testing; When the change type is Type 2, update the test coverage of each code level block to the coverage in the chip test.
[0062] Optionally, the device may also include: The duplicate instance group identification module is used to identify duplicate instance groups in the chip design and the number of instances of duplicate instance groups applied after updating the coverage in chip testing based on the target code level blocks, the modified content, and the test coverage of each code level block. The exemption rule generation module is used to select a representative instance from the duplicate instance group and generate exemption rules based on the representative instance; The exemption file generation module is used to uniformly apply exemption rules based on the number of instances in a duplicate instance group and generate exemption files for chip testing.
[0063] Optionally, the hierarchical structure partitioning module 310 includes: The hierarchical structure partitioning unit is used to partition the chip test code into multiple code hierarchical blocks based on the functional logic independence of the chip test code, the size of a single functional logic code, and the functional heterogeneous circuits in the chip.
[0064] Optionally, the device may also include: The targeted test incentive generation module is used to update the coverage in chip testing based on the target code level block, the modified content, and the test coverage of each code level block. When the coverage in chip testing does not reach the preset coverage target, it performs gap analysis based on the coverage and generates targeted test incentives. The iterative execution module is used to update the chip test code according to the targeted test incentives, and return the steps to obtain the current version and the previous version of the chip test code when there are updates, so as to update the coverage in the chip test.
[0065] The coverage determination device for chip testing provided in this embodiment of the invention can execute the coverage determination method for chip testing provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of executing the method.
[0066] Example 4 Figure 4 This is a schematic diagram of an electronic device implementing the coverage determination method in chip testing according to embodiments of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.
[0067] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) or random access memory (RAM), communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from the storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. Input / output (I / O) interfaces are also connected to the bus 14.
[0068] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0069] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as coverage determination methods in chip testing.
[0070] In some embodiments, the coverage determination method in chip testing may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the coverage determination method in chip testing described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the coverage determination method in chip testing by any other suitable means (e.g., by means of firmware).
[0071] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0072] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0073] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0074] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0075] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0076] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0077] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.
[0078] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. A method for determining coverage in chip testing, characterized in that, include: Obtain the chip test code and divide the chip test code into hierarchical structures to obtain multiple code hierarchical blocks; In chip testing, the chip test code is run and the test coverage of each code level block is determined; When the chip test code is updated, obtain the current version and the previous version of the chip test code; Using each code level block as a unit, the code content of the current version is compared with that of the previous version to determine the target code level block that has been modified and the modified content. Update the coverage in chip testing based on the target code level block, the modified content, and the test coverage of each code level block.
2. The method according to claim 1, characterized in that, Based on the target code level block, the modified content, and the test coverage of each code level block, update the coverage in chip testing, including: Based on the target code hierarchy block and the modified content, determine the modification type of the target code hierarchy block; Update the coverage in chip testing based on the type of change and the test coverage of each code level block.
3. The method according to claim 2, characterized in that, Based on the target code hierarchy block and the modified content, determine the modification type of the target code hierarchy block, including: When it is determined from the changes that the changes involve the control logic or interface of the target code layer block, the change type is determined to be the first type of change; When it is determined that the modification does not involve the control logic or interface of the target code level block based on the modified content, the amount of modification of the modified content is obtained; If the amount of modification is greater than the preset amount of code, the modification type is determined to be a first type of modification; otherwise, the modification type is determined to be a second type of modification.
4. The method according to claim 3, characterized in that, Based on the type of modification and the test coverage of each code level block, update the coverage in chip testing, including: When the modification type is the first type of modification, run the current version chip test code corresponding to the target code hierarchy block and reset the current test coverage of the target code hierarchy block; The test coverage of each code level block is updated based on the current test coverage to obtain the coverage in chip testing; When the change type is the second type, the test coverage of each code level block is updated to the coverage in the chip test.
5. The method according to claim 1, characterized in that, After updating the coverage in chip testing based on the target code level block, the modified content, and the test coverage of each code level block, the process further includes: Identify the repeating instance groups in the chip design and the number of instances in which the repeating instance groups are applied; Select a representative instance from the group of duplicate instances, and generate exemption rules based on the representative instance; The exemption rules are uniformly applied to the number of instances in the repeated instance group to generate an exemption file for chip testing.
6. The method according to claim 1, characterized in that, The chip test code is hierarchically divided into multiple code hierarchical blocks, including: Based on the functional logic independence of the chip test code, the size of a single functional logic code, and the functional heterogeneous circuits in the chip, the chip test code is divided into hierarchical structures to obtain multiple code hierarchical blocks.
7. The method according to claim 1, characterized in that, After updating the coverage in chip testing based on the target code level block, the modified content, and the test coverage of each code level block, the process further includes: When the coverage rate in chip testing does not reach the preset coverage target, gap analysis is performed based on the coverage rate and targeted test stimuli are generated. The chip test code is updated according to the targeted test stimulus, and when the chip test code is updated, the current version and the previous version of the chip test code are obtained to update the coverage in the chip test.
8. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to said at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the coverage determination method in chip testing according to any one of claims 1-7.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the coverage determination method in chip testing according to any one of claims 1-7.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the coverage determination method in chip testing according to any one of claims 1-7.