Repair test evaluation method and device for system-on-chip and electronic equipment

Abstract

The invention discloses a system-on-chip repair test evaluation method and device and electronic equipment, and relates to the technical field of computers.The method comprises the steps that a target subsystem which does not execute a repair test is screened out from a plurality of subsystems included in a system-on-chip according to the function of a current to-be-operated test case; under the condition that a target subsystem which does not execute the repair test exists in the multiple subsystems, first identification information corresponding to the target subsystem is obtained; according to the first identification information, first memory repair indication information corresponding to the target subsystem is adjusted, and the first memory repair indication information is used for the memory repair controller not to execute a repair test on the target subsystem in the memory repair process subsequently according to the first memory repair indication information. According to the method and the device, the target subsystems which do not execute the repair test are screened out, so that unnecessary memory repair test on the target subsystems is avoided, the time for testing the system-on-chip is shortened, and the verification efficiency of the system-on-chip is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, and electronic device for repairing, testing, and evaluating a system-on-chip. Background Art

[0002] In the post-simulation process of functional testing a system-on-chip (SoC) using case tests, the SoC first needs to be subjected to a memory repair test. Only after the chip's memory repair is completed can the test case be executed to test the SoC's functionality. This effectively improves the accuracy and reliability of the SoC's functional testing. By completing a limited memory repair test before executing the test case, potential defects in the SoC's memory can be discovered in advance, preventing memory failures from interfering with the results of the functional test, thereby truly reflecting the functional characteristics of the SoC through the test case. However, including the memory repair process in the process of testing the functionality of the SoC using test cases will result in excessively long test times and low SoC verification efficiency. Therefore, it is particularly important to shorten the SoC's repair test duration and improve functional verification efficiency. Summary of the Invention

[0003] The present application provides a method, device and electronic device for repair test evaluation of a system-on-chip, so as to at least solve the problem that the memory repair test time is long when the system-on-chip is functionally tested using test cases.

[0004] This application provides a system-on-chip repair test and evaluation method, including:

[0005] According to the function of the test case currently to be run, a target subsystem that does not perform the repair test is screened out from the multiple subsystems included in the system-level chip; in the case that there is a target subsystem that does not perform the repair test among the multiple subsystems, first identification information corresponding to the target subsystem is obtained; according to the first identification information, first memory repair indication information corresponding to the target subsystem is adjusted, and the first memory repair indication information is used by the memory repair controller to subsequently not perform the repair test on the target subsystem during the memory repair process according to the first memory repair indication information.

[0006] The present application also provides a system-on-chip repair test and evaluation device, comprising:

[0007] A screening module is used to screen out target subsystems that are not to be tested for repair from multiple subsystems included in the system-on-chip according to the functions of the test case currently to be run;

[0008] An acquisition module, configured to acquire first identification information corresponding to a target subsystem when there is a target subsystem that does not perform a repair test among the multiple subsystems;

[0009] An adjustment module is used to adjust first memory repair indication information corresponding to a target subsystem according to first identification information, wherein the first memory repair indication information is used by a memory repair controller to not perform a repair test on the target subsystem during a memory repair process according to the first memory repair indication information.

[0010] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned system-on-chip repair test and evaluation methods when executing the computer program.

[0011] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned system-on-chip repair test and evaluation methods are implemented.

[0012] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned system-on-chip repair test and evaluation methods when executed by a processor.

[0013] Through this application, test cases with different functions often focus on testing the subsystems corresponding to the function in the system-level chip. For example, for image recognition test cases, the focus is on the subsystem in the system-level chip used to implement the image recognition function, but not on the subsystem used to implement functions such as voice recognition. Therefore, in the repair test process of a certain test case, the target subsystem that needs to be repaired can be accurately located based on the function of the test case, and then the first memory indication information of the target subsystem can be adjusted based on the first identification information (such as interface information) of the target subsystem, so that the memory repair controller does not perform a repair test on the target subsystem based on the first memory repair indication information. In other words, in the memory repair process corresponding to this application, repair tests are not performed on all subsystems in the system-level chip, but on the target subsystem determined based on the test case function. In this way, unnecessary repair tests are effectively avoided on subsystems that are not related to the function of the current test case, the repair test operations of the memory repair controller are reduced, the test cycle of the system-level chip is shortened, and the test efficiency is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0015] Figure 1 A flowchart of a system-on-chip repair test and evaluation method provided in an embodiment of the present application;

[0016] Figure 2 A flowchart of another system-on-chip repair test and evaluation method provided in an embodiment of the present application;

[0017] Figure 3 A schematic diagram of performing repair testing on memories of multiple subsystems in a system-on-chip provided in an embodiment of the present application;

[0018] Figure 4 A schematic diagram of performing repair testing on memories of multiple subsystems in another system-on-chip provided in an embodiment of the present application;

[0019] Figure 5 A schematic structural diagram of a system-on-chip repair test and evaluation device provided in an embodiment of the present application;

[0020] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0021] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0022] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0023] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0024] First, the application scenarios of the embodiments of the present application are exemplarily introduced.

[0025] Post-simulation is an essential step in the system-on-chip (SoC) development process, crucial for rapid product market launch. Post-simulation, based on the SoC's netlist, verifies whether the SoC's circuits meet timing requirements during actual operation. Post-simulation effectively identifies and corrects potential issues, such as timing violations, ensuring the SoC's stability and reliability in a variety of complex operating scenarios and significantly reducing the risk of tapeout failure.

[0026] As system-on-chip (SoC) design complexity and memory capacity increase, the proportion of embedded memory within the SoC area has increased dramatically, with some data suggesting it can reach up to 90%. This high-density integration significantly increases memory failure rates, severely reducing SoC manufacturing yields. To improve SoC manufacturing yield and reliability, memory repair technology has emerged and is widely used. The development of this technology is crucial to addressing the high failure rate of memory in SoCs, improving product production yields while enhancing product reliability and market competitiveness.

[0027] Therefore, when using test cases to post-simulate the SoC to test subsystem functionality, memory repair testing is a necessary step before executing the test cases. Specifically, during the memory repair process, the memory repair controller performs repair tests on each subsystem in the SoC in turn. This pre-emptive step aims to preemptively identify and repair potential defects in the memory of each subsystem in the SoC, ensuring the accuracy and reliability of subsequent functional testing and preventing memory failures from interfering with the test case results, thereby ensuring that the test case truly reflects the functional characteristics of the SoC.

[0028] However, as the integration of system-level chips continues to increase, the number and complexity of subsystems within the chip are growing exponentially. Therefore, performing memory repair on all subsystems during the memory repair process will result in excessively long repair test times, affecting the verification efficiency of the system-level chip.

[0029] In view of this, an embodiment of the present application provides a repair test evaluation method for a system-on-chip (SoC) to shorten the repair test cycle of the SoC and improve test efficiency.

[0030] It should be noted that the method for repair test and evaluation of a system-level chip provided in an embodiment of the present invention may be executed by a device for repair test and evaluation of a system-level chip, and the device for repair test and evaluation of a system-level chip may be implemented as part or all of an electronic device through software, hardware, or a combination of software and hardware, wherein the electronic device may be a server or a terminal, wherein the server in the embodiment of the present application may be a single server or a server cluster composed of multiple servers, and the terminal in the embodiment of the present application may be a smart phone, a personal computer, a tablet computer, a wearable device, an intelligent robot, or other intelligent hardware devices. In the following method embodiments, the execution subject is an electronic device as an example for explanation.

[0031] According to an embodiment of the present invention, an embodiment of a repair test and evaluation method for a system-level chip is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0032] In this embodiment, a repair test and evaluation method for a system-on-chip is provided, which can be used in the above-mentioned electronic devices, such as servers, etc. Figure 1 FIG. 1 is a flow chart of a repair test and evaluation method for a system-on-chip according to an embodiment of the present invention. Figure 1 As shown, the process includes:

[0033] S101: Filtering out a target subsystem that does not perform a repair test from a plurality of subsystems included in the system-on-chip according to the function of the test case currently to be run.

[0034] Specifically, a system-on-chip (SoC) is an integrated circuit that integrates multiple subsystems with specific functions onto a single chip, thereby implementing complex system functions. The subsystems can implement functions such as task scheduling (such as determining the priority of scheduled tasks), digital signal processing (such as signal filtering and Fourier transforms), basic input and output interaction with the external environment, image processing, power management, and security and encryption functions. For example, a SoC includes components such as a processor, peripheral interfaces, and subsystems.

[0035] Test cases are used to verify whether a subsystem within a system-on-chip (SoC) functions as intended. For example, if you need to verify the image recognition functionality of an image processing subsystem, you can use the corresponding image processing test case. Here, the function of a test case can be understood as testing whether the subsystem functions as intended. Exemplarily, a test case includes input data, execution conditions, and expected results.

[0036] When performing post-simulation functional testing on a subsystem within a SoC using a test case, for example, during the initial simulation phase when the simulation tool utilizes the test case and the SoC's netlist data, the memory repair controller within the SoC will perform a repair test on the subsystem within the SoC to verify that the subsystem's memory is functioning properly. Only after the memory repair controller completes the repair test will the simulation tool perform functional testing on the subsystem within the SoC based on the inputs and execution conditions specified in the test case.

[0037] In the embodiment of the present application, the test case testing of the subsystem is called a functional test, and the memory repair controller testing of the subsystem memory is called a repair test. The target subsystem that does not perform the repair test is the subsystem on which the memory repair controller does not perform the repair test.

[0038] S102: When there is a target subsystem that does not perform a repair test among the multiple subsystems, first identification information corresponding to the target subsystem is obtained.

[0039] Specifically, the first identification information is used to identify the target subsystem in the system-on-chip. The first identification information may be the name, interface, number, or other information of the target subsystem that can uniquely identify and locate the target subsystem.

[0040] S103: Adjust first memory repair instruction information corresponding to the target subsystem according to the first identification information.

[0041] The first memory repair indication information is used by the memory repair controller to not perform a repair test on the target subsystem during the memory repair process according to the first memory repair indication information.

[0042] In one possible implementation, a memory repair controller is responsible for performing memory error testing (such as bit flips and address conflicts) and repairs on each subsystem in the SoC. The memory repair controller performs repair tests on each subsystem in the SoC based on the memory repair instructions from each subsystem. In other words, the memory repair instructions influence the execution logic of the memory repair process. After receiving the first memory repair instruction information for a target subsystem, the memory repair controller skips the memory repair test for the target subsystem during the repair process, i.e., it does not perform repair tests on the target subsystem.

[0043] Optionally, the memory repair controller includes but is not limited to a built-in self-repair (BISR) controller, a built-in self-test (BIST), a built-in redundancy analysis (BIRA) controller, etc. The BIST controller is used to perform self-inspections on the subsystem's memory and determine memory fault information. Fault information includes but is not limited to a fault status signal (used to indicate whether the subsystem's memory has a fault), the specific content of the fault (such as the location of the faulty unit and the type of fault), etc. The BIRA controller manages the allocation and optimization modules of memory redundant resources (such as redundant rows, columns, and word lines) and determines repair information. Repair information includes but is not limited to information about the redundant unit used to replace the faulty unit (such as the location of the redundant unit), the status mark of the redundant unit (such as available or occupied), etc. The BISR controller repairs the fault in the memory based on the repair information and generates repair result information. The repair result information includes but is not limited to a repair completion signal (used to indicate whether the repair is complete), repair duration, repair log, etc. The above-mentioned fault information, repair information, and repair result information are stored in registers corresponding to the memory repair controller, such as a BISR chain (also called a BISR register array).

[0044] In one possible implementation, the memory repair indication information of each subsystem is used to control the repair test behavior of the memory repair controller. Exemplarily, the memory repair control information can be in the form of a register value, a flag bit, etc. The first memory repair indication information is a specific instance of the memory repair indication information. Exemplarily, the memory repair indication information of each subsystem can be a preset high voltage and a preset low voltage. The preset high voltage is used to instruct the memory repair controller to perform a repair test on the subsystem. The preset low voltage is used to instruct the memory repair controller not to perform a repair test on the subsystem. In this case, the first memory repair indication information of the target subsystem is the preset low voltage.

[0045] In one possible implementation, the memory repair instruction information of the target subsystem is located based on the first identification information, and the memory repair instruction information of the target subsystem is adjusted to the first memory repair instruction information. For example, by default, the memory repair instruction information of each subsystem is used to instruct the memory repair controller to perform a repair test on each subsystem. If a subsystem in the system-on-chip is determined to be the target subsystem, the memory repair instruction information of that subsystem is changed to the first memory repair instruction information. In this way, the memory repair controller will not perform a repair test on the target subsystem during the memory repair process.

[0046] In an embodiment of the present application, test cases for different functions often focus on testing the subsystems in the system-on-chip that correspond to the function. For example, for image recognition test cases, the focus is on the subsystem in the system-on-chip used to implement the image recognition function, but not on the subsystems used to implement functions such as voice recognition. Therefore, during the repair test process of a certain test case, the target subsystem that needs to undergo a memory repair test can be accurately located based on the function of the test case, and then the first memory indication information of the target subsystem can be adjusted based on the first identification information of the target subsystem, so that the memory repair controller does not perform a repair test on the target subsystem based on the first memory repair indication information. In other words, during the memory repair process corresponding to the present application, repair tests are not performed on all subsystems in the system-on-chip, but on the target subsystems determined based on the test case function. In this way, unnecessary repair tests on subsystems that are not related to the function of the current test case are effectively avoided, the repair test operations of the memory repair controller are reduced, the test cycle of the system-on-chip is shortened, and the test efficiency is improved.

[0047] In some embodiments, the first identification information is interface information corresponding to the target subsystem.

[0048] The target subsystem's interface information describes the hardware interface parameters, memory address range, communication protocol, and other information needed for external interaction. This information can be extracted from the SoC's netlist file. For example, the target subsystem's interface information can be extracted from the SoC's netlist file using the target subsystem's top-level module name as a keyword.

[0049] In one possible implementation, Figure 2 FIG. 1 is a flowchart of another method for repair test and evaluation of a system-on-chip according to an embodiment of the present application. Figure 2 As shown in the figure, the process includes the following:

[0050] S201: Based on the function of the test case to be run, select the target subsystem that does not need to be repaired from the multiple subsystems included in the system-level chip. Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0051] S202: If there is a target subsystem that does not perform the repair test among the multiple subsystems, obtain the first identification information corresponding to the target subsystem. Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0052] S203: Adjust first memory repair instruction information corresponding to the target subsystem according to the first identification information.

[0053] Specifically, the above S203 includes:

[0054] S2031: Generate a stub file corresponding to the target subsystem based on the interface information.

[0055] In one possible implementation, a stub file is a virtual file that simulates a target subsystem and typically contains preset operations for interface information, such as register reads and writes, function return values, and the like within the simulated subsystem. In an embodiment of the present application, the stub file is a control instruction file for the target subsystem, used to control the memory repair behavior of the memory repair controller. Exemplarily, the format of the stub file can be State Transition (ST) stubs, JavaScript Object Notation (JSON), and other formats, which are not specifically limited in this application.

[0056] S2032: Adjust the first memory repair instruction information according to the piling file.

[0057] The adjusting of the first memory repair indication information includes: modifying a signal value of a memory repair signal corresponding to the target subsystem to a preset value, where the preset value is used to indicate that no repair test is performed on the target subsystem.

[0058] In one possible implementation, the memory repair signal is a signal used to control the memory repair controller to perform a repair test. The signal value of the memory repair signal determines whether the memory repair controller performs a repair test on the target subsystem. Exemplarily, the memory repair signal can be a binary signal (such as 0 / 1), a potential signal (such as high or low level), a register value, and the like. For example, a high level of the memory repair signal indicates that a repair test is performed on the subsystem. A low level of the memory repair signal indicates that a repair test is not performed on the subsystem. This application does not specifically limit the preset value of the memory repair signal, and it can be set according to actual conditions.

[0059] Optionally, the memory repair signal includes but is not limited to a repair enable signal, a fault status signal, a repair completion signal, and the like of the memory repair controller. The repair enable signal serves as a switch of the memory repair controller, controlling whether the memory repair controller performs a repair test on the subsystem. For the repair enable signal corresponding to the target subsystem, it can be set to a repair enable signal corresponding to a repair test that is not required. For example, when the repair enable signal is valid at a high level (i.e., when the repair enable signal is at a high level, the memory repair controller performs a repair test on the subsystem), the repair enable signal of the target subsystem is set to a low level, causing the memory repair controller to skip the repair test of the memory of the target subsystem. The fault status signal is used to indicate whether a memory fault of the subsystem is detected. For a target subsystem that does not require a repair test, the fault status can be set to a signal value corresponding to no fault. The repair completion signal is used to indicate whether the repair test of the subsystem has been completed. For a target subsystem that does not require a repair test, the repair completion flag can be set to completed or a specific invalid value, so that the memory repair controller skips the repair test of the target subsystem.

[0060] In one possible implementation, a stub file containing a memory repair signal with a preset value is created based on the target subsystem's interface information. Thus, during the memory repair process, if the memory repair controller detects that the target subsystem's internal repair signal is at the preset value, it will not perform a repair test on the target subsystem.

[0061] Exemplarily, in the process of generating a pile driving file based on interface information, first, the target information in the interface information is parsed, such as the name of the target subsystem, the interface type, the memory area address range, the signal value of the memory repair signal, etc. Then, according to the specific format of the pile driving file (such as JSON), the clear information is structured and arranged. Taking the JSON format as an example, the first identification information of the subsystem is used as the primary key, the memory repair signal name, the memory address range, etc. are used as subkeys, and the preset value (such as "0" means to turn off repair) is used as the corresponding value to form a key-value pair structure. Finally, the arranged information is used to generate a pile driving file in a preset format. At this point, the pile driving file contains specific instructions for controlling the repair test behavior of the memory repair controller, so that the memory repair controller does not perform repair tests on the target subsystem.

[0062] In a possible implementation, adjusting the first memory repair instruction information further includes: under preset conditions, resuming a repair test on the target subsystem.

[0063] Exemplarily, the preset conditions include the target subsystem having a memory error count greater than a preset error count, or preset status data (such as the target subsystem's temperature, voltage, and power consumption) exceeding a preset status range. The preset error count and preset status range can be set based on actual conditions, such as based on historical operating data of the target subsystem.

[0064] For example, during the memory repair process, if the number of memory errors or preset status data of the target subsystem exceeds a preset range, the target subsystem is simulated through a stub file to control the memory repair controller to perform a recovery repair test.

[0065] Optionally, the stub file may include not only the memory repair signal as a preset value, but also a recovery test strategy, wherein the recovery test strategy is used by the memory repair controller to resume the repair test on the target subsystem under preset conditions.

[0066] This approach accelerates SoC testing by disabling repair testing of the target subsystem at the beginning of the memory repair process, further shortening the test case functional verification cycle. Furthermore, in critical situations, such as increased memory error rates or abnormal temperatures, repair testing of the target subsystem is automatically resumed, improving detection efficiency while ensuring the reliability and stability of the target subsystem's operation, providing strong support for efficient SoC verification.

[0067] It is understandable that the memory repair indication information can also be stored in a register corresponding to the memory repair controller (such as a BISR chain), so that the memory repair controller performs a repair test on the subsystem memory based on the memory repair indication information.

[0068] Of course, in addition to replacing the netlist file of the target subsystem with the stub file to achieve the target subsystem without performing memory repair testing, it is also possible to intercept the memory repair signal of the target subsystem during the simulation process through the simulation tool and force its signal value to be modified to the preset value, or to modify the static configuration file in the memory repair controller to modify the signal value of the memory repair signal of the target subsystem to the preset value.

[0069] In some embodiments, the method provided in the embodiments of the present application further includes the following:

[0070] First, the netlist file of the target subsystem is extracted from the netlist file of the system-level chip.

[0071] In one possible implementation, when using test cases to perform functional testing on a system-on-chip (SoC), a simulation tool performs testing based on the SoC's netlist file. A netlist file is a text file that describes the subsystems and their connections within the SoC. Exemplary netlist files can be in the format of a Verilog netlist (.v), a Very-High-Speed ​​Integrated Circuit Hardware Description Language (VHDL) netlist (.vhd), or the like.

[0072] In a possible implementation, the netlist file of the target subsystem may be separated from the netlist file of the system-on-chip based on the first identification information of the target subsystem.

[0073] Then, the netlist file of the target subsystem is replaced with the stub file to obtain the updated netlist file of the system-level chip.

[0074] The updated netlist file is used to test whether the target subsystem has the functionality of the test case. This application does not specifically limit the specific implementation method for performing functional testing based on the updated netlist file and test case, and can be selected based on actual circumstances. For example, a simulation tool can be used to perform functional testing on the system-on-chip based on the updated netlist file and test case.

[0075] In one possible implementation, the target subsystem's netlist is deleted from the SoC's netlist and the stub file is inserted into the SoC's netlist to obtain an updated SoC netlist. During the replacement process, the input and output ports of the stub file must be consistent with those of the target subsystem.

[0076] In this embodiment of the present application, a stub file is used as a simplified model of the target subsystem, retaining only interface information and necessary behavioral logic. (In this embodiment of the present application, the stub file is used to instruct the memory repair controller not to perform repair testing on the target subsystem.) This can reduce the complexity of SoC testing and shorten testing time.

[0077] In some embodiments, in the above S101, the target subsystem not to be repaired is selected from the plurality of subsystems included in the system-on-chip in the following manner:

[0078] A subsystem that does not have the function of a test case is screened out from a plurality of subsystems included in the system-on-chip and is determined as a target subsystem.

[0079] In this way, the focus of repair testing is placed on subsystems that affect functional implementation, excluding the repair process of subsystems that are not related to the test case function, and avoiding transition testing of irrelevant subsystems, thereby achieving the purpose of shortening test time and reducing simulation complexity.

[0080] In one possible implementation, the function of the test case can be obtained by parsing the test case. Exemplarily, at least one preset keyword is extracted from the text of the test case, and a feature vector of the test case is constructed to characterize the function of the test case. The keyword can be a term in the field of system-on-chip. Similarly, the function of the subsystem can also be characterized by a feature vector. For example, a functional description is extracted from the data manual of the system-on-chip, and a feature vector of the subsystem is constructed to characterize the function of the subsystem. Furthermore, the target subsystem is determined based on the feature vector of the test case and the feature vector of the subsystem. For example, the similarity between the feature vector of the test case and the feature vector of the subsystem is calculated. When the similarity is less than or equal to a preset threshold, it is determined that the subsystem has the function of the test case and the subsystem is determined as the target subsystem; when the similarity is greater than the preset threshold, it is determined that the subsystem does not have the function of the test system.

[0081] In one possible implementation, the method provided in the embodiment of the present application further includes the following:

[0082] From the subsystems that do not have the functions of the test case, subsystems that do not establish an interactive relationship with the subsystems that have the functions of the test case are further screened and determined as target subsystems.

[0083] Optionally, the interactive relationship refers to communication between subsystems through a data bus, control signals, shared resources (such as interrupt signals), etc.

[0084] Exemplarily, by traversing the syntax tree of each subsystem, extracting the port connection relationship between each subsystem, the calling relationship between subsystems, the signal connection relationship, etc., the interaction relationship between each subsystem is determined. Among them, the syntax tree of the subsystem refers to the tree structure generated after the syntax analysis of the subsystem code, the nodes represent the syntax units (such as subsystem definition, instantiation statement, signal declaration, etc.), and the edges represent the syntax hierarchy relationship. The port connection relationship is used to characterize the direct connection between the subsystem port and the other subsystem ports. The calling relationship is the instantiation reference of the subsystem to other subsystems. The signal connection relationship refers to the data transmission between subsystems through interrupt signals (such as buses, shared variables).

[0085] Taking the port connection relationship between subsystems as an example, suppose subsystem B has the test case function, and subsystem A does not have the test case function, but there is a connection relationship between port 1 of subsystem A and port 2 of subsystem B. The output of port 1 of subsystem A may affect subsystem B, thereby interfering with the functional test of subsystem B. In this case, there is an interactive relationship between subsystems A and subsystem B.

[0086] Taking the inter-subsystem calling relationship as an example, suppose subsystem B has the test case function, and subsystem A does not have the test case function, but subsystem B needs to call subsystem A during operation. Subsystem A will affect subsystem B, thereby interfering with the functional testing of the subsystem. In this case, there is an interactive relationship between subsystems A and B.

[0087] Taking the signal connection relationship between subsystems as an example, suppose subsystem B has the test case function, subsystem A does not have the test case function, but the signal output of subsystem A affects subsystem B. In this case, there is an interactive relationship between subsystems A and B.

[0088] For example, when using a test case to test the image processing function of the Graphics Processing Unit (GPU) subsystem, the GPU subsystem transfers graphics data to the memory through the Direct Memory Access (DMA) subsystem during operation. At this time, although the DMA subsystem does not have an image processing function, an interactive relationship is established between the DMA subsystem and the GPU subsystem, specifically the port connection relationship and the signal connection relationship. In this case, the DMA subsystem also needs to ensure normal operation, and the DMA subsystem needs to be tested for memory repair. Therefore, neither the GPU subsystem nor the DMA subsystem will be used as the target subsystem.

[0089] In the implementation of the present application, the system-on-chip includes multiple subsystems, and the memory repair test requires computing resources and time. Whether or not the memory repair test is performed on a subsystem that is irrelevant to the test case function and has no interactive relationship will not affect the test results of the test case. By setting such subsystems as target subsystems and skipping the repair test, the repair resources of the memory repair controller can be concentrated on the subsystems that truly affect the functional test results, reducing the number of repair test subsystems of the memory repair controller, reducing the test complexity, shortening the repair test time, and further shortening the overall test time of the test case, thereby improving the verification efficiency of the system-on-chip.

[0090] In another possible implementation, the method provided in the embodiment of the present application further includes the following content:

[0091] First, get a list of systems in the SoC.

[0092] Optionally, the system list is used to display subsystems in the system-on-chip that do not have test case functions.

[0093] Optionally, the system list is used to display subsystems in the system-on-chip that do not have test case functions and do not establish interactive relationships with subsystems that have test case functions.

[0094] Of course, the system list can also be used to display all subsystems in the system-level chip, subsystems with frequent memory errors in historical operations, and so on.

[0095] Then, the receiving object performs a selection operation on the target subsystem in the system list.

[0096] In this way, the operator can select the target subsystem according to the test requirements without being limited to a fixed test process, which enhances the flexibility of repair testing.

[0097] Figure 3 This is a schematic diagram of repairing and testing the memory of multiple subsystems in a system-on-chip provided by an embodiment of the present application. Figure 3 The system-on-chip (SoC) in this paper includes the always-on (AON) subsystem, the double data rate (DDR) subsystem, the core processing subsystem, the high-speed peripheral component interconnect (PCIE) subsystem, and the peripheral device subsystem. The AON subsystem provides the chip with essential functions that always remain operational, such as a real-time clock and low-power management, ensuring the chip maintains necessary functionality under all operating conditions. The DDR subsystem manages and controls the double data rate synchronous dynamic random access memory (SDRAM), enabling high-speed data transmission and storage. The core processing subsystem contains the core components of the central processing unit (CPU), such as the arithmetic logic unit (ALU), registers, and control units, responsible for executing computer instructions, performing data calculations, and processing. The PCIE subsystem is a high-speed serial bus standard used to connect various computer peripherals, such as graphics cards, network cards, and solid-state drives. The peripheral device subsystem includes input / output devices, communication equipment, and other components, responsible for external communication and data transmission.

[0098] Taking the test case used to test the internal integrated circuit two-wire serial bus (Inter-Integrated Circuit, I2C) function of the peripheral device subsystem as an example, in the related art, such as Figure 3As shown in the figure, the memory repair controller performs repair testing on all subsystems in the SoC. The specific process involves: When the SoC is powered on or reset, the BISR controller configures the information in the BISR chain to all 0s. The BIST controller then tests the memory of each subsystem, detects fault information during testing, and writes this information to the BISR chain. Next, the BIRA controller determines repair information based on the fault information detected by the BIST controller and stores it in a local BIRA register. The BIRA controller then executes the "transfer BIRA to BISR" instruction to transfer the repair information stored in the local BIRA register to the BISR chain. Finally, the BISR controller compresses the repair information stored in the BISR chain and burns it into the one-time programmable memory (eFuse). The BIST controller then removes the repair information from the BIRA register. During subsequent memory repair, the BISR controller loads the repair information from the eFuse and transmits it through the BISR chain to the memory's repair port, thereby repairing the memory fault.

[0099] In the method provided in the embodiment of the present application, based on the function of the test case, that is, the I2C function, the various subsystems in the system-level chip are screened to determine the target subsystem that does not perform memory repair. In the system-level chip, the AON subsystem, DDR subsystem, Core processing subsystem, and PCIE subsystem are not involved in the I2C function. Among them, although the AON subsystem does not involve the I2C function, it has an interactive relationship with the Peripheral device subsystem with the I2C function. Therefore, if Figure 4 As shown, the target subsystems are the DDR subsystem, the Core processing subsystem, and the PCIE subsystem. The netlist files for these three subsystems are replaced with their respective stub files. Using these stub files, the first memory repair instructions for these three subsystems are adjusted, causing the memory repair controller to skip the repair test for these three subsystems, shortening the repair test time and improving test efficiency.

[0100] In some embodiments, after S101 above, the method provided in the embodiment of the present application further includes the following:

[0101] First, second identification information corresponding to the remaining subsystems except the target subsystem in the plurality of subsystems is obtained.

[0102] In a possible implementation, the second identification information is used to identify the remaining subsystems in the system-on-chip excluding the target subsystem. Exemplarily, the second identification information may be information such as the physical address and name of the subsystem.

[0103] Then, the system type of each remaining subsystem is identified according to the second identification information corresponding to each remaining subsystem.

[0104] In a possible implementation, in a system-on-chip, the system type can be used to characterize the function, importance, resource consumption, historical memory error count, etc. of a subsystem.

[0105] The importance of a subsystem can be measured by its impact on the overall operation of the SoC. For example, systems classified based on importance can be classified into critical subsystems and non-critical subsystems. A critical subsystem might be the security and encryption subsystem of the SoC; failure in this subsystem could lead to serious risks such as data leakage. A non-critical subsystem might be the audio codec subsystem; failure in this subsystem could affect some functions within the SoC but not the chip's primary functionality.

[0106] The resource consumption level of a subsystem can be measured by the amount of resources such as power consumption and bus bandwidth consumed during operation. For example, systems classified based on resource consumption can be classified as high-resource-consuming subsystems or low-resource-consuming subsystems. A high-resource-consuming subsystem might be one that runs a deep learning model, while a low-resource-consuming subsystem might be one responsible for low-speed serial communication.

[0107] The subsystem's historical memory error count may be the number of memory errors (such as bit flips and out-of-bounds access) that occurred during the subsystem's historical operation. For example, system types based on the historical memory error count may include high-risk subsystems and low-risk subsystems. A high-risk subsystem has a historical memory error count greater than or equal to a preset threshold, while a low-risk subsystem has a historical memory error count less than the preset threshold.

[0108] Finally, according to the system types corresponding to the remaining subsystems, the second memory repair instruction information corresponding to each remaining subsystem is adjusted, and the second memory repair instruction information is used to instruct the memory repair controller to perform memory repair on the remaining subsystems in an execution order.

[0109] In one possible implementation, the second memory repair instruction information may be a numeric value, where the value directly indicates the execution order of the remaining subsystems. For example, a smaller value indicates an earlier execution order. The second memory repair instruction information may also be a structured data structure, such as a key-value pair, an array, or a list, to determine the execution order of the remaining subsystems.

[0110] Continuing with the example of the system type used to characterize a subsystem's function, importance, resource consumption, and historical memory error count, if the system type is used to characterize the subsystem's function, memory repair testing will prioritize subsystems that play a critical supporting role in the SoC. If the system type is used to characterize the subsystem's importance, memory repair testing will prioritize subsystems with higher importance. If the system type is used to characterize the subsystem's resource consumption, subsystems with high resource consumption frequently read and write memory during operation, resulting in a relatively high probability of memory errors. Once an error occurs, the probability of memory errors is significantly impacted by the SoC's performance. Therefore, repair testing will prioritize subsystems with high resource consumption. If the system type is used to characterize the subsystem's historical memory error count, subsystems with a high error count will be considered high-risk and prioritized for memory repair testing to reduce the likelihood of failure. Subsystems with fewer errors, however, have better memory stability and can be repaired with a more deferred repair period.

[0111] In addition, the system type can also be used to characterize the real-time requirements for the subsystem. For example, the execution order of the real-time subsystem (that is, the system that needs to complete a specific task within a preset time) is arranged before the non-real-time subsystem, such as the batch processing subsystem (that is, the subsystem that processes a series of tasks in a preset order, such as the report generation subsystem). This is because the real-time subsystem has strict requirements for response time, and if there is a response delay, it may lead to serious consequences, while the batch processing subsystem pays more attention to the overall processing efficiency and resource utilization, and has relatively low requirements for real-time performance. Therefore, for the real-time subsystem, repair testing is performed first to quickly discover and solve potential problems. For the batch processing subsystem, repair testing can be arranged at a later time to make the memory repair process more efficient and improve the pertinence of the repair test.

[0112] In another possible implementation, the second memory repair indication information is also used to indicate the scope of repair testing for each remaining subsystem, such as full memory space repair, critical register area repair, partition repair, etc. Among them, full memory space repair refers to performing a complete repair test on all memory areas of the subsystem, covering all storage units. Critical register area repair refers to performing repair tests only on critical register areas in the subsystem that are directly related to the core functions, skipping non-critical or redundant memory areas. Partition repair refers to dividing the memory of the subsystem into multiple logical partitions (such as by rows and columns), and selecting one or more areas for repair testing.

[0113] In this way, the second memory repair instruction information can significantly improve the flexibility and efficiency of repair testing by indicating the memory repair test scope of the remaining subsystems (such as full memory space repair, key register area repair, and partition repair). Specifically, full memory space repair ensures comprehensive coverage of the subsystem's memory to avoid missing potential defects; key register area repair focuses on core functional units, giving priority to ensuring the stability of key subsystem services within a limited time, thereby reducing the duration of repair testing; partition repair supports dividing repair areas according to memory physical blocks or logical functions, allowing the system to maintain normal operation of other areas while repairing some areas, reducing the risk of functional interruption during the repair period.

[0114] Of course, in other possible implementations, the second memory repair indication information is also used to indicate the maximum allowed repair test time, repair algorithm, repair resource allocation (i.e., redundant memory resources that can be used for repair), etc. of each remaining subsystem, so as to adapt to the diverse needs of system-level chips.

[0115] In some embodiments, the test case is a test case in a test case set; the test case in the test case set is used to test the system-on-chip according to a preset test sequence.

[0116] In one possible implementation, the test case set includes multiple test cases, which perform functional tests on the system-on-chip in a preset order. Through the multiple test cases in the test case set, a comprehensive system test of the functions of the system-on-chip can be achieved.

[0117] The test order of each test case in the test case set refers to the order in which each test case is executed. The test order can be determined based on the function of each test case, test complexity, etc., and this application does not make specific restrictions on this.

[0118] In one possible implementation, the method provided in the embodiment of the present application further includes:

[0119] Subsystems that do not have the functions of the test case and subsystems that perform repair tests in the test case before the test case are screened out from multiple subsystems included in the system-level chip as target subsystems.

[0120] Among them, the subsystem that performs repair testing in the test case before the test case in the test sequence means that the repair testing of the subsystem has been executed in the previous test case, and therefore, there is no need to repeat it in the repair testing corresponding to the current test case.

[0121] For example, a system-on-chip includes subsystems A, B, C, and D. Subsystems A and B have the functionality of test case 2, while subsystems C and D do not. Subsystem B has already been repaired in test case 1, which precedes test case 2 in the test sequence. Therefore, subsystems B, C, and D are identified as target subsystems and will not be repaired in the repair test corresponding to test case 2.

[0122] In the implementation of this application, the system-on-chip structure is complex and contains multiple subsystems. If all subsystems are tested for memory repair in each test case, a large number of redundant operations will be performed, wasting computing resources and time. Only operating on subsystems related to the current test case and for which repair testing has not yet been completed can avoid repeated testing of a subsystem, shorten the repair test time, and improve test efficiency. In addition, unnecessary test processes for the memory repair controller are reduced, reducing the resource consumption of the memory repair controller and improving resource utilization efficiency.

[0123] The above mainly introduces the solution provided in the embodiment of the present application from the perspective of method.

[0124] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0125] In the embodiments of the present application, a repair test and evaluation device for a system-on-chip is also provided. The device is used to implement the above-mentioned embodiments and preferred embodiments, and the details already described will not be repeated. As used below, the term "module" can mean a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0126] This embodiment provides a system-on-chip repair test and evaluation device, such as Figure 5 Shown, including:

[0127] A screening module 501 is configured to screen out target subsystems that are not to be tested for repair from a plurality of subsystems included in the system-on-chip according to the function of the test case currently to be run;

[0128] An acquisition module 502 is configured to acquire first identification information corresponding to a target subsystem that does not perform a repair test, if there is a target subsystem among the multiple subsystems;

[0129] The adjustment module 503 is used to adjust the first memory repair indication information corresponding to the target subsystem according to the first identification information. The first memory repair indication information is used by the memory repair controller to not perform a repair test on the target subsystem during the memory repair process according to the first memory repair indication information.

[0130] Through the device provided by the embodiment of the present application, test cases of different functions often focus on testing the subsystems corresponding to the function in the system-level chip. For example, for image recognition test cases, the focus is on the subsystem in the system-level chip used to implement the image recognition function, while not focusing on the subsystems used to implement functions such as voice recognition. Therefore, in the repair test process of a certain test case, the target subsystem that needs to undergo memory repair testing can be accurately located based on the function of the test case, and then the first memory indication information of the target subsystem can be adjusted based on the first identification information of the target subsystem, so that the memory repair controller does not perform repair testing on the target subsystem based on the first memory repair indication information. In other words, in the memory repair process corresponding to the present application, repair testing is not performed on all subsystems in the system-level chip, but on the target subsystem determined based on the test case function. In this way, unnecessary repair testing of subsystems that are not related to the function of the current test case is effectively avoided, the repair test operations of the memory repair controller are reduced, the test cycle of the system-level chip is shortened, and the test efficiency is improved.

[0131] In one possible implementation, the adjustment module 503 is specifically used to generate a stubbing file corresponding to the target subsystem based on the interface information; and adjust the first memory repair indication information based on the stubbing file, wherein adjusting the first memory repair indication information includes: modifying the signal value of the memory repair signal corresponding to the target subsystem to a preset value, and the preset value is used to indicate that no repair test is performed on the target subsystem.

[0132] In a possible implementation, the acquisition module 502 is further configured to extract a netlist file of the target subsystem from a netlist file of the system-on-chip;

[0133] The acquisition module 502 is further used to replace the netlist file of the target subsystem with the stub file, and obtain the updated netlist file of the system-on-chip to test whether the target subsystem has the function of the test case.

[0134] In a possible implementation, the screening module 501 is specifically configured to screen out subsystems that do not have the functions of the test case from the multiple subsystems included in the system-on-chip, and determine them as target subsystems.

[0135] In a possible implementation, the screening module 501 is further configured to screen subsystems that do not have a test case function and do not have an interactive relationship with the subsystem that has a test case function from the subsystems that do not have a test case function, and determine them as target subsystems.

[0136] In a possible implementation, the acquisition module 502 is further configured to acquire second identification information corresponding to the remaining subsystems except the target subsystem in the plurality of subsystems;

[0137] The device further includes: an identification module for identifying the system type of each remaining subsystem according to the second identification information corresponding to each remaining subsystem;

[0138] The adjustment module 503 is also used to adjust the second memory repair indication information corresponding to each remaining subsystem according to the system types corresponding to the remaining subsystems. The second memory repair indication information is used to instruct the memory repair controller to perform memory repair on the remaining subsystems in an execution order.

[0139] In a possible implementation, the test case is a test case in a test case set; the test case in the test case set is used to test the system-on-chip according to a preset test sequence;

[0140] The screening module 501 is further configured to screen out subsystems that do not have the functions of the test case from the multiple subsystems included in the system-on-chip, and subsystems that perform repair tests in the test case before the test case as target subsystems.

[0141] For the description of the features in the embodiment corresponding to the repair test and evaluation device for system-on-chip, reference can be made to the relevant description of the embodiment corresponding to the repair test and evaluation method for system-on-chip, which will not be repeated here.

[0142] The embodiment of the present application also provides an electronic device, such as Figure 6 As shown, it includes a memory 10 and a processor 20, wherein the memory 10 stores a computer program, and the processor 20 is configured to run the computer program to execute the steps in any of the above-mentioned system-on-chip repair test and evaluation method embodiments.

[0143] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned system-on-chip repair test and evaluation method embodiments when run.

[0144] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0145] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned system-on-chip repair test and evaluation method embodiments are implemented.

[0146] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps in any of the above-mentioned system-on-chip repair test and evaluation method embodiments.

[0147] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0148] The above is a detailed introduction to the repair test and evaluation method, device and electronic device for a system-on-chip provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A repair test and evaluation method for a system-on-chip, characterized in that: The method comprises: According to the function of the test case currently to be run, a target subsystem that is not to be subjected to repair test is screened out from the plurality of subsystems included in the system-on-chip; If there is a target subsystem that does not perform the repair test among the multiple subsystems, obtaining first identification information corresponding to the target subsystem; According to the first identification information, first memory repair indication information corresponding to the target subsystem is adjusted, and the first memory repair indication information is used by a memory repair controller to not perform a repair test on the target subsystem during a memory repair process according to the first memory repair indication information.

2. The method according to claim 1, characterized in that The first identification information is interface information corresponding to the target subsystem, and adjusting the first memory repair instruction information corresponding to the target subsystem according to the first identification information includes: Generate a stubbing file corresponding to the target subsystem according to the interface information; According to the piling file, the first memory repair indication information is adjusted, wherein the adjusting of the first memory repair indication information includes: modifying the signal value of the memory repair signal corresponding to the target subsystem to a preset value, wherein the preset value is used to indicate that no repair test is performed on the target subsystem.

3. The method according to claim 2, characterized in that The method further comprises: Extracting the netlist file of the target subsystem from the netlist file of the system-on-chip; The netlist file of the target subsystem is replaced with the stub file, and the updated netlist file of the system-on-chip is obtained to test whether the target subsystem has the function of the test case.

4. The method according to any one of claims 1 to 3, characterized in that The step of screening out a target subsystem that is not to be tested for repair from a plurality of subsystems included in the system-on-chip according to the function of the test case currently to be run comprises: A subsystem that does not have the function of the test case is screened out from the multiple subsystems included in the system-on-chip and determined as the target subsystem.

5. The method according to claim 4, characterized in that The method further comprises: From the subsystems that do not have the function of the test case, subsystems that do not establish an interactive relationship with the subsystem that has the function of the test case are further screened and determined as the target subsystems.

6. The method according to any one of claims 1 to 3, characterized in that After selecting a target subsystem that does not perform a repair test from the multiple subsystems included in the system-on-chip according to the function of the test case currently to be run, the method further includes: Obtaining second identification information corresponding to the remaining subsystems in the plurality of subsystems except the target subsystem; identifying the system type of each of the remaining subsystems according to the second identification information corresponding to each of the remaining subsystems; According to the system types corresponding to the remaining subsystems, the second memory repair indication information corresponding to each of the remaining subsystems is adjusted, and the second memory repair indication information is used to instruct the memory repair controller to perform memory repair on the remaining subsystems in an execution order.

7. The method according to claim 1, characterized in that The test case is a test case in a test case set; The test cases in the test case set are used to test the system-on-chip according to a preset test sequence; The method further comprises: A subsystem that does not have the function of the test case is screened out from the multiple subsystems included in the system-on-chip, and a subsystem that performs the repair test in a test case before the test case in the test sequence is selected as the target subsystem.

8. A system-on-chip repair test and evaluation device, characterized in that: The device comprises: A screening module, configured to screen out target subsystems that are not to be tested for repair from the plurality of subsystems included in the system-on-chip according to the function of the test case currently to be run; An acquisition module, configured to acquire first identification information corresponding to a target subsystem that does not perform a repair test if the target subsystem exists among the multiple subsystems; An adjustment module is used to adjust the first memory repair indication information corresponding to the target subsystem according to the first identification information, and the first memory repair indication information is used by the memory repair controller to not perform a repair test on the target subsystem during the memory repair process according to the first memory repair indication information.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor is configured to implement the steps of the repair test and evaluation method for a system-on-chip according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the repair test and evaluation method for a system-on-chip according to any one of claims 1 to 7 are implemented.

Images