Chip function module testing method, device, storage medium and program product

Abstract

The application discloses a chip function module test method, equipment, a storage medium and a program product, relates to the chip test technical field, and the chip function module test method comprises the following steps: when system-level test of a chip fails, if the reason of the test failure of this time is related to a function module of a target chip of the test failure, the function module in the target chip is tested through a target test case, a damaged function module set is determined and the corresponding function module is disabled, if the target chip still meets the specification requirement standard after the damaged function module set is disabled, system-level test of the target chip is performed again, and a test result is obtained. Therefore, the function module of the chip is tested again, and the system-level test is performed again, so that the chip, which fails in the system-level test due to the fact that the damaged function module, which is not correctly identified in the final test of the test vector designed based on the test, is saved, and therefore, the yield of the chip is improved.

Description

Technical Field

[0001] This application relates to the field of chip testing technology, and in particular to chip functional module testing methods, equipment, storage media and program products. Background Technology

[0002] Chip production is affected by factors such as manufacturing process deviations and inherent manufacturing defects, resulting in a certain chip failure rate, which in turn affects the yield. For high-value chip products, in order to maximize the yield, a certain degree of design redundancy is usually implemented internally.

[0003] Current methods identify faulty C blocks (functional modules) in the chip during the Final Test (FT) stage, replace them with redundant functional modules, and then perform subsequent System Level Test (SLT). However, the test coverage of the FT is not 100%, and faulty functional modules may still exist during the subsequent SLT, causing the chip to fail the SLT and be discarded, resulting in a low chip yield. Summary of the Invention

[0004] The main purpose of this application is to provide a chip functional module testing method, equipment, storage medium, and program product, aiming to solve the technical problem of low chip yield.

[0005] To achieve the above objectives, this application proposes a chip functional module testing method, the method comprising: When a chip's system-level test fails, determine whether the reason for the failure is related to the functional module of the target chip that failed the test. If relevant, the functional modules in the target chip are tested using preset target test cases to determine the set of damaged functional modules; Disable the corresponding functional modules in the set of damaged functional modules, and determine whether the target chip still meets the preset qualification standards; If the conditions are met, the system-level test of the target chip is repeated to obtain the test results.

[0006] In one embodiment, the step of testing the functional modules in the target chip using preset target test cases to determine the set of damaged functional modules includes: Based on the target test cases, each of the functional modules in the target chip is tested to obtain a first test result corresponding to each functional module, and the first test result is stored in a preset first fuse bit; Obtain the second test result stored in the preset second fuse bit, wherein the second test result is the result of testing each functional module of the target chip in the final test of the test vector designed based on the test; Based on the first test results and the second test results, the set of damaged functional modules is determined.

[0007] In one embodiment, the step of determining the set of damaged functional modules based on the first test result and the second test result includes: For each functional module in the target chip, determine the first test result and the second test result corresponding to the functional module; If the first test result is a test failure, or the second test result is a test failure, then the functional module is determined to be a damaged functional module; Based on each of the damaged functional modules, the set of damaged functional modules is determined.

[0008] In one embodiment, the step of testing each functional module in the target chip based on the target test cases to obtain a first test result corresponding to each functional module includes: Among all the functional modules of the target chip, a number of functional modules to be tested are identified. Based on the target test cases, the functional module to be tested is subjected to isolation scan testing to obtain preliminary test results; If the preliminary test result is that the test is passed, the functional module to be tested is determined to be intact. Among the functional modules other than the functional module to be tested that are not determined to be intact, the functional modules to be tested that need to be tested are determined. Returning to the step of performing isolated scanning tests on the functional modules to be tested based on the target test case to obtain preliminary test results, until all the functional modules have been tested and the first test result is obtained.

[0009] In one embodiment, after the step of performing isolation scan testing on the functional module to be tested based on the target test case to obtain preliminary test results, the method further includes: If the preliminary test result is that the test fails, it is determined that there is a damaged functional module in the functional module to be tested, and a new functional module to be tested is determined in the functional module to be tested. Returning to the step of performing isolated scanning tests on the functional modules to be tested based on the target test case to obtain preliminary test results, until all the functional modules have been tested and the first test result is obtained.

[0010] In one embodiment, the step of determining whether the reason for the failure of the current test is related to the functional module of the target chip includes: Read the test log of the target chip for the current test; Based on the test logs, the test type for the current test is determined, wherein the test type includes functional module testing; If the test type is the functional module test, then the reason for the failure of the current test is determined to be related to the functional module of the target chip.

[0011] In one embodiment, the step of disabling the corresponding functional modules in the set of damaged functional modules and determining whether the target chip still meets the preset qualification criteria includes: Based on the set of damaged functional modules, determine the damaged functional modules that need to be disabled; Disable the damaged functional modules and determine the number of functional modules in the target chip that are not disabled; If the number of functional modules is not less than a preset threshold for the number of functional modules, then the target chip is determined to meet the qualification standard.

[0012] In addition, to achieve the above objectives, this application also proposes a chip functional module testing device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the chip functional module testing method described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the chip functional module testing method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the chip functional module testing method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: When the system-level test of the chip fails, this application determines whether the reason for the failure is related to the functional modules of the target chip. If so, it tests the functional modules in the target chip using preset target test cases, determines the set of damaged functional modules, disables the corresponding functional modules in the set of damaged functional modules, and determines whether the target chip still meets the preset qualification standard. If it does, the system-level test of the target chip is repeated to obtain the test result.

[0016] Compared to current methods where the final test coverage of functional modules is not 100%, and faulty functional modules still exist during subsequent system-level testing, causing the chip to fail system-level testing and be discarded, resulting in a low chip yield, this application improves chip yield by testing the functional modules within the chip, preventing the discard of intact chips. Specifically, for target chips that should have been discarded due to test failure, this application tests the functional modules when the cause of the test failure is determined to be related to a functional module, thereby identifying the damaged functional modules that were not successfully detected in the final test. By disabling the damaged functional modules and retesting them when they meet preset pass criteria, the damaged functional modules can be prevented from affecting the results of system-level testing, thus obtaining the final test results. Therefore, this application's retesting of functional modules and re-performing system-level testing can salvage chips that failed system-level testing due to the final failure to correctly identify damaged functional modules, thereby improving chip yield. Attached Figure Description

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

[0018] To more clearly illustrate the technical solutions in the embodiments of this application 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.

[0019] Figure 1 This is a flowchart illustrating an embodiment of the chip functional module testing method of this application. Figure 2 This is a schematic diagram of the internal redundancy design of the chip provided in Embodiment 1 of the chip functional module testing method of this application; Figure 3 This is a traditional wafer schematic diagram provided for Embodiment 1 of the chip functional module testing method of this application; Figure 4 This is a schematic diagram of the traditional chip testing steps provided in Embodiment 1 of the chip functional module testing method of this application; Figure 5 This is a schematic diagram of the chip testing steps provided in Embodiment 1 of the chip functional module testing method of this application; Figure 6 This is a flowchart illustrating Embodiment 2 of the chip functional module testing method of this application; Figure 7This is a schematic diagram of the device structure of the hardware operating environment involved in the chip functional module testing method in the embodiments of this application; Figure 8 This is a schematic diagram illustrating the data acquisition consent process involved in the chip functional module testing method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or chip functional module testing device capable of performing the above functions. The following description uses a chip functional module testing device as an example to illustrate this embodiment and the subsequent embodiments.

[0024] Chip production is affected by factors such as manufacturing process deviations and inherent manufacturing defects, resulting in a certain chip failure rate, which in turn affects the yield. For high-value chip products, in order to maximize the yield, a certain degree of design redundancy is usually implemented internally.

[0025] Current methods identify faulty C blocks (functional modules) in the chip during the final testing (FT) stage, replace them with redundant functional modules, and then perform subsequent system-level testing (SLT). However, the FT does not provide 100% coverage of functional modules. Faulty functional modules may still be present during the subsequent SLT, causing the chip to fail the SLT and be discarded, resulting in a low yield rate.

[0026] Based on this, embodiments of this application provide a chip functional module testing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the chip functional module testing method of this application.

[0027] In this embodiment, the chip functional module testing method includes steps S10 to S40: Step S10: When the system-level test of the chip fails, determine whether the reason for the failure of the current test is related to the functional module of the target chip that failed the test. It should be noted that System-Level Testing (SLT) refers to the testing phase after the chip is packaged, where it is placed on a circuit board simulating a real-world application environment and test cases from real-world application scenarios are run to verify whether the chip functions correctly in a real system. The target chip refers to the specific chip that is determined to have failed a certain test in the current testing process. A functional module (C block) refers to an independent circuit unit within the chip designed to implement a specific function.

[0028] It should also be noted that the internal redundancy design of the chip in this embodiment can refer to... Figure 2 In the diagram, P1, P2, P3, P4, and C represent different functional blocks within the chip. Block C is reused 132 times within the chip. Due to manufacturing process variations and inherent defects mentioned above, it's difficult to guarantee that all 132 C blocks will be intact in the manufactured chip; some will be faulty. According to the SPEC (Specification) requirements, a maximum of 128 C blocks need to function properly. This is a method of improving chip yield through redundant design.

[0029] Understandably, a schematic diagram of the wafer can be referenced. Figure 3 , Figure 3 Including wafers, chips / dies, dicing channels, test cells, edge dies, and dicing surfaces, traditional chip testing procedures can be referenced. Figure 4 , from Figure 4 The process flow shows that from CP (Chip Probe Test) to FT (Flat Test) and then to SLT (Standard Test), only chips that pass the previous step are sent to the next. Ultimately, only chips that pass all these tests are considered good enough to ship. This is because the testing environments, test cases, and test coverage for CP, FT, and SLT are all different. A chip undergoing wafer testing might actually be defective; due to the testing environment, test cases, and test coverage, the problem might not have been detected and would have been missed in the next testing stage, hoping that the next test would catch it.

[0030] Specifically, in the final testing phase of a chip, functional modules C102 and C129 were found to be faulty. Due to redundant design, there were still 132-2=130 functional modules that were intact, exceeding the requirement of 128 intact functional modules. Therefore, this chip was considered to have passed the final test and was a good chip, and was sent to the system-level test for further testing. However, due to coverage issues in the final test, it failed to detect that functional module C70 was also faulty. Consequently, it failed the system-level test and was correctly identified as a faulty chip and discarded.

[0031] However, even if the three functional modules C70, C102, and C129 are all faulty, it still meets the requirement of having more than 128 intact functional modules, and can still be shipped as a good chip. The problem lies in the final test's non-100% coverage of the functional modules. The final test did not correctly identify all the faulty C blocks, leading to the failure of the system-level test. This is because the system-level test relies entirely on the final test's identification and does not consider the possibility of the final test misidentifying the faulty blocks.

[0032] Therefore, in this embodiment, after a system-level test fails, the target chip is not directly determined to be a final defective product. Instead, the failure reason is further analyzed to see if it is related to a specific functional module. This allows for the accurate identification of chips that fail only due to functional module problems but have potential repair value, thus avoiding the indiscriminate discarding of all chips that fail system-level tests.

[0033] In one feasible implementation, the specific implementation of determining whether the reason for the failure of the current test is related to the functional module of the target chip can also be: Read the test log of the target chip for the current test, and determine the test type of the current test based on the test log. The test type includes functional module test. If the test type is the functional module test, it is determined that the reason for the failure of the current test is related to the functional module of the target chip.

[0034] It should be noted that the test log refers to the file that automatically records test execution and result information during chip testing. This includes detailed information such as the test case name, test item, test time, pass / fail status, and error message upon failure. The test type refers to the category by which test cases are classified according to test purpose or test object, such as functional module testing, interface testing, performance testing, etc., used to identify the scope of chip functionality being tested.

[0035] Understandably, when a target chip fails during system-level testing, the first step is to read the automatically generated test logs from that test. Based on the information recorded in the test logs, the test type corresponding to the failure is analyzed and determined. Test types include functional module tests specifically designed to detect functional modules. If it is determined that the test type corresponding to the failure is indeed a functional module test, then the failure of the target chip is considered to be related to a functional module within the chip. Therefore, this implementation method achieves rapid and objective determination of the correlation between the failure cause and the functional module by automatically parsing the test type information in the test logs.

[0036] Furthermore, since this implementation method uses automated reading and identification of test types in the test log to determine whether the failure reason is related to the functional module, rather than relying on subjective analysis based on human experience, it can greatly improve the judgment efficiency and reduce the possibility of human misjudgment or omission.

[0037] Step S20: If relevant, test the functional modules in the target chip using preset target test cases to determine the set of damaged functional modules; It should be noted that a target test case refers to a set of test instructions or programs designed to achieve a specific testing purpose. This test case can independently start, run, and test each functional module inside the chip according to a predetermined order and method. A set of damaged functional modules refers to a summary record of one or more functional modules that, after passing the test, are identified as defective and unable to function properly.

[0038] Understandably, if the failure of the target chip in system-level testing is related to a functional module, a specially designed target test case is initiated. This test case can sequentially and individually activate each functional module in the target chip, making it operational, while disabling the remaining functional modules, thereby independently testing the integrity of each functional module. Through the execution of this test case, all functional modules with actual defects can be accurately identified, and the records of these modules can be summarized to form a set of damaged functional modules. This allows for the independent and precise location of all damaged functional modules in the target chip without relying on previous test results.

[0039] In this embodiment, after confirming that the failure is related to a functional module, the previous test records were not used. Instead, each functional module was independently and proactively scanned and verified one by one through dedicated target test cases. This allowed for the accurate identification of all damaged functional modules and the formation of a set of damaged functional modules, so as to accurately determine whether the chip still meets the specifications in the subsequent process.

[0040] Step S30: Disable the corresponding functional module in the set of damaged functional modules, and determine whether the target chip still meets the preset qualification standard; It should be noted that disabling refers to using internal chip configuration methods to prevent a specified functional module from participating in operation and contributing functionality under normal chip conditions, thereby avoiding the impact of its defects on the overall chip functionality. Acceptance criteria refer to the minimum performance or functional requirements that a chip must meet to be considered a qualified product, usually defined by a threshold number of intact functional modules.

[0041] In one feasible implementation, the specific implementation of disabling the corresponding functional modules in the set of damaged functional modules and determining whether the target chip still meets the preset qualification standard can also be: Based on the set of damaged functional modules, the damaged functional modules that need to be disabled are determined, the damaged functional modules are disabled, and the number of undisabled functional modules in the target chip is determined. If the number of functional modules is not less than a preset threshold for the number of functional modules, then the target chip is determined to meet the qualification standard.

[0042] It should be noted that the functional module number threshold refers to the minimum number of intact functional modules required for a chip to be considered a qualified product. This threshold is determined by the chip's specifications. For example, if the chip specifications require at least 128 intact functional modules to function properly, then the threshold is 128. The number of non-disabled functional modules refers to the total number of functional modules remaining in the target chip after disabling all identified damaged functional modules in the set of damaged functional modules.

[0043] Understandably, after obtaining the set of damaged functional modules, this embodiment identifies all damaged functional modules in the set as objects that need to be disabled in the target chip and disables them through configuration. After the disabling operation is completed, the number of functional modules in the target chip that have not been disabled is counted, that is, the total number of functional modules that can still work normally. This number is compared with the functional module number threshold preset in the chip specification. If the number of functional modules that have not been disabled is greater than or equal to the threshold, the target chip is determined to meet the qualification standard and can be used as a salvageable chip in subsequent processes, thereby avoiding misjudgments that may be caused by insufficient test coverage in traditional solutions.

[0044] Step S40: If the conditions are met, the system-level test of the target chip is repeated to obtain the test results.

[0045] Understandably, if the target chip still meets the preset acceptance criteria after disabling the damaged functional module, it will be resubmitted to the system-level testing phase for a complete system-level testing process. After the retest is completed, the final result is recorded as the final determination of whether the target chip can be ultimately deemed a qualified product. This embodiment verifies the integrity of the chip's overall functionality again in a real-world application scenario after isolating the damaged module, ensuring that the chip truly meets shipping requirements after repair. The chip testing process in this embodiment can be referred to... Figure 5 .

[0046] This embodiment, based on the determination that the target chip meets the qualification standards, re-performs a complete system-level test on the chip, thereby verifying its overall functional performance after disabling the damaged modules in the chip's actual operating environment. Through the above steps, this embodiment not only ensures the accuracy of identifying the preceding damaged modules but also ensures that while the chip meets the quantity threshold, its remaining intact modules can work together normally in practical applications. This final verification allows the salvaged chip to achieve the same shipment standards as traditional good chips, thus effectively improving chip yield without compromising product quality.

[0047] In summary, when the system-level test of the chip fails, this embodiment determines whether the reason for the failure is related to the functional modules of the target chip. If so, it tests the functional modules in the target chip using preset target test cases, identifies the set of damaged functional modules, disables the corresponding functional modules in the set of damaged functional modules, and determines whether the target chip still meets the preset qualification standards. If it does, it re-performs the system-level test of the target chip to obtain the test results.

[0048] Compared to current methods where the final test coverage of functional modules is not 100%, and faulty functional modules still exist during subsequent system-level testing, causing the chip to fail system-level testing and be discarded, resulting in a low chip yield, this application improves chip yield by testing the functional modules within the chip, preventing the discard of intact chips. Specifically, for target chips that should have been discarded due to test failure, this application tests the functional modules when the cause of the test failure is determined to be related to a functional module, thereby identifying the damaged functional modules that were not successfully detected in the final test. By disabling the damaged functional modules and retesting them when they meet preset pass criteria, the damaged functional modules can be prevented from affecting the results of system-level testing, thus obtaining the final test results. Therefore, this application's retesting of functional modules and re-performing system-level testing can salvage chips that failed system-level testing due to the final failure to correctly identify damaged functional modules, thereby improving chip yield.

[0049] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 6 Step S20, the chip functional module testing method further includes steps S21~S23: Step S21: Based on the target test cases, test each of the functional modules in the target chip to obtain the first test result corresponding to each functional module, and store the first test result in a preset first fuse bit; It should be noted that the first test result refers to the judgment information regarding the integrity of each functional module obtained after independently testing each functional module using the target test cases. Each functional module corresponds to an independent test result. The first fuse bit refers to a set of fuse storage units preset inside the chip, used to permanently record information related to the functional module test. In this embodiment, the first fuse bit is dedicated to storing the obtained first test result. The fuse bit is a one-time programmable storage unit that records binary information by fusing or holding its state.

[0050] Understandably, after the target test case is initiated, it independently starts and tests each functional module in the target chip. Upon completion of the test for each functional module, a first test result is generated to indicate whether the module is intact or damaged. This first test result is then written to a pre-defined first fuse bit within the chip. Each functional module's test result is stored in a specific fuse bit, thus non-volatilely storing the integrity information of each functional module obtained through this independent test within the chip.

[0051] In one feasible implementation, the specific implementation of testing each functional module in the target chip based on the target test cases to obtain the first test result corresponding to each functional module can also be: Among all the functional modules of the target chip, a number of functional modules to be tested are identified. Based on the target test cases, isolated scan tests are performed on the functional modules to be tested to obtain preliminary test results. If the preliminary test results are that the test is passed, the functional module to be tested is determined to be intact. Among the functional modules outside the functional modules to be tested that are not determined to be intact, the functional modules to be tested that need to be tested are identified. The process of performing isolated scan tests on the functional modules to be tested based on the target test cases to obtain preliminary test results is returned until all the functional modules are tested and the first test result is obtained.

[0052] It should be noted that the functional modules to be tested refer to a group of functional modules selected in the current test round as the ones for which the target test cases need to be executed. The preliminary test results refer to the information obtained after performing overall testing on the currently selected functional modules to be tested, regarding whether there are any damaged modules in this group of modules.

[0053] It is understood that this implementation method, when testing functional modules based on target test cases, does not test individual functional modules one by one, but rather adopts a grouped iterative testing approach. First, a batch of functional modules to be tested is selected from all functional modules of the target chip. This batch of modules is then subjected to overall testing using the target test cases to obtain preliminary test results. If the overall test of this batch of modules passes, all functional modules in that batch are determined to be intact. Subsequently, from the remaining functional modules that have not yet been determined to be intact, the next batch of functional modules to be tested is selected, and the overall testing step is returned to, repeating the above process. This iterative process continues until all functional modules of the target chip have been covered and tested, and finally, the first test results for each functional module are obtained.

[0054] Because this implementation combines multiple functional modules into a group for overall testing, once the group passes the test, all modules in the group can be confirmed as intact at once, eliminating the need to test each module individually. This significantly reduces the number of test cases that need to be executed. Simultaneously, by iteratively filtering out intact modules in batches and gradually converging the testing focus to potentially damaged modules, the overall testing process becomes more efficient. This implementation optimizes the execution efficiency of the testing process while maintaining accurate identification of damaged modules. When there are a large number of functional modules and a high percentage of intact modules, it can effectively shorten the functional module scanning time in the system-level testing phase.

[0055] In one feasible implementation, the specific implementation following the step of performing isolation scan testing on the functional module to be tested based on the target test cases to obtain preliminary test results can also be: If the preliminary test result is that the test fails, it is determined that there is a damaged functional module in the functional module to be tested. A new functional module to be tested is re-determined in the functional module to be tested, and the process of performing isolation scan test on the functional module to be tested based on the target test case to obtain the preliminary test result is repeated until all functional modules are tested and the first test result is obtained.

[0056] Understandably, in this embodiment, after performing overall testing on the functional modules to be tested and obtaining preliminary test results, if the preliminary test result is a failure, it indicates that at least one functional module in this batch of functional modules to be tested is faulty. At this point, this embodiment narrows down the grouping scope within this batch of functional modules to be tested and regroups them, identifying a new group of functional modules to be tested, and returns to the overall testing step to perform overall testing again on the newly identified functional modules to be tested. By repeatedly executing the above iterative process, the actual faulty functional modules in this batch are gradually located until all functional modules have been tested, and finally, the first test result corresponding to each functional module is obtained.

[0057] When the initial test result indicates a failure, this implementation method employs a recursive grouping approach. From the batches where faulty modules have been identified, new functional modules to be tested are re-determined and tested as a whole, thereby gradually narrowing down the scope of faulty modules. Compared to testing one by one, this implementation method significantly reduces the number of test cases that need to be executed. Even with a small number of faulty modules, it can quickly locate specific faulty functional modules, significantly improving testing efficiency while maintaining identification accuracy and reducing the overall testing time overhead in the system-level testing phase.

[0058] Step S22: Obtain the second test result stored in the preset second fuse bit, wherein the second test result is the result of testing each functional module of the target chip in the final test of the test vector designed based on the test; It should be noted that the second fuse bit refers to another set of fuse storage units preset inside the chip, independent of the first fuse bit, used to permanently record information related to functional module testing. In this embodiment, the second fuse bit is dedicated to storing the test results obtained in the final testing phase. The second test result refers to the judgment information on whether each functional module is intact after testing each functional module in the target chip in the final testing phase. Each functional module corresponds to an independent test result.

[0059] It is understood that, in this embodiment, after storing the test results of the target test case in the first fuse bit, the stored second test result is further read from the preset second fuse bit inside the chip. This second test result is the judgment information recorded after testing each functional module of the target chip during the final testing phase of the chip manufacturing process. By reading the second fuse bit, this embodiment obtains another set of independent records from the final testing phase regarding the integrity status of each functional module, thereby allowing the test results of the same chip functional module from different testing phases to be aggregated.

[0060] Since the two sets of test results come from different test stages and may be based on different test coverage and test conditions, by aggregating these two independently obtained test results into the same processing flow, more comprehensive and complete information on damaged functional modules can be provided for subsequent steps. This can compensate for the missed detection problem that may be caused by insufficient test coverage in a single test stage and improve the accuracy of judging the actual good condition of the chip.

[0061] Step S23: Based on the first test result and the second test result, determine the set of damaged functional modules.

[0062] It is understood that this embodiment uses both first and second test results when determining the set of damaged functional modules. The first test result comes from an independent scan during the system-level testing phase, while the second test result comes from test records during the final testing phase. These two sets of test results are based on different testing environments, test cases, and test coverage, and each may identify damaged modules that the other may have missed. By combining these two sets of results, the potential for missed detections due to insufficient test coverage in a single testing phase can be effectively mitigated, resulting in a more comprehensive and accurate identification of the damaged modules.

[0063] In one feasible implementation, the specific implementation of determining the set of damaged functional modules based on the first test result and the second test result may also be: For each functional module in the target chip, a first test result and a second test result corresponding to the functional module are determined. If the first test result is a test failure or the second test result is a test failure, the functional module is determined to be a damaged functional module. Based on each damaged functional module, a set of damaged functional modules is determined.

[0064] It should be noted that "test failed" means that in a certain testing phase, after testing a specific functional module, the test conclusion is that the functional module has defects and cannot work properly.

[0065] Understandably, after obtaining the first and second test results, for each functional module in the target chip, its judgment status in the first test result and its judgment status in the second test result are obtained respectively. For the currently being processed functional module, if the first test result shows that the module failed the test, or the second test result shows that the module failed the test, then the functional module is identified as a damaged functional module. After traversing all functional modules in the target chip according to the above logic, all functional modules identified as damaged are summarized to obtain the set of damaged functional modules.

[0066] This implementation combines the results of two independent testing phases using an "OR" logic to identify damaged modules with the most stringent standards. It fully utilizes the test coverage capabilities of each phase, ensuring that no damaged module detected in either phase is missed. This effectively overcomes the potential for missed detections due to insufficient test coverage in a single testing phase, resulting in a more comprehensive and accurate final set of identified damaged functional modules.

[0067] In one embodiment, the step of determining the set of damaged functional modules based on the first test result and the second test result further includes: For each functional module, compare the state of the functional module in the first test result with the state of the functional module in the second test result. If both are intact, the functional module is marked as a first-priority intact module. If there is a discrepancy between the two, the functional module is marked as a second-priority module to be verified. If both are damaged, the functional module is marked as a damaged module and directly included in the set of damaged functional modules.

[0068] For each functional module marked as a second priority module to be verified, the target test case is re-executed to independently verify it, a third test result is generated, and the functional module is determined to be a good module or a damaged module based on the third test result.

[0069] The first damaged functional module, which is directly included in the damaged functional module set, is combined with the second damaged functional module determined according to the third test result to form a damaged functional module set. The identification information corresponding to all damaged modules in this set is written into the preset third fuse bit as the final damaged functional module record of the target chip.

[0070] It should be noted that the first priority intact module refers to a functional module that is judged to be intact in both the first and second test results. This type of module has the highest confidence level of integrity. The second priority unverified module refers to a functional module whose judgment results are inconsistent in the first and second test results, that is, a module judged to be intact in one test phase and damaged in another test phase. This type of module needs further verification to determine its true state. The third test result refers to the judgment information on whether the functional module is intact obtained after independently verifying the second priority unverified module by re-executing the target test cases. The third fuse bit refers to another set of fuse storage units preset inside the chip, independent of the first and second fuse bits, used to permanently record the information of the finally damaged functional module determined after comprehensive verification.

[0071] Understandably, this embodiment divides functional modules into three priorities for processing. Modules with consistent test results are directly judged, while modules with inconsistent results undergo secondary independent verification. This avoids indiscriminate repeated testing of all modules while ensuring identification accuracy. The secondary verification of the second-priority modules effectively resolves the judgment conflict caused by differences in test coverage or test environment at different testing stages, effectively improving the identification accuracy of the ultimately damaged modules.

[0072] Furthermore, this embodiment writes the finally confirmed damaged module information into the third fuse bit, so that subsequent system-level tests can directly read the record to disable the module and optimize the test, without having to repeatedly perform functional module scanning during each system-level test. This improves test efficiency and establishes a complete and traceable record of damaged modules for the chip from the final test to the system-level test.

[0073] In one embodiment, the step of re-executing the target test case to independently verify each functional module marked as a second priority module to be verified, generating a third test result, and determining whether the functional module is a good module or a damaged module based on the third test result, further includes: Obtain all functional modules marked as second priority modules to be verified, and group them according to the status of the module in the second test result. Modules that are damaged in the second test result but intact in the first test result are assigned to the first dispute group, and modules that are intact in the second test result but damaged in the first test result are assigned to the second dispute group. Independent verification is performed on the functional modules in the first dispute group first. Each module is started in sequence according to the functional module number. Only one module is started at a time and put into working state, while the remaining functional modules are put into disabled state. Target test cases are executed on the separately started functional module to generate the third test results corresponding to each module in the first dispute group. The true state of each module is determined based on the third test results. After completing the verification of all modules in the first dispute group, the functional modules in the second dispute group are independently verified. The third test results for each module are generated according to the same serial independent test method. The true state of each module is determined based on the third test results. Modules in both groups that are confirmed to be damaged by the third test results are marked as damaged modules.

[0074] It should be noted that the first disputed group refers to the set of functional modules marked as second priority modules to be verified, whose second test result is corrupted but whose first test result is intact. These modules are judged as corrupted in the final testing phase but as intact in the system-level testing phase. The second disputed group refers to the set of functional modules marked as second priority modules to be verified, whose second test result is intact but whose first test result is corrupted. These modules are judged as intact in the final testing phase but as corrupted in the system-level testing phase. Independent verification refers to the testing process of individually starting and testing a single functional module using target test cases. During testing, only the module currently under test is in a working state, and all other functional modules are disabled.

[0075] Understandably, this embodiment divides the second priority modules to be verified into a first dispute group and a second dispute group according to the source of the dispute, and prioritizes the verification of modules in the first dispute group that may have been over-killed. Modules in the first dispute group are marked as damaged in the final testing stage, which means that the fuse bits corresponding to these modules have been blown, and the actual number of usable intact modules in the chip may be underestimated. Prioritizing the verification of these modules, once verified as intact, can promptly correct the over-kill error, allowing the chip to be salvaged from the brink of failing to meet the acceptance standards, thereby improving the chip yield.

[0076] Furthermore, this embodiment performs secondary verification of the disputed module through serial independent testing, eliminating the possibility of mutual interference between modules and ensuring the absolute accuracy of the third test result. This verification result, serving as the final judgment basis, effectively resolves the judgment conflict caused by differences in test coverage and testing environment at different testing stages. This ensures that the identification of damaged functional modules avoids misjudging intact modules as damaged, and vice versa, thereby maximizing the timeliness and success rate of chip recovery while guaranteeing verification accuracy.

[0077] In summary, this embodiment performs independent or group tests on each functional module in the target chip based on the target test cases, and stores the first test result corresponding to each functional module in a preset first fuse bit inside the chip, realizing a permanent record of the functional module's intact state during the system-level testing phase. Subsequently, the second test result, which is pre-stored in the second fuse bit and originates from the test records of each functional module of the same chip during the final testing phase, is obtained. Based on the first and second test results, an OR logic is used for comprehensive judgment, and a set of damaged functional modules is formed.

[0078] This embodiment records the test results of the functional modules during the system-level testing phase and the final testing phase using the first fuse bit and the second fuse bit respectively. Furthermore, when determining the set of damaged functional modules, it employs a comprehensive judgment method that ORs the two test results, ensuring that any damaged module detectable in any testing phase can be included in the set of damaged functional modules. This embodiment fully utilizes the complementarity of different testing phases in terms of test environment, test cases, and test coverage through the above steps, effectively compensating for the problem of missed detection of damaged modules that may occur due to insufficient test coverage in a single testing phase. This improves the accuracy of the judgment process and increases the chip yield.

[0079] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the chip functional module testing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0080] This application provides a chip functional module testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the chip functional module testing method in Embodiment 1 above.

[0081] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a chip functional module testing device suitable for implementing embodiments of this application. The chip functional module testing device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, tablets, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The chip functional module testing equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0082] like Figure 7As shown, the chip functional module testing equipment may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the chip functional module testing equipment. The processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the chip functional module test equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a chip functional module test equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0083] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0084] The chip functional module testing equipment provided in this application, employing the chip functional module testing method described in the above embodiments, can solve the technical problem of low chip yield. Compared with the prior art, the beneficial effects of the chip functional module testing equipment provided in this application are the same as those of the chip functional module testing method provided in the above embodiments, and other technical features of this chip functional module testing equipment are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0085] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0086] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0087] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the chip functional module testing method in the above embodiments.

[0088] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0089] The aforementioned computer-readable storage medium may be included in the chip functional module testing equipment; or it may exist independently and not be assembled into the chip functional module testing equipment.

[0090] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the chip functional module testing device, cause the chip functional module testing device to perform the aforementioned chip functional module testing method.

[0091] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0093] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0094] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described chip functional module testing method, thereby solving the technical problem of low chip yield. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the chip functional module testing method provided in the above embodiments, and will not be repeated here.

[0095] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the chip functional module testing method described above.

[0096] The computer program product provided in this application can solve the technical problem of low chip yield. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the chip functional module testing method provided in the above embodiments, and will not be repeated here.

[0097] All user-related data involved in this application was obtained with the user's permission or consent, as per [reference]. Figure 8 In other words, when this application is applied to a specific product or technology, user permission is required to acquire and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0098] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for testing chip functional modules, characterized in that, The method includes: When a chip's system-level test fails, determine whether the reason for the failure is related to the functional module of the target chip that failed the test. If relevant, the functional modules in the target chip are tested using preset target test cases to determine the set of damaged functional modules. The target test cases are used to sequentially and individually activate each functional module in the target chip, making the functional module work, while disabling the remaining functional modules. Disable the corresponding functional modules in the set of damaged functional modules, and determine whether the target chip still meets the preset qualification standards; If the conditions are met, the system-level test of the target chip is repeated to obtain the test results; The step of testing the functional modules in the target chip using preset target test cases to determine the set of damaged functional modules includes: Based on the target test cases, each of the functional modules in the target chip is tested to obtain a first test result corresponding to each functional module, and the first test result is stored in a preset first fuse bit; Obtain the second test result stored in the preset second fuse bit, wherein the second test result is the result of testing each functional module of the target chip in the final test of the test vector designed based on the test; Based on the first test results and the second test results, the set of damaged functional modules is determined; The step of determining the set of damaged functional modules based on the first test result and the second test result further includes: For each functional module, compare the state of the functional module in the first test result with the state of the functional module in the second test result. If both are intact, the functional module is marked as a first priority intact module. If there is a discrepancy between the two, the functional module is marked as a second priority module to be verified. If both are damaged, the functional module is marked as a damaged module and directly included in the set of damaged functional modules. For each functional module marked as a second priority module to be verified, the target test case is re-executed to independently verify it, a third test result is generated, and the functional module is determined to be a good module or a damaged module based on the third test result; The first damaged functional module, which is directly included in the damaged functional module set, is combined with the second damaged functional module determined according to the third test result to form a damaged functional module set. The identification information corresponding to all damaged modules in this set is written into the preset third fuse bit as the final damaged functional module record of the target chip.

2. The method as described in claim 1, characterized in that, The step of determining the set of damaged functional modules based on the first test result and the second test result includes: For each functional module in the target chip, determine the first test result and the second test result corresponding to the functional module; If the first test result is a test failure, or the second test result is a test failure, then the functional module is determined to be a damaged functional module; Based on each of the damaged functional modules, the set of damaged functional modules is determined.

3. The method as described in claim 1, characterized in that, The step of testing each functional module in the target chip based on the target test cases and obtaining the first test result corresponding to each functional module includes: Among all the functional modules of the target chip, a number of functional modules to be tested are identified. Based on the target test cases, the functional module to be tested is subjected to isolation scan testing to obtain preliminary test results; If the preliminary test result is that the test is passed, then the functional module to be tested is determined to be a complete functional module; From the functional modules other than the intact functional modules, determine the new functional module to be tested; Returning to the step of performing isolated scanning tests on the functional modules to be tested based on the target test case to obtain preliminary test results, until all the functional modules have been tested and the first test result is obtained.

4. The method as described in claim 3, characterized in that, After the step of performing isolation scan testing on the functional module to be tested based on the target test case to obtain preliminary test results, the method further includes: If the preliminary test result is that the test fails, it is determined that there is a damaged functional module in the functional module to be tested, and a new functional module to be tested is determined in the functional module to be tested. Returning to the step of performing isolated scanning tests on the functional modules to be tested based on the target test case to obtain preliminary test results, until all the functional modules have been tested and the first test result is obtained.

5. The method as described in claim 1, characterized in that, The step of determining whether the reason for the failure of the current test is related to the functional module of the target chip includes: Read the test log of the target chip for the current test; Based on the test logs, the test type for the current test is determined, wherein the test type includes functional module testing; If the test type is the functional module test, then the reason for the failure of the current test is determined to be related to the functional module of the target chip.

6. The method as described in claim 1, characterized in that, The step of disabling the corresponding functional modules in the set of damaged functional modules and determining whether the target chip still meets the preset qualification standards includes: Based on the set of damaged functional modules, determine the damaged functional modules that need to be disabled; Disable the damaged functional modules and determine the number of functional modules in the target chip that are not disabled; If the number of functional modules is not less than a preset threshold for the number of functional modules, then the target chip is determined to meet the qualification standard.

7. A chip functional module testing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the chip functional module testing method as described in any one of claims 1 to 6.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the chip functional module testing method as described in any one of claims 1 to 6.

9. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the chip functional module testing method as described in any one of claims 1 to 6.

Images