An in-chip self-repair method and system

Abstract

This application provides a chip-embedded self-repair method and system, relating to the field of chip self-repair technology. First, it performs full-chip initialization settings and a first power-on loading operation. Then, it sequentially performs a first memory test and a repair-needs determination test on each memory group. All memories under test on the chip are pre-divided into multiple memory groups, and the test for each memory group is performed through a corresponding group test vector. Next, when a repairable defect is determined in the chip, it performs full-chip capture and repair information, fuse writing, and fuse verification operations to permanently write the repair information into the fuses. Finally, it verifies whether the repair was successful. Here, between different test vectors or between different segments of the same test vector, the continuity between segment vectors is maintained through preset segmentation and reset options. The solution provided in this application has the advantages of ensuring high consistency between testing and simulation, high test location efficiency, and low risk of misjudgment.

Description

Technical Field

[0001] This application relates to the field of chip self-repair technology, and more specifically, to a chip built-in self-repair method and system. Background Technology

[0002] In the field of integrated circuit testing, the industry commonly employs built-in self-healing technology to address manufacturing defects in embedded memory. This technology combines fuse storage repair information with built-in memory self-testing processes for automatic diagnosis and repair. Siemens Tessent toolkit provides a standardized Repair Flow, which is widely used in mass production testing of SoC chips at advanced process nodes.

[0003] According to the Tessent manual, the standard Repair Flow comprises seven key steps, mapped to four independent test vectors: PowerUpEmulation Pattern, PreRepair Pattern, CheckRepairNeeded Pattern (repair judgment vector and repair information burned to efuse), and PostRepair Pattern (post-repair verification vector). Throughout the process, six test vectors are generated from the four vector specifications, and each vector is executed sequentially on the ATE (Automatic Test Equipment).

[0004] This method suffers from three major engineering bottlenecks: First, inconsistencies exist between actual testing and simulation verification scenarios, leading to a lack of simulation continuity. Key steps such as Pre-Repair and Post-Repair are forcibly separated, and the simulation environment cannot reproduce cross-vector state transition behavior. Consequently, test vectors cannot be fully simulated and verified before chip fabrication, resulting in uncertain reliability of vector quality. Second, unified testing across the entire chip, with all memory participating synchronously, makes it impossible for Shmoo debugging (voltage / frequency boundary scanning) to locate specific failed modules. Partial Good screening requires tracing massive amounts of logs and complex test program design, resulting in low efficiency and a high risk of misjudgment. Third, fuse programming requires powering the programming power supply VQPS. However, the independent vector file, in addition to the selffusebox program, also includes CaptureBira, making it impossible to quickly and accurately provide additional power only for the fuse programming step.

[0005] In summary, existing technologies suffer from problems such as a lack of continuity in the simulation process, low efficiency and susceptibility to misjudgment in testing and locating specific failed modules, and complex power supply issues in fuse burning. Summary of the Invention

[0006] The purpose of this application is to provide a chip-embedded self-repair method and system to solve the problems of lack of continuity in the simulation process, low efficiency and easy misjudgment in testing and locating specific failed modules, and complex power supply for burning fuses in the prior art.

[0007] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: On one hand, embodiments of this application provide a chip-embedded self-repair method, the chip-embedded self-repair method comprising: By using one or more shared test vectors, perform full-chip initialization setup and first power-on loading operations to load existing repair information from the chip's fuses; The first memory test and the determination test of whether repair is needed are performed sequentially for each memory group. All the memories under test on the chip are pre-divided into multiple memory groups, and the test of each memory group is performed through the corresponding group test vector. When a chip is determined to have a repairable defect, the chip performs full-chip capture repair information, fuse programming, and fuse verification operations through one or more shared test vectors to permanently write the repair information into the fuse. A second power-on loading operation is performed to load the written repair information, and a second memory test is performed on each memory group in sequence to verify whether the repair was successful. The second memory test for each memory group is performed through the corresponding group test vector. Specifically, the independence and continuity of test vectors are achieved through preset segmentation and reset options between different test vectors or between different segments of the same test vector.

[0008] Optionally, the segmentation and reset options include: The `network_end_state:reset` option is set to restore the IJTAG network's state control register to a reset state at the end of the test vector; and... Configure the `split_patterns_file` option; when this option is set to `on`, the complete repair process within the same vector specification is split into multiple independent test vector files according to the boundaries of each TestStep or ProcedureStep; when this option is set to `off`, each TestStep or ProcedureStep is merged and written into the same test vector file.

[0009] Optionally, a grouping strategy for pre-dividing all the memories under test on the chip into multiple memory groups includes: The chip is divided into multiple target modules by region; wherein the multiple target modules are arranged in an array; wherein each target module includes one or more memories to be tested.

[0010] Based on actual functions and screening requirements, each target module is classified into one of the following: core module, fault-tolerant module, and hybrid module. The core module is a module in which all components must be fully functional; the fault-tolerant module is a module in which all components are allowed to be partially damaged; and the hybrid module is a module that simultaneously contains a core component that must be fully functional and a fault-tolerant component that is allowed to be partially damaged. Target modules of the same type are grouped into the same set, and the target modules in the same set are further divided into multiple groups according to their staggered positions, so that any two target modules in the same group are not adjacent to each other in terms of physical location on the chip.

[0011] Optionally, the step of grouping target modules of the same type into the same set includes: All core modules and core sub-modules in all hybrid modules are divided into a first set; all fault-tolerant modules and fault-tolerant sub-modules in all hybrid modules are divided into a second set.

[0012] Optionally, after the step of dividing all fault-tolerant modules and fault-tolerant blocks in all hybrid modules into a second set, the method further includes: The second set is divided into multiple subsets according to their functions; each subset includes fault-tolerant modules that perform the same function and fault-tolerant blocks in the hybrid module.

[0013] Optionally, the steps of performing a first memory test and a determination test to determine whether repair is needed for each memory group sequentially include: When testing the first set, the corresponding group test vectors are executed sequentially according to the memory grouping, and the test results are directly compared within each group test vector; If any core module or core block fails the test, the chip is determined to be a faulty chip; if any fault-tolerant module or fault-tolerant block fails the test, the location information of the fault-tolerant module and fault-tolerant block that failed the test is determined.

[0014] Optionally, the shared test vector, the grouped test vector, and the simulation vector used for simulation verification are generated from the same vector specification.

[0015] Optionally, the initialization settings include chip reset, clock configuration, and parameter configuration for repair mode.

[0016] Optionally, the shared test vector includes one or more of the following: full chip initialization test vector, power-on loading test vector, capture and repair information test vector, fuse programming test vector, and fuse verification test vector.

[0017] On the other hand, embodiments of this application also provide a chip-embedded self-repair system, the system comprising: The preparation module is used to perform full-chip initialization setup and first power-on loading operations through one or more common test vectors to load existing repair information from the chip's fuses. The group test module is used to perform the first memory test and the determination test of whether repair is needed for each memory group in sequence. All the memories under test on the chip are pre-divided into multiple memory groups, and the test of each memory group is performed through the corresponding group test vector. The repair information solidification module is used to perform full-chip capture repair information, fuse writing, and fuse verification operations through one or more common test vectors when it is determined that there is a repairable defect in the chip, so as to permanently write the repair information into the fuse. Repair verification module: It is used to perform a second power-on loading operation to load the written repair information, and sequentially perform a second memory test on each memory group to verify whether the repair is successful. The second memory test of each memory group is performed through the corresponding group test vector. Specifically, the independence and continuity of test vectors are achieved through preset state segmentation and reset options between different test vectors or between different segments of the same test vector. Compared with the prior art, this application has the following beneficial effects: This application provides a chip-embedded self-healing method and system. First, using one or more shared test vectors, the entire chip undergoes initialization and a first power-on loading operation to load existing repair information from the chip's fuses. Then, each memory group is sequentially subjected to a first memory test and a repair-needed determination test. All memories under test on the chip are pre-divided into multiple memory groups, and the test for each memory group is executed through a corresponding group test vector. Next, when a repairable defect is determined in the chip, the entire chip is subjected to capture of repair information, fuse burning, and fuse verification operations using one or more shared test vectors to permanently write the repair information into the fuses. Finally, a second power-on loading operation is performed to load the written repair information, and a second memory test is sequentially performed on each memory group to verify the success of the repair. The second memory test for each memory group is executed through a corresponding group test vector. Between different test vectors or different segments of the same test vector, preset segmentation and reset options allow for flexible and independent test vector operation while maintaining functional continuity.

[0018] On the one hand, this application pre-divides the memory under test (MDT) on the chip into multiple groups and executes tests sequentially through the corresponding group test vectors. This allows for independent testing of each group, limiting the failure range to a single group without needing to separate it from aliased signals. Therefore, it achieves high positioning efficiency and reduces the likelihood of misjudgment. On the other hand, all test vectors are generated from the same vector specification. Pre-defined state segments and reset options between different test vectors or different segments of the same test vector enable flexible and independent testing while maintaining functional continuity. The test vectors generated in this way are highly consistent with the simulation vectors. The simulation environment can realistically reproduce the complete repair process, ensuring process continuity and enabling cross-vector state handover behavior, making end-to-end verification more reliable. Simultaneously, generating the fuse programming vectors according to independent vector files facilitates precise power supply (VQPS) during the testing phase.

[0019] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the standard repair process in existing technologies.

[0022] Figure 2 An exemplary flowchart of a chip-embedded self-healing method provided in an embodiment of this application.

[0023] Figure 3 A schematic diagram of the repair process provided for this application.

[0024] Figure 4 This is a schematic diagram of the first structure of the memory under test after being grouped, as provided in an embodiment of this application.

[0025] Figure 5 This is a schematic diagram of a second structure of the memory under test after being grouped, as provided in an embodiment of this application.

[0026] Figure 6 This is a schematic diagram of a third structure of the memory under test after being grouped, as provided in an embodiment of this application.

[0027] Figure 7This is a schematic diagram of the fourth structure of the memory under test after being grouped, as provided in an embodiment of this application. Detailed Implementation

[0028] 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, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0029] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0030] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0031] It should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0032] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0033] For chip memory repair, please refer to Figure 1 In existing technologies, standard repair flows generally include: 1. PowerUp Emulation: The built-in self-healing controller first calculates the length of the built-in self-healing chain, then decompresses the repair information from the fuse and loads the decompressed information into the built-in self-healing chain. It should be noted that this operation is mainly used to calculate the repair chain length and complete system initialization preparations. If the power-up emulation passes, proceed to the next step; if it fails, the entire process exits directly, and the chip is identified as a bad die.

[0034] 2. Pre-Repair: This is the first time the built-in memory self-test (MBIST) is performed. The test results determine if the chip is defective. MBIST is a built-in memory self-test circuit that automatically generates test vectors to perform read and write tests on the memory and reports the fault location, providing defect information for subsequent repair processes. Chips that fail the test indicate that their memory defects are beyond repair capabilities and are directly classified as defective. Chips that pass the test proceed to further steps for classification.

[0035] 3. Repair Necessity Check (CheckRepairNeeded): Chips that pass the pre-repair test can be divided into two categories: good chips without manufacturing defects and repairable faulty chips within the repair capability range. This step further distinguishes between chips that pass the pre-repair test and those without manufacturing defects or repairable faulty chips within the repair capability range. Chips confirmed to be defect-free are directly classified as good chips; chips confirmed to have repairable defects proceed to the next repair step.

[0036] 4. Repair Information Capture (CaptureBira): Transfers the repair information stored in the built-in repair analyzer register to the built-in self-repair register, completing the transfer of repair information from the analysis unit to the execution unit.

[0037] 5. SelfFuseBoxProgram: Obtain the repair information from the built-in self-healing chain, compress and encode it, and then write the compressed code into the fuse.

[0038] 6. Fuse Box Verification: Reads the contents programmed into the fuse, decompresses them, applies the decompressed repair information to the input of the built-in self-healing chain, and compares the input with the output of the built-in self-healing chain to verify whether the repair information programmed into the fuse is correct.

[0039] 7. Post-Repair: Before the second execution of the built-in memory self-test, a power-on loading operation is performed to load the repair information from the fuse into the corresponding location of the memory to be repaired. Then, the built-in memory self-test is executed a second time to verify whether the repaired chip can pass the test. If it passes, the chip is considered successfully repaired and considered a good chip.

[0040] It should be noted that if any step in the above process fails, the chip will be deemed defective. Furthermore, the "repair" mentioned above refers to the technical process of using reserved spare memory units within the chip to replace defective memory units through address remapping, thereby restoring the functionality of the manufacturing-defective memory. Specifically, extra memory units (spare rows or columns) are reserved in the memory during chip design. When a row or column of memory on the chip cannot be read or written normally due to manufacturing process issues, repair information is generated. This repair information represents data indicating "which defective address is mapped to which spare address," and this repair information must be stored in non-volatile memory (in this application, it is stored in a fuse) to ensure that the repair takes effect after each power-on, thus enabling a hardware mechanism that automatically redirects to the spare address when the CPU or other host devices access the defective address. As can be seen, in this application, "repair" refers to the entire process of discovering memory defects through MBIST testing, calculating replacement schemes by BIRA (Built-In Repair Analysis), burning the schemes into the fuse, loading and executing address remapping when the chip is powered on, and replacing the columns or rows of defective memory cells with reserved spare memory cell columns or rows inside the chip, so as to restore the memory to normal function.

[0041] In the above process, Tessent's officially recommended Repair Flow breaks down the complete repair process into four independent test vectors (patterns): PowerUpEmulation Pattern, PreRepair Pattern, CheckRepairNeeded Pattern, and PostRepair Pattern. Figure 1 (Vectors 1 through 4), each pattern is executed sequentially on the ATE. Both PreRepair and PostRepair must cover the BIST controllers associated with all the memories under test on the entire chip. Throughout the process, six test vectors are generated from the four vector specifications. Figure 1 (Independent vector files 1 to 6), and at the same time, the power-on loading process before the post-repair test reuses vector 1.

[0042] However, this approach presents three problems for large chips: First, the lack of continuity in the simulation process makes it impossible to verify the reliability of the test vectors. The final delivered Repair test vectors consist of six independent vector files generated from four independent patterns within one or more vector specifications. These patterns are the physical units that generate simulation or test vectors in the tessent flow, and they are independent of each other. After the vector testing in the chip testing phase, the chip's internal state remains unchanged without a hardware reset, allowing subsequent test vectors to continue testing based on the results of previous vectors. However, in the simulation phase, the simulation vectors of different patterns run independently, and they cannot inherit or continue the simulation results of previous vectors. This situation means that the continuity of the test vectors between different patterns in the self-repair process cannot be verified during the simulation phase. For example, the pre-repair test and repair necessity check are entity vectors generated from two vector names in the vector specification. The simulation software cannot transfer the test results of the pre-repair test step to the repair necessity check step. The second power-on load extracts repair information from the fuse box and completes the initialization operation. However, since the fuse box programming, power-on load, and post-repair test belong to three different entity vectors in different vector specifications, the values ​​in the fuse box cannot be used in the power-on load step during the simulation phase, and the repair results of the power-on load step cannot be carried over to the post-repair test step. Before the test vector is delivered, end-to-end functional verification of the complete Repair Flow cannot be performed. Only local simulation with each pattern as the test scope can be relied upon, which significantly increases the risk of ATE test failure.

[0043] Second, simultaneous operation of the entire chip's memory presents limitations in simulation feasibility and testing / debugging capabilities due to the massive amount of data.

[0044] In the field of very large-scale integrated circuit design, especially for system-on-a-chip (SoC) with hundreds of millions or even billions of logic gates, the logic scale contained in its register-transfer level or gate-level netlist is extremely large. Pre-repair testing and post-repair testing target all the memory on the chip. For large chips, the related logic volume is also enormous. Existing simulation tools, when handling such designs, are generally limited by the computing resources and memory capacity of the host CPU where the simulation engine resides, generally facing a significant degradation in simulation speed. In severe cases, the number of state combinations that need to be traced in the stimulus sequence grows exponentially, leading to simulator memory overflow or process crashes, thus preventing effective simulation iterations. Therefore, in the functional verification stage before chip tape-out, conventional simulation methods struggle to complete sufficient regression testing within an acceptable time window. Simultaneously, in timing simulation for timing approval, the large logic scale also makes it impossible to obtain timely and complete verification results. If verification is performed using module-level MBIST simulation vectors, there is a significant difference between this and the final delivered ATE test vectors based on the entire chip, leading to uncertainty in ATE testing.

[0045] While testing all memory modules in parallel can reduce testing time, it is inconvenient for shmoo debugging (voltage / frequency boundary scan) and partial good testing procedures. Specifically, when all BIST controllers are activated in parallel, power spikes, IR drop disturbances, and other effects overlap, making it impossible to separate the voltage / frequency margin of a single Hardened Block (hard core module) from the overall test results. This makes it impossible to locate the specific failed module during shmoo debugging. When PostRepair fails as a whole, it is necessary to backtrack through massive Fail Logs, parse TDO responses byte by byte to locate the physical block to which the failed memory cell belongs, and further determine whether it belongs to a degradeable module. The processing overhead at the ATE end is huge, and it is prone to misjudgment due to log truncation or timing misalignment.

[0046] Third, during the Self-FuseBoxProgram programming process in the self-healing workflow, a large programming current is required. efuse has a dedicated programming voltage input port, VQPS, which operates at 1.8V ± 5% to provide the necessary high current during programming. Existing solutions include a separate vector file for this step, containing not only the fuse box programming step but also CaptureBira (the repair information capture tool), making it difficult to quickly and accurately provide additional power solely for the fuse programming step.

[0047] In summary, existing technologies suffer from problems such as a lack of continuity in the simulation process, low efficiency and susceptibility to misjudgment in testing and locating specific failed modules, and complex power supply issues in fuse burning.

[0048] In view of this, in order to solve the above problems, this application provides a chip-embedded self-healing method. By grouping the memory under test and flexibly controlling the size of each group, the method solves the problems of low efficiency and easy misjudgment in locating specific faulty modules. By adopting a shared vector specification for testing and simulation, the method achieves continuity of the simulation process and verifies the consistency of test vector behavior, thereby improving the reliability of test vectors. By setting segmentation and reset options, the method enables test vectors to be presented as independent files as needed, thus solving the problem of complex power supply for fuse burning.

[0049] As one implementation method, please refer to Figure 2 The chip has built-in self-healing methods, including: S102 performs full-chip initialization setup and first power-on loading operations using one or more shared test vectors to load existing repair information from the chip's fuses.

[0050] S104, sequentially perform the first memory test and the determination test of whether repair is needed for each memory group. Here, all the memories to be tested on the chip are pre-divided into multiple memory groups, and the test of each memory group is performed through the corresponding group test vector.

[0051] S106 When it is determined that there is a repairable defect in the chip, the chip capture repair information, fuse writing and fuse verification operations are performed through one or more common test vectors to permanently write the repair information into the fuse.

[0052] S108, perform a second power-on loading operation to load the written repair information, and sequentially perform a second memory test on each memory group to verify whether the repair is successful. The second memory test of each memory group is performed through the corresponding group test vector. The independence and functional continuity of the test vectors are achieved through preset state segmentation and reset options between different test vectors or between different segments of the same test vector.

[0053] Please see Figure 3 The schematic diagram of the repair process provided in this application illustrates the timing relationship of the above steps. Specifically, the pre-repair stage, the check-repair-needed stage, and the post-repair stage all require grouping. For example, if all the memory within the chip is divided into N groups, then in each of these three stages, tests and checks are performed sequentially from group 1 to group N. These three stages are executed using corresponding group test vectors, namely, the pre-repair test group test vector, the check-repair-needed group test vector, and the post-repair test group test vector. The remaining stages are executed using shared test vectors.

[0054] It should be noted that this application defines the shared test vector as a set composed of one or more of the following five types of vectors: full chip initialization test vector, power-on loading test vector, capture repair information test vector, fuse programming test vector, and fuse verification test vector. The full chip initialization test vector is used to perform the complete set of operations for chip reset, clock configuration, and repair mode parameter configuration, which is a prerequisite for all subsequent repair steps. The power-on loading test vector is used to simulate the actual power-on process of the chip, triggering the automatic loading of existing repair information in the fuse to the corresponding repair controller, enabling the chip to restore its historical repair state without external intervention. The capture repair information test vector is used to transfer the repair information stored in the built-in repair analysis register to the built-in self-repair register, completing the transfer of repair information from the analysis unit to the execution unit. The fuse programming test vector is used to convert the captured repair information into a physical-level permanent fuse programming operation, ensuring that the repair results are retained after the chip is powered off. The fuse verification test vector is used to immediately read the fuse content after programming and compare it with the original repair data to confirm the accuracy of the programming information.

[0055] The five types of test vectors mentioned above are called "shared test vectors" because they are not bound to any specific memory group, but are uniformly invoked and globally effective across the entire chip. They can be used for initial loading before the first power-on load, as well as for state reset during the repair verification phase. This avoids repeatedly designing test vectors with overlapping functions for different stages, significantly reducing the total number of test vectors, lowering vector management complexity, and improving the robustness of the test process. Furthermore, using a separate test file for the fuse programming test vector greatly simplifies the test program's handling of additional power supply during fuse programming, allowing for quick and precise power supply only to the programming process.

[0056] In summary, this combination of initialization settings and shared test vectors is not simply a list of operational steps, but rather establishes a fundamental state anchoring system and a reusable test resource architecture that runs through the entire chip's built-in self-healing process. It constructs a test-driven mechanism with a unified entry point and state baseline for the entire chip's built-in self-healing process. This mechanism ensures that all repair-related operations across the entire chip are based on the same and controllable initial hardware state, thereby guaranteeing consistency of prerequisites and reproducibility of behavior among the stages of repair information loading, defect identification, fuse solidification, and repair verification.

[0057] The initialization settings described in this application can include three parts: chip reset, clock configuration, and repair mode parameter configuration. In practical applications, chip reset refers to sending a reset signal to the chip, forcing its internal registers, control logic, and memory units to return to predefined initial values. This eliminates interference from residual charge before power-on, historical test residual flags, or abnormal latch values ​​on subsequent repair processes, providing a clean and definite hardware starting point for the entire self-repair method. Clock configuration refers to precisely setting the frequency, phase, enable state, and division ratio of various clock sources within the chip according to the actual needs of the repair operation. For example, configuring a lower frequency for fuse programming operations to ensure programming reliability, and configuring a high-precision synchronous clock for high-speed memory testing to ensure data sampling accuracy, avoiding misreading of repair information, misjudgment of test results, or fuse programming failure due to clock deviation. Repair mode parameter configuration refers to loading specific operating parameters onto the chip's built-in repair controller, including but not limited to repair enable timing, fuse box control and selection, etc. These parameters collectively define the current repair strategy under which the chip operates, and are the fundamental basis for distinguishing between ordinary functional tests and repair-specific tests.

[0058] Understandably, this application restores the IJTAG network state control register to the reset state by pre-setting segmentation and reset options between different test vectors or between different segments of the same test vector, ensuring that the IJTAG network state is correct when different vectors are executed, thereby achieving flexible and independent test vectors while taking into account the continuity of functions.

[0059] As one implementation method, the segmentation and reset options include: Setting the `network_end_state:reset` option restores the IJTAG network's state control register to a reset state at the end of a vector execution. A reset IJTAG network state control register ensures correct execution of the next vector and maintains continuity between the preceding and following vectors. The `split_patterns_file` option determines whether to generate independent vector files for each TestStep or ProcedureStep within the same vector specification. When this option is set to `on`, the complete repair process within the same vector specification is split into multiple independent test vector files according to the boundaries of each TestStep or ProcedureStep. When this option is set to `off`, no independent vector files are generated, and each TestStep or ProcedureStep is merged and written into the same test vector file. The combination of `split_patterns_file:on` and `network_end_state:reset` restores the IJTAG network state control register within the vector to a reset state when splitting the test vector file according to specified boundaries. The state of the chip's internal non-IJTAG networks is retained without a reset. A reset IJTAG network state control register ensures that the next vector executes correctly and achieves continuous effects.

[0060] This application combines the above two options into a segmentation and reset option. In the test process upon which the chip's built-in self-healing method relies, when a test vector or a segment of that test vector is completed, the chip's IJTAG network is automatically reset. This ensures that subsequent test vectors are executed based on a clean and accurate IJTAG network, guaranteeing the correct execution of the test vector functions. Simultaneously, when an original test vector file is split into multiple independent test vector files according to preset boundaries due to engineering needs, this application ensures that the split test vector files can still accurately identify and continue the state information saved in the previous file while correctly executing the functions of each test vector. This guarantees the state continuity between different test vectors or between different segments of the same test vector, enabling the entire repair process to have cross-file and cross-stage state traceability and behavioral consistency.

[0061] Specifically, the entire chip's memory under test is divided into N memory groups. The division principle can be determined based on the actual chip situation, considering factors such as power supply voltage drop (IR drop), functional module affiliation, and physical location information. For example, for a memory group GroupX, each operation step in the repair process is defined as a ProcedureStep and a TestStep under the corresponding group's test vector for GroupX, and both options are set in each step. Then, the three stages of pre-repair, determination of whether repair is needed, and post-repair verification for all memory groups are organized into a test sequence executable by an automated test device according to the full chip repair process.

[0062] It should be noted that the five steps of full chip initialization setup, first power-on loading operation, capturing repair information, fuse programming, and fuse verification are all shared test vectors in each memory group. Therefore, delivery can be completed by extracting the test vectors generated by any memory group. However, the three steps of pre-repair, determination of whether repair is needed, and post-repair verification will bring together the group test vectors corresponding to each memory group for unified delivery.

[0063] The ability to save and transfer state information between different test vectors or between different segments of the same test vector is achieved through the aforementioned two configuration options. Whenever the `split_patterns_file:on` option and `network_end_state:reset` are enabled, the system automatically splits a complete test vector into multiple test vector files according to predefined position boundaries. Each split file resets the IJTAG network state, ensuring the normal execution of each test vector and maintaining continuity throughout the repair process after splitting.

[0064] In summary, this application achieves flexible and independent test vectors while maintaining functional continuity by pre-setting segmentation and reset options between different test vectors or different segments of the same test vector. Specifically, this application divides all the memory under test in the entire chip into multiple memory groups and configures corresponding group test vectors for each memory group. Each group test vector defines the various operation steps required for the repair process, including pre-repair, determination of whether repair is needed, and post-repair verification. Segmentation and reset options are embedded in each operation step, so that the IJTAG network state is in a reset state when the chip executes different test vectors or different segments of the same test vector, ensuring the correct execution of subsequent test vector functions. This ensures that the entire chain of the chip's built-in self-repair method, from initialization settings, first power-on loading, group testing, repair information solidification to second power-on loading and repair verification, has logical coherence and execution traceability.

[0065] As one implementation method, a grouping strategy that pre-divides all the memories under test on the chip into multiple memory groups includes: The chip is divided into multiple target modules by region; the multiple target modules are arranged in an array; each target module includes one or more memories under test.

[0066] Based on actual functions and screening requirements, each target module is classified into one of the following: core module, fault-tolerant module, or hybrid module. A core module is a module in which all components must be fully functional; a fault-tolerant module is a module in which all components are allowed to be partially damaged; and a hybrid module is a module that contains both a core component that must be fully functional and a fault-tolerant component that is allowed to be partially damaged. Target modules of the same type are grouped into the same set, and the target modules in the same set are further divided into multiple groups according to their staggered positions, so that any two target modules in the same group are not adjacent to each other in terms of physical location on the chip.

[0067] It should be noted that the modules within an actual chip are irregular, and each module is also irregular. Since the overall layout of the chip is mostly a rectangular matrix, the overall outline is a rectangular matrix. Based on this, the array arrangement described in this application can be an approximate matrix rather than a standard X-row, Y-column matrix. For example, the first X-1 rows may all include Y-column modules, while the last row may only include Y-1 columns of modules, meaning the last module is missing. In this application, this method is still defined as an array arrangement.

[0068] When classifying modules, they are divided into three categories: core modules, fault-tolerant modules, and hybrid modules. Core modules are those that must be fully functional (Full Good). If a core module fails during testing, the chip is considered defective. Fault-tolerant modules are those where partial failure is permissible (Partial Good). If a partial failure occurs, the testers record the details for later chip classification and screening, noting which fault-tolerant modules failed. In subsequent use, these failed fault-tolerant modules are skipped, achieving a degraded performance. For example, if all 10 fault-tolerant modules pass testing, the chip is classified as a top-tier chip. If 8 fault-tolerant modules pass testing, but 2 fail, the chip is classified as a lower-tier chip, and these two fault-tolerant modules must be skipped during use. The hybrid module is a module that simultaneously contains a core module that must be fully functional and a fault-tolerant module that allows for partial failure. During testing, if the hybrid module fails, it is necessary to determine whether the failure is caused by the core module or the fault-tolerant module. If the failure is caused by the core module, the chip is considered defective; if the failure is caused by the fault-tolerant module, the test results are recorded, and the module is downgraded and skipped in subsequent use.

[0069] The steps for grouping target modules of the same type into the same set include: All core modules and core blocks in all hybrid modules are divided into a first set; all fault-tolerant blocks in all hybrid modules are divided into a second set.

[0070] Since both core modules and core blocks require full testing to pass, otherwise the chip will be considered defective, while fault-tolerant modules and blocks only need to be recorded if they fail, and can be categorized and screened later, this application divides all core modules and core blocks in all hybrid modules into a first set as the first type of test object to improve testing efficiency. Simultaneously, all fault-tolerant blocks in all hybrid modules are divided into a second set as the second type of test object. Furthermore, when testing the first and second types of test objects separately, they must be performed with alternating rows.

[0071] Furthermore, after the step of dividing all fault-tolerant modules and fault-tolerant blocks in all hybrid modules into a second set, the method further includes: The second set is divided into multiple subsets according to their functions; each subset includes fault-tolerant modules that perform the same function and fault-tolerant blocks in the hybrid modules.

[0072] In order to achieve more accurate testing, the modules that support PartialGood are further subdivided by function according to the screening strategy. For example, the two functions CORE and DDR (there are many actual functional categories, depending on the complexity of the screening strategy) can be divided into two subsets, so that different functional modules can be independently grouped into a group object.

[0073] In addition, the steps of performing a first memory test and a determination test to determine whether repair is needed for each memory group in sequence include: When testing the first set, the corresponding group test vectors are executed sequentially according to the memory grouping, and the test results are directly compared within each group test vector; If any core module or core block fails the test, the chip is determined to be a faulty chip; if any fault-tolerant module or fault-tolerant block fails the test, the location information of the fault-tolerant module and fault-tolerant block that failed the test is determined.

[0074] The grouping strategy provided in this application is described in detail below: This application is based on each target module, ensuring that any two target modules within the same memory group are not adjacent to each other in terms of chip physical location. This effectively disperses the test power consumption distribution of each target module on the chip surface when executing the group test vector corresponding to the memory group, suppresses the power supply voltage drop caused by instantaneous current concentration, and ensures power supply stability and signal integrity during the test.

[0075] It should be noted that the target module described in this application refers to a circuit block on a chip with a certain independent function, which usually corresponds to a hardened functional module in the chip design. Some of these modules are reusable, while others are dedicated, and their shapes are irregular, but the overall layout is an approximate rectangular matrix.

[0076] In the field of semiconductor engineering, a target module, also known as a hardened block, refers to a functional unit that has been physically verified and can be instantiated and reused multiple times on a chip. Each target module contains a complete circuit structure, which inevitably includes several memories that need to be tested and repaired. Typical examples of target modules include: cache units in a processor core, coefficient memory arrays in a digital signal processing engine, texture caches in a graphics processing unit, and queue memories in a communication protocol engine.

[0077] Understandably, a target module contains multiple memories under test, and the two have a relationship of inclusion. Specifically, each target module contains one or more sets of memories under test, which are the smallest units for actually storing data. For example, a target module may contain 5 memories. Of course, the number of memories contained in each target module may be the same or different.

[0078] Taking an example where each target module includes 5 memory units, if the total number of target modules is 100 and they are divided into 4 groups, then the first group includes 25 target modules, which means the first group contains 25 * 5 = 125 memory units, forming the first memory group. Similarly, the other three memory groups also each include 125 memory units. Of course, in practical applications, the target modules may be more complex. For example, the first target module may include 2 memory units, the second target module may include 7 memory units, the third target module may include 5 memory units, and so on. This application does not limit this.

[0079] As one implementation method, multiple target modules on the chip are arranged in an array, that is, multiple target modules are arranged in rows and columns, i.e., the array arrangement described above. Furthermore, due to the complexity of the actual working conditions of the chip, the array arrangement described in this application is all in approximate matrix form.

[0080] Meanwhile, each target module contains three possible scenarios: the first is that the entire module must be fully functional; the second is that the module is divided into core blocks that must be fully functional and mixed blocks that allow partial damage; and the third is that the entire module is a fault-tolerant module that allows partial damage. Based on this, differentiated testing processes and result judgment mechanisms are implemented for blocks of different natures, so that the chip's built-in self-healing method can not only ensure the absolute reliability of key functional areas, but also flexibly support advanced yield management strategies such as partial qualified screening.

[0081] The grouping strategy of this application includes the following steps: The first step is to classify the modules into three types based on their functions and screening strategies: FullGood, PartialGood, and FullGood+PartialGood (i.e., core modules, fault-tolerant modules, and hybrid modules).

[0082] The second step is to divide the core modules and core sub-modules in the core modules and hybrid modules into a first set, and divide the fault-tolerant modules and fault-tolerant sub-modules in the fault-tolerant modules into a second set.

[0083] The third step is to further divide the target modules in the second set into multiple subsets according to their functions.

[0084] The fourth step is to reduce power consumption by staggering peak loads. The first set and each subset are divided into multiple groups using an alternating row and column (non-adjacent) arrangement. This ensures that target modules within the same memory group are not physically adjacent to each other on the chip, significantly reducing the instantaneous power consumption peaks in localized areas during testing, mitigating power supply voltage drops, and improving the stability of test results.

[0085] The fifth step is to test each group of modules in turn. For example... Figures 4-7 This represents the grouping of a set or subset, for example, the grouping of core modules. Each BLK represents a target module, and its suffix indicates location information (i.e., coordinate information). For example, BLK_x1y1 indicates the target module with coordinates x1y1. For clarity, the coordinate information in the first line is x1y1~x8y1, and the coordinate information in the last line is x1y10~x8y10.

[0086] Based on this, such as Figure 4 As shown, BLK_x1y1, BLK_x3y1, BLK_x5y1, and BLK_x7y1 are assigned to the first memory group. For any two target modules, they are not physically adjacent to each other on the chip. For example, BLK_x1y1 and BLK_x3y1 are separated by BLK_x2y1; BLK_x1y1 and BLK_x5y1 are separated by BLK_x2y1 to BLK_x4y1, and so on. Similarly, in the column direction, any two target modules are not adjacent. For example, BLK_x1y1 in the first column is separated from the nearest target module by one target module; they are not adjacent. Figures 5-7 In the second memory group shown, no two target modules are adjacent to each other.

[0087] Based on this, one implementation method is to divide multiple target modules on the chip into multiple groups according to their staggered positions: Multiple target modules are divided into multiple arrays of n*m target units, where n and m are both integers greater than 1. Target modules at the same position in each target unit are grouped into the same group. By selecting target units by array, at least one target module is separated from any two target modules in any memory group, thus ensuring that any two target modules in the same memory group are not adjacent to each other in terms of chip physical location.

[0088] For example, when n equals 2 and m equals 2, the grouping method based on each target unit can be: Select the target modules located in the upper left corner of each target unit into the same group as the first group; select the target modules located in the upper right corner of each target unit into the same group as the second group; select the target modules located in the lower left corner of each target unit into the same group as the third group; and select the target modules located in the lower right corner of each target unit into the same group as the fourth group.

[0089] Understandably, when n equals 2 and m equals 2, there is a gap of one target module between each two adjacent target modules in each memory group; if n and m are larger, then in each memory group, the two adjacent target modules form a chessboard array that is not selected when they are selected.

[0090] Furthermore, the above example assumes that all target modules within the same set are adjacent. In practice, however, many other scenarios may exist, leading to variations in the number of groups required. For instance, if the first set contains multiple core modules, but no two core modules are adjacent, only one group is needed when dividing the storage subgroups. If multiple core modules are adjacent only in the row direction and not in the column direction, then two groups are required in each case; this is not a limitation.

[0091] After dividing the memory into groups and generating corresponding test vectors for each group, the script automatically extracts the test pass identifier for each fault-tolerant module. This identifier specifically includes the position of a particular test vector cycle on the output pin, representing the end and pass of the test. The automated test equipment compares the actual test results with this identifier to identify which specific fault-tolerant module has failed the test, thereby determining the location of repairable defects or the fault information required for partial pass / fail assessment.

[0092] from Figures 4-7As shown in the grouping effect diagram, this scheme maximizes the number of modules under test in a single test, reduces the overall test time cost, and effectively balances the control of local power consumption and power supply voltage drop, expanding the reliable operating range of parameter scan testing. In the grouping simulation verification phase, only the currently selected target module needs to use a real circuit netlist, while other unselected target modules use interface models or gray-box models, thus significantly reducing the amount of data required for simulation verification and improving verification feasibility.

[0093] Furthermore, as an implementation method, the shared test vectors, grouped test vectors, and simulation vectors used for simulation verification are generated from the same vector specification. The simulation vectors are used to verify the logical correctness of the chip's built-in self-healing process in the simulation environment, and the simulation vectors have the same repair process description as the shared test vectors and grouped test vectors.

[0094] In this application, the Tessent tool, based on the same vector specification, can generate test vectors (including shared and grouped test vectors) for execution by automated test equipment, as well as simulation vectors for execution by a simulator. Since both originate from the same vector specification, the described repair process steps, operation sequence, state transition conditions, and judgment criteria are logically identical; the only difference lies in the output format and application environment. Therefore, a repair process verified through simulation vectors will not exhibit logical deviations when executing the corresponding test vectors on automated test equipment, thus ensuring behavioral consistency between simulation verification and actual ATE testing.

[0095] Understandably, this application splits the built-in self-test controllers of all memory devices under test (DUTs) on the entire chip into memory groups, giving each memory group an independent and complete group test vector, thereby achieving grouped and structured management of the chip's internal test and repair status. Based on this, the method provided in this application has at least the following beneficial effects: First, the test vectors can be fully verified through simulation. The repair process for each memory group exists within a complete test vector, and the resulting Verilog-formatted test vectors naturally preserve the state continuity between steps, allowing for simulation verification of the correctness of the memory group's repair configuration. This approach offers superior state continuity between steps compared to the Tessent tool manual's recommendation of generating all test content using four independent test vectors. Furthermore, by splitting the process by memory group, the logic scale of a single simulation is significantly reduced, substantially improving the feasibility of simulation verification for large-scale integrated circuit chips.

[0096] Second, the debugging capabilities of automated test equipment have been significantly improved. During the testing phase of automated test equipment, the built-in self-test of memory requires frequent performance optimization work, including parameter scan test limit calibration of each hardened functional module, as well as partial pass / fail screening tests necessary for large-scale chips. These requirements are based on the significant debugging advantages of test vectors generated by memory grouping: First, the design approval standards for different hardened functional modules may not be consistent. Debugging separately by memory group can accurately locate the specific test objects affecting the parameter scan test results, facilitating targeted analysis. Second, partial pass / fail screening is a crucial yield improvement technology in large-scale chip manufacturing, which can significantly reduce the scrap rate. Among these, partial pass / fail judgment related to memory is particularly critical.

[0097] After generating built-in self-test vectors for memory groups, partial pass / fail classification can be intuitively performed based on the test results of each memory group. For example, if a memory group GroupX meets the partial pass / fail criteria, and the post-repair verification test for that memory group fails, the system can directly retain the chip in the partial pass / fail queue for classification. However, if a single set of test vectors is generated for all memories on the entire chip, once the post-repair verification fails, it is necessary to rely on a large amount of failure logs for detailed analysis. It would require manual or complex programming to identify all possible error locations, determine which specific memory is faulty, and further determine whether the memory meets the partial pass / fail screening criteria. The amount of data to be processed is extremely large, and the program executed on the automated test equipment is also extremely complex.

[0098] Third, programming fuses requires power to the programming power supply VQPS. However, the vector splitting scheme recommended by tessent includes CaptureBira in addition to the selffusebox program, which cannot quickly and accurately provide additional power to the programming fuse step alone.

[0099] Fourth, the test vector delivery is highly consistent with the simulation. A single test vector set can generate all the vectors required for actual testing by the automated test equipment. The test vector specifications delivered to the automated test equipment are highly consistent with the test vector specifications used for simulation, thereby ensuring that the test vectors have been fully verified before being put into actual testing by the automated test equipment, thus improving test reliability.

[0100] In summary, dividing all memory under test into multiple memory groups has several beneficial effects, and the division principle is flexible and adjustable: on the one hand, the data size of each memory group is significantly reduced after the division, which greatly facilitates the simulation verification work; on the other hand, each memory group after the division can quickly support the debugging of key performance indicators of automatic testing equipment such as parameter scanning test; in addition, this division method provides a practical operational basis and execution convenience for advanced screening technologies such as partial qualification screening.

[0101] It should be noted that the above embodiments are all based on a single repair process to illustrate the technical solution of this application. However, the scope of protection of this application is not limited thereto. The Tessent tool also supports incremental repair mode, which can perform multiple repairs on the chip. In incremental repair mode, the execution method of each single repair is exactly the same as the single repair process described in the foregoing embodiments. Therefore, the grouped test vector generation method, segmentation and reset option setting method, and grouping strategy described in this application are also applicable to each repair operation in incremental repair mode.

[0102] Furthermore, the embodiments described above in this application are based on a basic repair process. In practical engineering applications, the basic repair process also has various extended forms. For example, a dual-fuse scheme can be used for repair data writing, that is, the fuse writing operation and the fuse verification operation are performed twice, or two fuses are written simultaneously in a single execution. Even further, repair schemes with more than two fuses can be used. In these extended repair processes, the core built-in memory self-test section is completely consistent with the basic repair process.

[0103] It is understandable that the repair scheme combining the dual-fuse solution and the incremental repair mode can also employ the technical solution described in this application for its underlying memory-built-in self-test section. That is, regardless of whether the repair process uses single-step repair or incremental repair, and regardless of whether the fuse writing uses a single-fuse, dual-fuse, or multi-fuse solution, as long as its memory-built-in self-test section employs the group testing, state saving, and other technical means described in this application, it is included within the protection scope of this application.

[0104] The above alternatives are merely a few specific examples of this application. Other alternatives that can be easily conceived by those skilled in the art based on the above disclosure, such as applying the method described in this application to other similar built-in self-testing tools, or combining the grouping strategy of this application with other state saving mechanisms, should all constitute part of the protection scope of this application.

[0105] Based on the above implementation, this application also provides a chip-embedded self-repair system, which includes: The preparation module is used to perform full-chip initialization setup and first power-on loading operations using one or more common test vectors to load existing repair information from the chip's fuses.

[0106] The group test module is used to perform the first memory test and the determination test of whether repair is needed for each memory group in sequence. All the memories under test on the chip are pre-divided into multiple memory groups, and the test of each memory group is performed through the corresponding group test vector.

[0107] The repair information solidification module is used to permanently write the repair information into the fuse when a chip is determined to have a repairable defect. This is done by using one or more common test vectors to capture repair information, write fuses, and verify fuses across the entire chip.

[0108] Repair verification module: Used to perform a second power-on loading operation to load the written repair information, and sequentially perform a second memory test on each memory group to verify whether the repair is successful. The second memory test of each memory group is performed through the corresponding group test vector. The continuity between segment vectors is maintained through preset segmentation and reset options between different test vectors or between different segments of the same test vector.

[0109] In summary, this application provides a chip-embedded self-healing method and system. First, using one or more shared test vectors, the entire chip undergoes initialization and a first power-on loading operation to load existing repair information from the chip's fuses. Then, each memory group is sequentially subjected to a first memory test and a repair-needed determination test. All memories under test on the chip are pre-divided into multiple memory groups, and the test for each memory group is executed through a corresponding group test vector. Next, when a repairable defect is determined in the chip, the entire chip is subjected to capture of repair information, fuse burning, and fuse verification operations using one or more shared test vectors to permanently write the repair information into the fuses. Finally, a second power-on loading operation is performed to load the written repair information, and a second memory test is sequentially performed on each memory group to verify the success of the repair. The second memory test for each memory group is executed through a corresponding group test vector. Between different test vectors or between different segments of the same test vector, the continuity between segment vectors is maintained through preset segmentation and reset options. On the one hand, this application pre-divides the memory under test (MDT) on the chip into multiple groups and sequentially executes tests through the corresponding group test vectors. This allows for independent testing of each group, limiting the failure range to a single group without needing to separate it from aliased signals. Therefore, it achieves high positioning efficiency and reduces the likelihood of misjudgment. On the other hand, preset segment and network state reset options ensure that cross-vector or cross-segment states do not interfere with each other, allowing the entire repair process to be executed effectively and correctly. Simultaneously, the simulation environment can realistically reproduce the complete repair process, guaranteeing the reliability of the test vectors.

[0110] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0111] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A chip-embedded self-repair method, characterized in that, The chip's built-in self-healing method includes: By using one or more shared test vectors, perform full-chip initialization setup and first power-on loading operations to load existing repair information from the chip's fuses; The first memory test and the determination test of whether repair is needed are performed sequentially for each memory group. All the memories under test on the chip are pre-divided into multiple memory groups, and the test of each memory group is performed through the corresponding group test vector. When a chip is determined to have a repairable defect, the chip performs full-chip capture repair information, fuse programming, and fuse verification operations through one or more shared test vectors to permanently write the repair information into the fuse. A second power-on loading operation is performed to load the written repair information, and a second memory test is performed on each memory group in sequence to verify whether the repair was successful. The second memory test for each memory group is performed through the corresponding group test vector. Specifically, between different test vectors or between different segments of the same test vector, the independence of test vectors and the continuity of functions are achieved through preset segmentation and reset options.

2. The chip-embedded self-repair method according to claim 1, characterized in that, The segmentation and reset options include: The `network_end_state:reset` option is set to restore the IJTAG network's state control register to a reset state at the end of the test vector; and... Configure the `split_patterns_file` option; when this option is set to `on`, the complete repair process within the same vector specification is split into multiple independent test vector files according to the boundaries of each TestStep or ProcedureStep; when this option is set to `off`, each TestStep or ProcedureStep is merged and written into the same test vector file.

3. The chip-embedded self-repair method according to claim 1, characterized in that, Grouping strategies that pre-divide all on-chip memories into multiple memory groups include: The chip is divided into multiple target modules by region; wherein the multiple target modules are arranged in an array; wherein each target module includes one or more memories under test; Based on actual functions and screening requirements, each target module is classified into one of the following: core module, fault-tolerant module, and hybrid module. The core module is a module in which all components must be fully functional; the fault-tolerant module is a module in which all components are allowed to be partially damaged; and the hybrid module is a module that simultaneously contains a core component that must be fully functional and a fault-tolerant component that is allowed to be partially damaged. Target modules of the same type are grouped into the same set, and the target modules in the same set are further divided into multiple groups according to their staggered positions, so that any two target modules in the same group are not adjacent to each other in terms of physical location on the chip.

4. The chip-embedded self-repair method according to claim 3, characterized in that, The steps to group target modules of the same type into the same set include: All core modules and core sub-modules in all hybrid modules are divided into a first set; all fault-tolerant modules and fault-tolerant sub-modules in all hybrid modules are divided into a second set.

5. The chip-embedded self-repair method according to claim 4, characterized in that, After the step of dividing all fault-tolerant modules and fault-tolerant blocks in all hybrid modules into a second set, the method further includes: The second set is divided into multiple subsets according to their functions; each subset includes fault-tolerant modules that perform the same function and fault-tolerant blocks in the hybrid module.

6. The chip-embedded self-repair method according to claim 4, characterized in that, The steps of performing the first memory test and the determination test for whether repair is needed for each memory group in sequence include: When testing the first set, the corresponding group test vectors are executed sequentially according to the memory grouping, and the test results are directly compared within each group test vector; If any core module or core block fails the test, the chip is determined to be a faulty chip; if any fault-tolerant module or fault-tolerant block fails the test, the location information of the fault-tolerant module and fault-tolerant block that failed the test is determined.

7. The chip-embedded self-repair method according to claim 1, characterized in that, The shared test vector, the grouped test vector, and the simulation vector used for simulation verification are generated from the same vector specification.

8. The chip-embedded self-repair method according to claim 1, characterized in that, The initialization settings include chip reset, clock configuration, and parameter configuration for repair mode.

9. The chip-embedded self-repair method according to any one of claims 1 to 8, characterized in that, The shared test vectors include one or more of the following: full chip initialization test vector, power-on loading test vector, capture and repair information test vector, fuse programming test vector, and fuse verification test vector.

10. A chip-embedded self-repair system, characterized in that, The system includes: The preparation module is used to perform full-chip initialization setup and first power-on loading operations through one or more common test vectors to load existing repair information from the chip's fuses. The group test module is used to perform the first memory test and the determination test of whether repair is needed for each memory group in sequence. All the memories under test on the chip are pre-divided into multiple memory groups, and the test of each memory group is performed through the corresponding group test vector. The repair information solidification module is used to perform full-chip capture repair information, fuse writing, and fuse verification operations through one or more common test vectors when it is determined that there is a repairable defect in the chip, so as to permanently write the repair information into the fuse. Repair verification module: It is used to perform a second power-on loading operation to load the written repair information, and to perform a second memory test on each memory group in turn to verify whether the repair is successful. The second memory test of each memory group is performed through the corresponding group test vector. Specifically, between different test vectors or between different segments of the same test vector, the independence of test vectors and the continuity of functions are achieved through preset state segments and reset options.

Images