Chip Test Result Analysis Methods and Apparatus

Abstract

This application relates to a chip test result analysis method and apparatus. The technical solution utilizes a test process dependency graph, enabling the system to identify "legitimate skips" caused by previous test failures and strictly distinguish them from "abnormal missing values" caused by hardware malfunctions. This avoids misjudging normally skipped test items as chip defects, thereby improving the accuracy of yield analysis. Through intelligent merging decision-making, the system can activate corresponding intelligent logic based on data status (conflicts, missing values), rather than applying rigid "one-size-fits-all" rules. The final merged test results more accurately reflect the actual performance and quality status of each chip, allowing the selection of the most suitable solution for the testing objective (e.g., first pass of contact test, optimal value for performance test) when handling conflicting results, ensuring the rationality of the merging decision.

Description

Technical Field

[0001] This application relates to the field of chip testing, and in particular to a method and apparatus for analyzing chip test results. Background Technology

[0002] With the continuous advancement of semiconductor manufacturing processes, chip complexity is increasing, and the requirements for efficiency and reliability in mass production testing are becoming increasingly stringent. In the chip wafer testing (CP, Circuit Probing) stage, to improve testing efficiency, multi-site parallel testing technology is commonly used, which uses multiple probe card contacts to test multiple chips simultaneously. This inevitably generates multiple test data files from different test passes (such as CP1, CP2, CP3, etc.). Therefore, how to accurately and reliably merge the test data from multiple passes to generate the final test results for each chip has become a critical step affecting the accuracy of yield analysis and the correctness of chip sorting (binning).

[0003] In existing technologies, some solutions have been developed to address the problem of merging multi-source test data. These solutions typically rely on parsing Standard Test Data Format (STDF) files and primarily focus on data-level processing. They have inherent limitations and cannot effectively handle the complex dynamic logic and semantic scenarios in chip testing, leading to distorted test results, masking real faults, failing to accurately reflect the chip's optimal performance or potential defects, and exhibiting poor traceability of test results. Summary of the Invention

[0004] This application provides a chip test result analysis method and apparatus to solve the technical problems of inaccurate chip test results in the prior art, which cannot reflect real faults or the chip's best performance or potential defects.

[0005] Firstly, this application provides a method for analyzing chip test results, including: Acquire raw chip test data from multiple test passes, the raw chip test data including standard test data format files; Semantic parsing is performed on the raw chip test data to construct test process dependencies, which include logical dependencies between chip test items. For each test item of the chip, the test results of the chip in multiple test passes are merged based on the test process dependency to obtain the final test result of each test item; Output the final test results for all test items of the chip.

[0006] Optionally, semantic parsing is performed on the raw chip test data to construct test process dependencies. These dependencies include logical dependencies between various chip test items, including: Parse the test sequence in the standard test data format file to reconstruct the execution order and branch logic of the test items; Using a keyword database in the field of chip testing, the names of the test items are semantically parsed to identify the test types corresponding to the test items; Based on the execution order, branch logic, and corresponding test types of the test items, construct the test process dependencies for all test items.

[0007] Optionally, for each test item of the chip, the test results of the chip in multiple test passes are merged based on the test process dependency to obtain the final test result for each test item, including: Based on the unique identifier of the chip, each test item in the test item list corresponding to the chip is traversed one by one; Detect the test results of each test item in multiple test passes; If the test result corresponding to the test item is missing data, an anomaly judgment is made on the missing data based on the test process dependency; The final test result for the test item is generated based on the anomaly detection result.

[0008] Optionally, anomaly detection of missing data is performed based on the test process dependencies, including: Based on the test process dependency relationship, query the preceding test items that are dependent on the test item, and whether the test of the preceding test item was successful; If, based on the test process dependencies, it is determined that the missing data is due to the failure of the preceding test item, causing the test item to be skipped, then the missing data is determined to be normal. If, based on the test process dependencies, it is determined that the preceding test item was successful and the test item should not be skipped, then the missing data is determined to be an anomaly.

[0009] Optionally, for each test item of the chip, the test results of the chip in multiple test passes are merged based on the test process dependency to obtain the final test result for each test item, including: If there are conflicts among multiple test results for the same test item, select the corresponding conflict resolution strategy according to the test type corresponding to the test item; The target test result is selected from the multiple test results of the conflict according to the conflict resolution strategy; The target test result is taken as the final test result of the test item.

[0010] Optionally, the method further includes: For each test item, record the corresponding merging strategy information based on the final test result. Generate merge metadata from the merge strategy information; The output of the final test results for all test items of the chip includes: The final test results corresponding to all test items of the chip are merged into a test result data table and output together with the merged metadata.

[0011] Optionally, the method further includes: Obtain the chip manufacturing process data and chip design data corresponding to the chip; The wafer identifier where the chip is located and the absolute coordinates of the chip on the wafer are used as a unified key value. Based on the unified key value, the chip test raw data, the chip manufacturing process data and the chip design data are associated to obtain the parameter association strength between the test item parameters, chip manufacturing parameters and chip design parameters. If the current final test result of the test item is abnormal, query the current chip manufacturing parameters and current chip design parameters associated with the test item parameters according to the parameter association strength; When the historical final test result of the test item is normal, the historical chip manufacturing parameters and historical chip design parameters associated with the test item parameters are obtained. The current chip manufacturing parameters and current chip design parameters are compared with historical chip manufacturing parameters and historical chip design parameters to obtain the parameters that cause test anomalies. The confidence level of each parameter causing test anomalies is calculated based on the correlation strength of the parameters to obtain a root cause list of the test items that cause current test anomalies. The root cause list includes the parameter content of each parameter that causes test anomalies and the confidence level of the test anomalies. Output the list of root causes.

[0012] Secondly, this application provides a chip test result analysis device, comprising: The acquisition module is used to acquire raw chip test data from multiple test passes, wherein the raw chip test data includes a standard test data format file; The dependency construction module is used to perform semantic parsing on the raw chip test data and construct test process dependencies, which include logical dependencies between chip test items. The merging module is used to merge the test results of the chip in multiple test passes based on the test process dependency for each test item of the chip, so as to obtain the final test result of each test item; The output module is used to output the final test results of all test items of the chip.

[0013] Thirdly, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store a computer program; and the processor is used to implement the above-mentioned chip test result analysis method when executing the computer program.

[0014] Fourthly, this application also provides a computer storage medium storing computer-executable instructions, which are used to execute the chip test result analysis method described in any of the above claims of this application.

[0015] Compared with the prior art, the technical solution provided in this application has the following advantages: The method provided in this application, through a test process dependency graph, enables the system to identify "legitimate skips" caused by previous test failures and strictly distinguish them from "abnormal missing values" caused by hardware faults. This avoids misjudging test items that are normally skipped by the program as chip defects, thereby improving the accuracy of yield analysis. Through intelligent merging decision-making, the system can activate corresponding intelligent logic based on data status (conflicts, missing values), rather than applying rigid "one-size-fits-all" rules. The final test results after merging more accurately reflect the actual performance and quality status of each chip, allowing the selection of the most suitable solution for the testing purpose (e.g., the contact test passes on the first attempt, and the performance test takes the best value) when handling conflicting results, ensuring the rationality of the merging decision. Treating test procedures as "understandable logic" rather than "data to be processed" enables computer systems to understand the intentions of test engineers for the first time. This allows for the automatic parsing of complex test process logic, eliminating the need for manually pre-writing complex merging rules for each test scenario. Furthermore, it automatically identifies "abnormal missing values" and triggers alarms, enabling early automatic detection of potential faults in test hardware (such as probe cards and test channels), shifting problem discovery from post-event analysis to the real-time or even during the testing process. This effectively reduces reliance on the personal experience of test engineers and minimizes the workload of manual configuration and subsequent data cleaning. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0019] Figure 1 A flowchart illustrating a chip test result analysis method provided in this application embodiment; Figure 2 A flowchart illustrating a chip test result analysis method provided in another embodiment of this application; Figure 3 A flowchart illustrating a chip test result analysis method provided in another embodiment of this application; Figure 4 A flowchart illustrating a chip test result analysis method provided in another embodiment of this application; Figure 5 A flowchart illustrating a chip test result analysis method provided in another embodiment of this application; Figure 6 A flowchart illustrating a chip test result analysis method provided in another embodiment of this application; Figure 7 A flowchart illustrating a chip test result analysis method provided in another embodiment of this application; Figure 8 A schematic diagram of a chip test result analysis device provided in another embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0022] In existing technologies, the merging of multi-source test data typically relies on parsing Standard Test Data Format (STDF) files and mainly focuses on data-level processing. The specific workflow is as follows: (1) Data format standardization: Convert data from different sources into a unified internal format.

[0023] (2) Coordinate alignment: Data from different channels are matched by wafer coordinates (Wafer ID) and chip coordinates (Die X, Y) to ensure that the data corresponds to the same physical chip.

[0024] (3) Conflict handling: When the results of the same test item are inconsistent in different channels (i.e., there is a conflict), a preset static rule is used to handle the conflict. Common rules include, but are not limited to: always using the result of the first test (FirstHit), always using the result of the last test (Last Hit), or using a certain statistic (such as the average). These rules are usually globally uniform or set through a simple configuration file.

[0025] However, the inventors discovered that the aforementioned existing technical solutions have inherent limitations and cannot effectively cope with the complex dynamic logic and semantic scenarios in chip testing. Their main shortcomings are reflected in the following aspects: (1) Unable to understand the test intent and have difficulty distinguishing between "legitimate skip" and "abnormal missing". Current technologies treat test data as a static, final set of results, assuming that all tests have been performed. However, chip testing procedures actually involve complex conditional checks and jump logic (e.g., if a basic contact test fails, subsequent costly functional and performance tests are skipped to save time). Existing merging tools cannot understand this dynamic nature of the process. When test data is missing, they either simply treat it as invalid or arbitrarily mark it as a failure, failing to distinguish between "legitimate skips" due to preceding failures (which are part of the normal testing process) and "abnormal missing data" caused by hardware issues such as probe card contact problems or test channel malfunctions. This misjudgment directly leads to distorted yield calculations and masks real hardware failures.

[0026] (2) Conflict resolution strategies are rigid and lack intelligence. Existing conflict resolution rules (such as First Hit / Last Hit) are "one-size-fits-all" and fail to consider the physical meaning and purpose of different test items. For example, for contact testing, connectivity can be proven with just one successful attempt, making a "first pass" strategy more reasonable; however, for performance testing (such as maximum speed), the best value among all passes needs to be taken. Rigid rules cannot adapt to the semantic requirements of different test items, potentially leading to merged results that do not accurately reflect the chip's optimal performance or potential defects, thus affecting the accuracy of chip classification.

[0027] (3) The merger process is opaque and has poor traceability. Existing solutions typically only output the final merged result, ignoring the decision-making process that led to that result. When engineers find questions about the merged data, it is difficult to trace which rules were used or which original data from which path were used to arrive at the conclusion, posing significant challenges to root cause analysis (RCA) and data credibility assessment.

[0028] Therefore, the industry urgently needs a chip test data integration method that can understand test logic, make intelligent decisions, and provide complete traceability information to overcome the shortcomings of existing technologies in terms of accuracy, reliability, and maintainability.

[0029] To address the technical problems of inaccurate chip test results in existing technologies, which fail to reflect real faults and the chip's optimal performance or potential defects, this application provides a chip test result analysis method that can understand the test logic and make intelligent decisions.

[0030] Figure 1 This is a flowchart illustrating a chip test result analysis method provided in an embodiment of this application. Figure 1 As shown, the method includes the following steps S11-S14.

[0031] Step S11: Obtain raw chip test data from multiple test passes. The raw chip test data includes standard test data format files.

[0032] The system collects raw chip test data in real time or in batches from the monitoring catalog specified by the Automated Test Equipment (ATE) or Manufacturing Execution System (MES).

[0033] Raw chip testing data includes: Standard Test Data Format (STDF) files generated by multiple test passes (such as CP1, CP2, CP3, etc.) of the Automated Test Equipment (ATE), containing detailed results (parameters, functions, etc.) for each test item; test program logs (.log) generated by the ATE operating system, recording the execution process of the test program, including jumps, conditional judgments, and other information; and summary files containing test program version and batch information. These are standard data sources for characterizing test results and process status in the field of chip testing.

[0034] Step S12: Perform semantic parsing on the raw chip test data and construct test process dependencies, which include the logical dependencies between each chip test item.

[0035] This step involves understanding the test intent and process logic of the test program, replacing the traditional simple merging configuration based on fixed column mapping rules, in order to cope with complex conditional test sequences in chip testing.

[0036] Step S13: For each test item of the chip, the test results of the chip in multiple test passes are merged based on the test process dependency to obtain the final test result of each test item.

[0037] By using the wafer ID and die XY coordinates as unique identifiers, the test results for each test item on each chip are intelligently merged based on the test process dependencies, ultimately yielding the final test result for each test item on each chip.

[0038] Step S14: Output the final test results for all test items of the chip.

[0039] Finally, a complete set of test results data containing all test items for all chips can be output. This test results data can be a wafer map format data table or a CSV file.

[0040] This embodiment utilizes a test process dependency graph to identify "legitimate skips" caused by previous test failures and strictly distinguishes them from "abnormal missing values" caused by hardware malfunctions. This avoids misjudging test items that are skipped normally as chip defects, thereby improving the accuracy of yield analysis. Through intelligent merging decisions, the system can activate corresponding intelligent logic based on data status (conflicts, missing values) instead of applying rigid "one-size-fits-all" rules. The final test results after merging more accurately reflect the actual performance and quality status of each chip, allowing the system to select the most suitable solution for the testing objective when handling conflicting results (e.g., if the contact test passes on the first attempt, the performance test takes the best value), ensuring the rationality of the merging decision.

[0041] This embodiment treats the test program as "understandable logic" rather than "data to be processed," enabling the computer system to understand the test engineer's intent for the first time. It can automatically parse complex test process logic without requiring manual pre-writing of complex merging rules for each test scenario. Furthermore, it can automatically identify "abnormal missing values" and trigger alarms, achieving early automatic detection of potential faults in test hardware (such as probe cards and test channels), shifting problem discovery from post-event analysis to the in-process or even real-time stage. This effectively reduces reliance on the test engineer's personal experience and decreases the workload of manual configuration and subsequent data cleaning.

[0042] The following provides a detailed description of each step in the chip test result analysis method of the embodiments of this application.

[0043] Figure 2 This is a flowchart illustrating a chip test result analysis method according to another embodiment of this application. Figure 2 As shown, step S12 above includes the following steps.

[0044] Step S121: Parse the test sequence in the standard test data format file to restore the execution order and branch logic of the test items.

[0045] Analyze the PTR (Parameter Test Result) and FTR (Functional Test Result) record sequences in the STDF file to reconstruct the execution order and branching logic of the test items defined in the Test Program. Step S122: Using a keyword library in the field of chip testing, semantic parsing is performed on the names of test items to identify the test types corresponding to the test items.

[0046] For test items with specific naming rules in chip testing (such as VDDQ_MIN_FAST@1.2V, IOHT_LEAKAGE), the test item names are semantically decomposed and classified using a keyword library pre-set for the chip testing field (such as "MIN / MAX" for performance screening, "LEAKAGE" for power consumption testing, and "CONTACT" for contact testing).

[0047] For example, it can be identified that "VDDQ" belongs to power supply voltage parameter testing and "FUNCTIONAL" belongs to functional verification testing.

[0048] Step S123: Based on the execution order, branch logic, and corresponding test types of the test items, construct the test process dependencies for all test items.

[0049] Based on the above analysis, a "test flow dependency graph" reflecting the chip testing logic can be constructed. This graph clearly describes the prerequisite-skip relationships between test items, which is a typical feature of chip testing. For example: "If CONTACT_TEST fails, its subsequent FUNCTIONAL_TEST and SPEED_BINNING test items should be marked as 'strictly skipped'."

[0050] In this embodiment, semantic parsing of the chip testing process enables machine understanding of the testing intent, forming test process dependencies for subsequent analysis of test results. Before dependency graph construction, the machine only sees a jumbled collection of data points (PASS / FAIL, measured values); the construction of the dependency graph transforms the machine from "data processing" to "logical understanding." The system no longer mechanically processes data but can understand the logical relationships and execution order between test items. For example, it understands that "contact testing" is a prerequisite for "functional testing," and if contact fails, functional testing becomes meaningless. This provides a unique and accurate basis for all subsequent intelligent decisions.

[0051] Furthermore, when data for a test item is missing, the system queries the dependency graph. If the dependency graph indicates that the test should be skipped due to a previous test failure, it is marked as SKIPPED (valid skip). This avoids misjudging skipped tests as chip failures, thus significantly improving the accuracy of yield calculations. If the dependency graph indicates that the previous test has passed and the test should not be missing, it is marked as ABNORMAL_MISSING (abnormal missing) and an alarm is triggered. This enables early, automatic detection of potential faults in test hardware (such as probe cards), transforming problems from "post-incident discovery" to "in-process warning"; and transforming data loss from an "error state that needs to be masked" to an "information-rich, diagnostic state."

[0052] Furthermore, dependency graphs provide a clear logical chain for merge decisions, transforming the entire process from a "black box" to a "white box." For each merge result (especially skipped or anomaly markers), the system can provide a clear explanation, such as: "This functional test was marked 'skipped' because, according to the dependency graph, its preceding contact test failed." This traceability greatly enhances engineers' confidence in the automated merge results. When batch issues arise, engineers can quickly pinpoint whether the problem lies with chip design / manufacturing or test equipment, significantly accelerating root cause analysis.

[0053] In an optional embodiment, a visual interface for test process dependencies can be provided, allowing testers to view dependencies and perform verification and fine-tuning based on their understanding of the test program, ensuring that the system's understanding of the test intent is consistent with the actual situation.

[0054] Figure 3 This is a flowchart illustrating a chip test result analysis method according to another embodiment of this application. Figure 3 As shown, step S13 above includes the following steps.

[0055] Step S131: Traverse each test item in the test item list corresponding to the chip one by one according to the chip's unique identifier.

[0056] Each chip can be uniquely identified based on its wafer ID and chip coordinates. The process iterates through each chip according to its unique identifier, and then processes each chip's complete list of test items.

[0057] Step S132: Detect the test result of each test item in multiple test passes.

[0058] Step S133: If the test result corresponding to the test item is missing data, perform anomaly judgment on missing data based on the test process dependency relationship.

[0059] In an optional embodiment, step S133 determines the abnormality of missing data based on the test process dependency relationship, including: querying the preceding test items that are dependent on the test item according to the test process dependency relationship, and whether the preceding test item was successfully tested; if it is determined according to the test process dependency relationship that the missing data is due to the failure of the preceding test item causing the test item to be skipped, then the missing data is determined to be normal; if it is determined according to the test process dependency relationship that the preceding test item was successful and the test item should not be skipped, then the missing data is determined to be abnormal.

[0060] Data missing refers to a situation where a certain test item for the same chip has no data record in one or more test passes. For example, chip A's FUNCTIONAL_TEST has a result (PASS) in CP1, but the record for this test item cannot be found in the data file of CP2. In this case, the test process dependencies can be checked to determine if the missing data is a reasonable procedural skip caused by a previous test failure (such as a contact failure or power short circuit). If so, the test item result is marked as SKIPPED; if not (i.e., the dependency diagram shows that the previous test has passed, and this should not be missing), it is marked as ABNORMAL_MISSING, and a test hardware anomaly alarm is triggered, indicating a possible probe card or tester channel hardware failure.

[0061] Step S134: Generate the final test results of the test items based on the anomaly judgment results.

[0062] According to the test program logic, if a preceding, more fundamental test fails, subsequent tests will be automatically skipped to avoid unnecessary testing and potential risks. The final result will be marked as SKIPPED. This will not be considered a chip defect, but rather a normal situation that needs to be correctly understood during yield analysis.

[0063] If, according to the test program logic, all preconditions for a particular test item have been met (i.e., all preconditions have passed), but data for this test item is still missing, this violates the test program's logic. Since the program should execute this test, why is there no result? This is most likely due to a momentary malfunction of the test hardware (such as a probe card or test channel), which is an abnormal situation. The final result is marked as ABNORMAL_MISSING, triggering an alarm. This prompts engineers to check the test hardware to prevent a large number of chips from being mistakenly identified as defective due to hardware problems.

[0064] Existing technologies either simply mark all missing data as "failed" or ignore it altogether, both of which lead to distorted yield calculations. The former underestimates the yield (classifying normally skipped chips as defective), while the latter overestimates it (masking up true hardware faults). In this embodiment, a strategy for handling data missing anomalies based on the logical relationships of the test program intelligently marks test items skipped due to previous test failures as SKIPPED (legitimate skip), which is not considered a chip defect. Therefore, the final calculated yield more accurately reflects the chip's manufacturing and design quality, rather than logical or hardware faults in the testing process, significantly improving data quality and the accuracy of yield analysis.

[0065] Intermittent failures in existing test hardware (such as probe cards and test channels) are difficult to detect, often only emerging after a large number of scrapped products or through periodic, time-consuming manual calibration. In this embodiment, when the system determines a missing item as "unreasonable" (i.e., a previous test passed but failed to execute), it marks it as ABNORMAL_MISSING and triggers an alarm. This is equivalent to embedding a real-time monitoring system into mass production testing, enabling rapid location and alerts to potential hardware problems, such as probe card contamination, pin wear, or channel failure, allowing maintenance personnel to intervene promptly and reduce production losses.

[0066] Furthermore, existing methods treat test result merging as a "black box," meaning engineers cannot determine why a particular test item is null or failed. They must manually trace back the original logs, which is inefficient and error-prone. This implementation records the decision-making basis for each missing value (e.g., "marked as SKIPPED because the dependency graph shows that preceding test A failed"). This provides test engineers with a complete chain of decision-making traceability, greatly enhancing their confidence in the automated merging results and accelerating root cause analysis of anomalous data.

[0067] There exists a situation where the same test item for the same chip is executed in multiple test passes (such as CP1 and CP2), but inconsistent results are obtained. For example, CP1 shows a FAIL (0.95V) result for the VDDQ_MIN test, while CP2 shows a PASS (1.05V). Therefore, it is necessary to intelligently select the most reasonable final result that best represents the chip's true performance from the conflicting results. This embodiment intelligently selects the most reasonable final result that best represents the chip's true performance from the conflicting results.

[0068] Figure 4 This is a flowchart illustrating a chip test result analysis method according to another embodiment of this application. Figure 4 As shown, step S13 above includes the following steps.

[0069] Step S135: If there are conflicts among multiple test results for the same test item, select the corresponding conflict resolution strategy according to the test type corresponding to the test item.

[0070] The test types can include contact tests and performance limit tests. Contact tests (such as CONTACT_TEST) use a first-pass strategy, while performance limit tests (such as SPEED_BINNING, VDDQ_MIN) use a best-performance strategy.

[0071] The purpose of contact testing is to verify whether the physical connection between the tester and the chip is good. If even one pass (e.g., CP1) successfully makes contact and passes the test, it proves that the chip's pins and circuitry are connected. Failures in subsequent passes (e.g., CP2) may be caused by momentary contamination of the probe card, vibration, or other random noise. Therefore, the result of the first pass is considered more reasonable.

[0072] The purpose of performance limit testing is to screen out the chip's capabilities under extreme conditions (such as maximum operating speed, minimum operating voltage). We should take the best result from all passes (such as the highest frequency, lowest voltage) because it represents the upper limit of the chip's potential, ensuring that no chip is "underestimated".

[0073] Step S136: Select the target test result from multiple test results of the conflict according to the conflict resolution strategy; Step S137: Use the target test result as the final test result of the test item.

[0074] Existing methods that use fixed rules (such as always taking the first result) are arbitrary. For example, taking the first result might be reasonable for contact testing, but for performance testing, this could lead to underestimating a chip that could potentially operate at a higher frequency. This embodiment achieves "specific analysis for specific problems" by dynamically selecting a strategy based on the semantic type of the test item. The FIRST_PASS strategy for contact testing is based on the engineering logic that "connectivity only needs to be proven once," avoiding misjudgments caused by momentary interference. The BEST_PERFORMANCE strategy for performance testing is based on the testing objective of "screening out the chip's ultimate capabilities," ensuring that chip potential is not wasted and optimizing the accuracy of chip binning. This means that a high-performance chip will not be incorrectly classified into a low-performance category, thereby increasing product value. This improves the rationality of the merging results and the accuracy of chip classification.

[0075] The essence of conflict resolution strategies is to encode and automate the domain knowledge and technical judgment of test engineers (e.g., "For this type of test, which result should we believe is more reliable"). This intelligent decision-making avoids "false negatives" of promising chips and reduces "false positives" of defective products, directly contributing to improving the quality consistency and reliability of the final product. Simultaneously, through precise grading, the market value of each chip can be maximized.

[0076] Furthermore, when introducing new test items or test processes, only the mapping between their semantic types and conflict resolution strategies needs to be updated, without modifying the core code of the merging engine, thus improving the system's scalability and maintainability. Similar to missing item handling decisions, the system logs the decision for each conflict resolution (e.g., "Use CP2's result; since the test item type is performance testing, the strategy is BEST_PERFORMANCE"). This provides engineers with clear traceability information, enhancing their trust in the automated results and facilitating subsequent review and verification.

[0077] Figure 5 This is a flowchart illustrating a chip test result analysis method according to another embodiment of this application. Figure 5 As shown, the above method also includes the following steps.

[0078] Step S15: Record the merging strategy information corresponding to the final test result of each test item; Step S16: Generate merge metadata from the merge strategy information; Step S14 above includes: merging the final test results corresponding to all test items of the chip into a test result data table, and outputting it together with the merged metadata.

[0079] In this embodiment, the final test results of each test item are output together with the merging strategy information. This allows the output results to be directly used for yield analysis, chip sorting (binning), and quality traceability. It also provides transparent and reliable data support for test engineers to perform root cause analysis (RCA), especially for distinguishing between defects caused by "program skipping" and "hardware anomalies".

[0080] To address the pain point of "knowing what happened, but not why" in chip testing—that is, knowing that a test has failed but finding it difficult to quickly pinpoint whether the problem lies in the manufacturing process or the chip design—this application also provides an embodiment that can enhance the analysis of chip-related data and locate the root cause of abnormal test results.

[0081] Figure 6 This is a flowchart illustrating a chip test result analysis method according to another embodiment of this application. Figure 6 As shown, the above method also includes the following steps.

[0082] Step S21: Obtain chip manufacturing process data and chip design data corresponding to the chip.

[0083] Chip manufacturing process data includes: Wafer Acceptance Test (WAT) parameter tables, Semiconductor Defect Scan Maps (DSM), monitoring parameters for specific process chambers (such as etching, thin film), etc. Chip design data includes: critical path timing files (.timing), a list of hotspot coordinates identified in the physical verification of the layout, etc.

[0084] Step S22: Use the wafer identifier where the chip is located and the absolute coordinates of the chip on the wafer as a unified key value. Based on the unified key value, associate the chip test raw data, chip manufacturing process data and chip design data to obtain the parameter association strength between test item parameters, chip manufacturing parameters and chip design parameters.

[0085] By using the wafer ID and the chip's absolute coordinates (X, Y) on the wafer as a unified key, records from different data sources can be precisely correlated. For example, the coordinates of a failed chip can be mapped to the thin film thickness measurement and layout hotspot database at that location.

[0086] The system can utilize historical batch data and algorithms such as mutual information or Spearman's rank correlation coefficient to calculate the correlation strength between various test parameters (e.g., leakage current, Ileak), process parameters (e.g., gate oxide thickness, Tox), and design parameters (e.g., path delay), automatically generating a "parameter correlation diagram." This diagram can reveal implicit knowledge such as "the failure of a high-speed circuit path is highly correlated with the defect density of nearby metal layers."

[0087] Step S23: If the current final test result of the test item is abnormal, query the current chip manufacturing parameters and current chip design parameters associated with the test item parameters based on the parameter association strength.

[0088] When the system encounters an abnormal cluster failure (e.g., all power supply tests on the same chip in the same row fail), the root cause analysis subprocess is triggered. The engine queries the aforementioned "parameter association graph" to retrieve all process and design parameters associated with the failure location.

[0089] Step S24: Obtain the historical chip manufacturing parameters and historical chip design parameters associated with the test item parameters when the historical final test result of the test item is normal.

[0090] Step S25: Compare the current chip manufacturing parameters and current chip design parameters with the historical chip manufacturing parameters and historical chip design parameters to obtain the parameters that cause test anomalies. Calculate the confidence level of each parameter causing the test anomaly based on the correlation strength of the parameters to obtain a root cause list for the current test anomaly of the test item. The root cause list includes the parameter content of each parameter that causes the test anomaly and the confidence level of the parameter causing the test anomaly.

[0091] By comparing the distribution of these parameters in the current batch with the differences in historical normal yield batches, a root cause list is obtained, such as: "Root cause probability 1 (75%): Chemical mechanical polishing (CMP) thickness uniformity is out of specification; Root cause probability 2 (60%): The density of neighboring hotspot areas 'CLK_BUF_AA' in the layout is too high."

[0092] Step S26: Output the root cause list.

[0093] The final output data table now includes a new "Root_Cause_Hint" field. This field not only provides text hints but also serves as a hyperlink, directly navigating to the relevant process control chart or layout viewer. This elevates test data analysis from the electrical verification level to the process diagnostics level, significantly accelerating the closed-loop process for troubleshooting mass production issues.

[0094] In this embodiment, through a "parameter association graph" and a "spatiotemporal alignment engine," test failures are automatically and in real time associated with potential manufacturing process parameter anomalies (such as uneven CMP thickness) or design layout hotspots (such as excessively high density in specific areas). A root cause suggestion list with confidence levels is directly output (e.g., "Probability 75%: CMP process chamber X parameter drift"), reducing problem troubleshooting from "weeks of manual analysis" to "minutes of automatic diagnosis."

[0095] Furthermore, algorithms (such as mutual information) automatically mine the statistical correlation strength between test parameters, process parameters, and design parameters, forming a "parameter correlation graph." This is equivalent to constructing a cross-domain knowledge graph, capable of discovering complex relationships that are difficult for the human brain to intuitively perceive, such as "the failure of a certain high-speed path is highly correlated with a specific thin film thickness value at the wafer edge." This deep data fusion provides a completely new perspective for understanding the root causes of systemic problems. It breaks down data silos, achieving deep integration and intelligent correlation of manufacturing, design, and testing data.

[0096] Furthermore, test data analysis is upgraded from a simple "quality inspection tool" to a "decision support system for process improvement and design optimization." For manufacturing, it can quickly pinpoint test failures to specific manufacturing stages or equipment chambers, thereby accurately guiding process window optimization and preventative equipment maintenance, improving overall manufacturing yield and stability. For design, it can repeatedly verify whether certain design hotspots actually lead to high failure rates in manufacturing, providing data-driven feedback for optimizing design rules for next-generation products, achieving more manufacturable and robust designs. This shortens the "learning cycle," accelerates technological iteration, and brings long-term competitive barriers and strategic advantages to enterprises.

[0097] The implementation process of the chip test result analysis method of this application will be described in detail below with an example. Figure 7 As shown, the specific process is as follows: (1) Start merging multiple CP test data.

[0098] (2) Data and metadata collection, including STDF files, test program logs, etc.

[0099] (3) Semantic parsing of the test process, specifically including: 31) Parse the test item sequence and result code; 32) Names and types of NLP analysis test items; 33) Construct a test process dependency graph; 34) Determine if an engineer has verified the data; if so, proceed to step 35; otherwise, proceed to step 36. 35) Manually verify and correct dependencies; 36) Complete the dependency graph construction.

[0100] (4) The test is performed repeatedly for each chip, and each test is combined. This includes: 41) Obtain the test item context based on the dependency graph; 42) Check the data status. If multiple results conflict, execute 43); if data is missing, execute 44); if the data is normal, execute 47). 43) Select a conflict resolution strategy based on the semantics of the test items; 44) Query the dependency graph to determine if it can be skipped. If yes, skip it legally and proceed to step 45); otherwise, it indicates an abnormal missing dependency and proceed to step 46). 45) Marked as SKI; 46) Mark as MISSING and trigger an alarm; 47) Directly take the value; 48) Record and merge traceability information; 49) Generate the final merged value.

[0101] (5) Output the merged results and traceability information.

[0102] (6) End.

[0103] This embodiment elevates chip test data integration from a simple, rule-based data post-processing task into an intelligent system capable of understanding test intent, making intelligent decisions, and providing in-depth diagnostic insights. Ultimately, it provides a more accurate, efficient, reliable, and traceable data processing solution for chip mass production testing.

[0104] The technical effects achieved by this embodiment are as follows: 1. Significantly improves data accuracy and reliability Accurately distinguish missing types: By using the test process dependency graph, it can intelligently distinguish between "legitimate skips" and "abnormal missing", avoiding misjudgments of yield and making the final result more accurately reflect chip quality.

[0105] Intelligent data conflict resolution: Dynamically select the optimal merging strategy (such as first pass, best performance) based on the semantics of the test items (such as contactability, performance) to ensure that the merging results best meet the test objectives and optimize chip sorting accuracy.

[0106] 2. Enhance the level of process automation and intelligence Understanding test intent: Treating test programs as parsable logic replaces the model of relying on human experience to configure static rules, thus reducing reliance on human intervention.

[0107] Proactive monitoring and early warning: Automatically identify "abnormal missing" and trigger hardware (such as probe card) fault alarms, turning post-event problem discovery into real-time early warning, and improving production stability.

[0108] 3. Achieve full transparency and traceability throughout the entire process. Decision tracing: Record detailed merging criteria for the final result of each test item (such as the strategy adopted and the reason for skipping), forming a "data passport", which greatly facilitates root cause analysis for test engineers.

[0109] Enhancing data credibility: A transparent decision-making process enables engineers to trust and quickly understand the output of automated systems, thus increasing the credibility of the results.

[0110] The following are embodiments of the apparatus of this application, which can be used to execute the embodiments of the method of this application. Figure 8 This is a block diagram of a chip test result analysis device provided in an embodiment of this application. This device can be implemented as part or all of an electronic device through software, hardware, or a combination of both. Figure 8 As shown, the device includes: The acquisition module 71 is used to acquire raw chip test data from multiple test passes, wherein the raw chip test data includes a standard test data format file; The dependency construction module 72 is used to perform semantic parsing on the chip test raw data and construct test process dependencies, which include logical dependencies between chip test items. The merging module 73 is used to merge the test results of the chip in multiple test passes based on the test process dependency for each test item of the chip, so as to obtain the final test result of each test item; Output module 74 is used to output the final test results of all test items of the chip.

[0111] Optionally, the dependency construction module 72 is used to parse the test sequence in the standard test data format file, restore the execution order and branch logic of the test items; use a keyword library in the chip testing field to perform semantic parsing on the name of the test item, identify the test type corresponding to the test item; and construct the test process dependency relationship of all test items according to the execution order, branch logic and corresponding test type of the test item.

[0112] Optionally, the merging module 73 is configured to traverse each test item in the test item list corresponding to the chip one by one according to the chip's unique identifier; detect the test results of each test item in multiple test passes; if the test result corresponding to the test item is missing data, perform an anomaly judgment on the missing data according to the test process dependency; and generate the final test result of the test item according to the anomaly judgment result.

[0113] Optionally, the merging module 73 is used to query the preceding test items that are dependent on the test item according to the test process dependency relationship, and whether the test of the preceding test item was successful; if it is determined according to the test process dependency relationship that the data missing is due to the failure of the preceding test item causing the test item to be skipped, then the data missing is determined to be normal; if it is determined according to the test process dependency relationship that the preceding test item was successful but the test item should not be skipped, then the data missing is determined to be abnormal.

[0114] Optionally, the merging module 73 is used to select a corresponding conflict resolution strategy according to the test type corresponding to the test item if there are conflicts among multiple test results for the same test item; select a target test result from the multiple conflicting test results according to the conflict resolution strategy; and use the target test result as the final test result of the test item.

[0115] Optionally, the device may also include: The recording module is used to record the merging strategy information corresponding to the final test result of each test item; The merging module is used to generate merging metadata from the merging strategy information; The output module is used to merge the final test results corresponding to all test items of the chip into a test result data table, and output it together with the merged metadata.

[0116] Optionally, the device may also include: The relevant data acquisition module is used to acquire chip manufacturing process data and chip design data corresponding to the chip; The association module is used to use the wafer identifier where the chip is located and the absolute coordinates of the chip on the wafer as a unified key value, and associate the chip test raw data, the chip manufacturing process data and the chip design data according to the unified key value to obtain the parameter association strength between the test item parameters, chip manufacturing parameters and chip design parameters. The query module is used to query the current chip manufacturing parameters and current chip design parameters associated with the test item parameters based on the parameter association strength if the current final test result of the test item is abnormal. The historical data acquisition module is used to acquire the historical chip manufacturing parameters and historical chip design parameters associated with the test item parameters when the historical final test result of the test item is normal. The root cause analysis module is used to compare the current chip manufacturing parameters and current chip design parameters with historical chip manufacturing parameters and historical chip design parameters to obtain the parameters that cause test anomalies, and calculate the confidence level of each parameter causing test anomalies based on the correlation strength of the parameters to obtain a root cause list of the test items that cause current test anomalies. The root cause list includes the parameter content of each parameter that causes test anomalies and the confidence level of the test anomalies. The output module is used to output the root cause list.

[0117] like Figure 9 As shown in the figure, this application provides an air conditioner control device, including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114. Memory 113 is used to store computer programs; In one embodiment of this application, the processor 111, when executing the program stored in the memory 113, implements the chip test result analysis method provided in any of the foregoing method embodiments.

[0118] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the chip test result analysis method provided in any of the foregoing method embodiments.

[0119] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0120] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0121] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also mean including the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0122] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for analyzing chip test results, characterized in that, include: Acquire raw chip test data from multiple test passes, the raw chip test data including standard test data format files; Semantic parsing is performed on the raw chip test data to construct test process dependencies, which include logical dependencies between chip test items. For each test item of the chip, the test results of the chip in multiple test passes are merged based on the test process dependency to obtain the final test result of each test item; Output the final test results for all test items of the chip.

2. The method according to claim 1, characterized in that, Semantic parsing is performed on the raw chip test data to construct test process dependencies. These dependencies include logical dependencies between various chip test items, including: Parse the test sequence in the standard test data format file to reconstruct the execution order and branch logic of the test items; Using a keyword database in the field of chip testing, the names of the test items are semantically parsed to identify the test types corresponding to the test items; Based on the execution order, branch logic, and corresponding test types of the test items, construct the test process dependencies for all test items.

3. The method according to claim 2, characterized in that, For each test item of the chip, the test results of the chip in multiple test passes are merged based on the test process dependencies to obtain the final test result for each test item, including: Based on the unique identifier of the chip, each test item in the test item list corresponding to the chip is traversed one by one; Detect the test results of each test item in multiple test passes; If the test result corresponding to the test item is missing data, an anomaly judgment is made on the missing data based on the test process dependency; The final test result for the test item is generated based on the anomaly detection result.

4. The method according to claim 3, characterized in that, Based on the aforementioned test process dependencies, anomaly detection for missing data is performed, including: Based on the test process dependency relationship, query the preceding test items that are dependent on the test item, and whether the test of the preceding test item was successful; If, based on the test process dependencies, it is determined that the missing data is due to the failure of the preceding test item, causing the test item to be skipped, then the missing data is determined to be normal. If, based on the test process dependencies, it is determined that the preceding test item was successful and the test item should not be skipped, then the missing data is determined to be an anomaly.

5. The method according to claim 2, characterized in that, For each test item of the chip, the test results of the chip in multiple test passes are merged based on the test process dependencies to obtain the final test result for each test item, including: If there are conflicts among multiple test results for the same test item, select the corresponding conflict resolution strategy according to the test type corresponding to the test item; The target test result is selected from the multiple test results of the conflict according to the conflict resolution strategy; The target test result is taken as the final test result of the test item.

6. The method according to claim 1, characterized in that, The method further includes: For each test item, record the corresponding merging strategy information based on the final test result. Generate merge metadata from the merge strategy information; The output of the final test results for all test items of the chip includes: The final test results corresponding to all test items of the chip are merged into a test result data table and output together with the merged metadata.

7. The method according to claim 1, characterized in that, The method further includes: Obtain the chip manufacturing process data and chip design data corresponding to the chip; The wafer identifier where the chip is located and the absolute coordinates of the chip on the wafer are used as a unified key value. Based on the unified key value, the chip test raw data, the chip manufacturing process data and the chip design data are associated to obtain the parameter association strength between the test item parameters, chip manufacturing parameters and chip design parameters. If the current final test result of the test item is abnormal, query the current chip manufacturing parameters and current chip design parameters associated with the test item parameters according to the parameter association strength; When the historical final test result of the test item is normal, the historical chip manufacturing parameters and historical chip design parameters associated with the test item parameters are obtained. The current chip manufacturing parameters and current chip design parameters are compared with historical chip manufacturing parameters and historical chip design parameters to obtain the parameters that cause test anomalies. The confidence level of each parameter causing test anomalies is calculated based on the correlation strength of the parameters to obtain a root cause list of the test items that cause current test anomalies. The root cause list includes the parameter content of each parameter that causes test anomalies and the confidence level of the test anomalies. Output the list of root causes.

8. A chip test result analysis device, characterized in that, include: The acquisition module is used to acquire raw chip test data from multiple test passes, wherein the raw chip test data includes a standard test data format file; The dependency construction module is used to perform semantic parsing on the raw chip test data and construct test process dependencies, which include logical dependencies between chip test items. The merging module is used to merge the test results of the chip in multiple test passes based on the test process dependency for each test item of the chip, so as to obtain the final test result of each test item; The output module is used to output the final test results of all test items of the chip.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory is used to store computer programs; the processor is used to execute the computer programs to implement the chip test result analysis method according to any one of claims 1-7.

10. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the chip test result analysis method according to any one of claims 1-7.

Images