Chip testing method and device, equipment, storage medium and computer program product

Abstract

The invention discloses a chip testing method and device, equipment, a storage medium and a computer program product, and relates to the technical field of automatic testing, and the method comprises the steps: electrifying each core on a to-be-tested chip, and distributing an identification number for each core; determining a main core from the cores, and determining a target subprogram from preset functional subprograms through the main core; each target subprogram is distributed to a target core in each core through the main core, and the target core executes the received target subprogram, performs self-inspection after execution is completed and returns a self-inspection result; and after each self-checking result is received through the main core, returning to execute the step of determining the target sub-program from the preset functional sub-programs through the main core until each core finishes self-checking. According to the method and the device, a complicated test task can be executed without an operating system, so that the self-inspection of the chip can be completed without depending on the operating system.

Description

Technical Field

[0001] The present application relates to the field of automated testing technology, and in particular to chip testing methods, devices, equipment, storage media and computer program products. Background Art

[0002] Chip testing is an important part of the integrated circuit manufacturing and verification process, which aims to ensure that the produced chips meet the design specifications and can work reliably in the expected application scenarios. At present, the mainstream chip testing solutions in the industry are based on the existing OS (Operating System) code, and different online testing functions are implemented by executing different applications. The applications running on the OS are deeply bound to the OS framework and runtime library, resulting in the inability to test the chip directly on the bare die or verification environment without the OS.

[0003] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0004] The main purpose of this application is to provide a chip testing method, device, equipment, storage medium and computer program product, aiming to solve the technical problem that chip testing cannot be separated from OS and directly tested on a bare chip or in a verification environment.

[0005] To achieve the above objectives, the present application proposes a chip testing method, the method comprising:

[0006] Powering on each core on the chip to be tested and assigning an identification number to each core;

[0007] Determine a main core from the cores, and determine a target subprogram from preset functional subprograms through the main core;

[0008] Allocating each of the target subprograms to a target core in each of the cores through the main core, wherein the target core executes the received target subprogram, performs a self-check after the execution is completed, and returns a self-check result;

[0009] After receiving each of the self-test results through the main core, return to the step of determining the target subroutine from the preset functional subroutines through the main core until each of the cores completes the self-test.

[0010] In one embodiment, before the step of assigning identification numbers to the respective cores, the method further includes:

[0011] Performing anomaly detection on each of the cores respectively to obtain anomaly detection results of each of the cores;

[0012] The step of assigning identification numbers to the respective cores comprises:

[0013] A normal core is determined from among the cores based on each of the abnormality detection results, and an identification number is assigned to each of the normal cores.

[0014] In one embodiment, the step of performing anomaly detection on each of the cores to obtain anomaly detection results for each of the cores includes:

[0015] For any target core among the cores, detecting whether each hardware component of the target core is normal;

[0016] If the hardware components are normal, determining the target core is a normal core;

[0017] If at least one of the hardware components is abnormal, the target core is determined to be an abnormal core.

[0018] In one embodiment, the step of determining the target subprogram from the preset functional subprograms by the main core includes:

[0019] Generate at least one random number based on an assembly random algorithm by the main core;

[0020] A target subprogram whose index value is consistent with the at least one random number is determined from the preset functional subprograms.

[0021] In one embodiment, the step of powering on each core on the chip to be tested includes:

[0022] A temporary main core is determined from the cores on the chip to be tested based on a preset main core selection rule, and the cores are powered on through the temporary main core.

[0023] In one embodiment, before the step of powering on each core on the chip to be tested and assigning an identification number to each core, the method further includes:

[0024] Obtaining a program source file and determining a program entry address in the program source file, and compiling the program source file into a binary file through a compiler;

[0025] In a bare metal test environment, loading the binary file into a dynamic random access memory at a preset program start execution address;

[0026] After the operating system is initialized, the chip to be tested jumps to the program start execution address, and executes the steps of powering on each core on the chip to be tested and assigning identification numbers to each core according to the program code in the dynamic random access memory.

[0027] In addition, to achieve the above-mentioned purpose, the present application also proposes a chip testing device, the chip testing device comprising:

[0028] A power-on module, used to power on each core on the chip to be tested and assign an identification number to each core;

[0029] A determination module, used to determine a main core from the various cores, and determine a target subprogram from preset functional subprograms through the main core;

[0030] an allocation module, used to allocate each of the target subprograms to a target core in each of the cores through the main core, wherein the target core executes the received target subprogram, performs a self-check after the execution is completed, and returns a self-check result;

[0031] The self-check module is used to return to the step of determining the target subroutine from the preset functional subroutines through the main core after receiving each of the self-check results through the main core, until each of the cores completes the self-check.

[0032] In addition, to achieve the above objectives, the present application also proposes a chip testing device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the chip testing method described above.

[0033] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the chip testing method described above are implemented.

[0034] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the chip testing method described above are implemented.

[0035] In the present application, each core on the chip to be tested is powered on, and an identification number is assigned to each core; a main core is determined from the cores, and a target subroutine is determined from preset functional subroutines through the main core; each target subroutine is respectively assigned to a target core in each core through the main core, wherein the target core executes the received target subroutine, performs a self-test after the execution is completed, and returns a self-test result; after receiving each self-test result through the main core, the step of determining the target subroutine from the preset functional subroutine through the main core is returned to execution until the self-test of each core is completed.

[0036] This application avoids dependence on the operating system, its framework and runtime library by assigning the test tasks to a dedicated main core for coordination. Even without an operating system, complex test tasks can be performed, thereby completing the chip self-test without relying on the operating system. In addition, each core only needs to focus on its own test tasks, without having to worry about the status of other cores or the scheduling of the operating system, which simplifies the test process. Through the coordination of the main core, test tasks can be more efficiently assigned and executed, reducing the additional overhead caused by the operating system. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0039] Figure 1 This is a brief flow chart of chip testing based on OS;

[0040] Figure 2 A schematic diagram of a process flow provided for the first embodiment of the chip testing method of the present application;

[0041] Figure 3 A schematic diagram of a process flow provided for the second embodiment of the chip testing method of the present application;

[0042] Figure 4 A schematic diagram of a brief process of a chip testing method provided in one embodiment of the present application;

[0043] Figure 5 This is a schematic diagram of the module structure of the chip testing device according to an embodiment of the present application;

[0044] Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the chip testing method in the embodiment of the present application.

[0045] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0046] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0047] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0048] The main solution of the embodiment of the present application is: power on each core on the chip to be tested, and assign an identification number to each core; determine a main core from the cores, and determine a target subroutine from preset functional subroutines through the main core; assign each of the target subroutines to the target cores in the cores through the main core, wherein the target core executes the received target subroutine, performs self-test after execution and returns the self-test result; after receiving each of the self-test results through the main core, return to execute the step of determining the target subroutine from the preset functional subroutine through the main core until the self-test of each core is completed.

[0049] In this embodiment, for the convenience of description, the following description is made by taking the chip testing device as the execution subject.

[0050] At present, the mainstream online random solutions in the industry are based on the existing OS operating system code, and different online test functions are implemented by executing different applications. Since the OS itself is written in high-level system programming languages ​​such as C / C++, various applications are also written in the same language, or written in other high-level programming languages ​​in the OS. The existing chip test process can be as follows Figure 1 As shown, after the master core is powered on, all slave cores are powered on based on the system configuration and the master core starts the operating system, creates a page table and then executes the application; after all slave cores are successfully powered on, the slave core creates a page table and then executes the application.

[0051] The technical features of the existing solution mainly include the following points:

[0052] (1) Development requires reliance on the OS; the initial configuration of the system requires the participation of the OS.

[0053] (2) They are all based on high-level system programming languages, and the description of functions is more abstract; using high-level languages ​​such as C, C++, and JAVA, system application software with various functions can be developed;

[0054] (3) The development of applications requires a code framework that is compatible with the OS.

[0055] Since the existing solutions are developed based on OS code, they inevitably have the following disadvantages:

[0056] (1) The amount of code is extremely large, which makes code management and team collaboration difficult;

[0057] (2) High-level languages ​​are not friendly to bare chip testing, especially for chips with large processor cores. (I) Although high-level languages ​​have good readability and ease of development, they are usually not as efficient as low-level languages ​​in terms of execution. This is because they need to be converted into machine code by a compiler or interpreter. This conversion process not only increases the execution time, but may also result in efficiency differences due to different compiler optimization strategies. (II) Compared with the ability of low-level languages ​​to directly operate hardware, high-level languages ​​provide weaker hardware control capabilities. This means that the use of high-level languages ​​may encounter limitations in areas involving fine hardware operations, real-time system development, or embedded system programming. (III) Since high-level languages ​​provide many convenient features and abstractions, such as garbage collection and object models, these may lead to additional resource consumption. In resource-constrained environments, such as mobile devices or embedded systems, this additional consumption may become a problem. In particular, the use of memory and processor resources requires more sophisticated optimization to mitigate its impact. (IV) The characteristic of high-level language programming is that the code is highly abstract and relatively concise. This improves the readability and maintainability of the code to a certain extent, but it also causes some problems. When the code logic is complex or there are many problems, the simplicity of high-level languages ​​may cause difficulties for developers, increasing the difficulty of understanding and debugging.

[0058] (3) In the existing solution, applications running on the OS cannot be used directly on the bare chip or in the verification environment. These applications are deeply bound to the framework and runtime library of the OS, so it is impossible to compile these applications separately.

[0059] The present application provides a solution that avoids dependence on the operating system, its framework and runtime library by assigning the test task to a dedicated main core for coordination. Even without an operating system, complex test tasks can be performed, thereby achieving chip self-test without relying on the operating system. In addition, each core only needs to focus on its own test task, without having to care about the status of other cores or the scheduling of the operating system, which simplifies the test process. Through the coordination of the main core, test tasks can be more efficiently assigned and executed, reducing the additional overhead caused by the operating system.

[0060] In addition, compared with the huge amount of code in existing chip testing solutions, this application breaks down the testing tasks into multiple independent functional subroutines and manages them uniformly through the main core. The modular design helps to split large test codes into small, easy-to-manage parts. The main core is responsible for coordinating the execution of each subroutine, making the code structure of the chip test clearer. Each core only needs to focus on its own subroutine, reducing the code complexity faced by a single developer. The preset functional subroutines can be reused by multiple cores, reducing the amount of redundant code and facilitating maintenance and updates. The main core automatically allocates and executes subroutines, reducing the need for manual intervention, thereby reducing the error rate caused by the large amount of code.

[0061] Compared with the low efficiency of OS-based chip testing, the test subroutine in this application can be written in low-level languages ​​​​such as C / C++ to obtain higher execution efficiency. Through static compilation tools, the code can be optimized at the compilation stage to reduce additional overhead at runtime.

[0062] Compared with the weak hardware control capability of OS-based chip testing, the subroutines in this application can be written in assembly language or C / C++ to establish a lightweight hardware abstraction layer, so that high-level languages ​​can call underlying functions to achieve direct control of the hardware.

[0063] Compared with OS-based chip testing that results in additional resource consumption, the test environment of this application only contains necessary libraries and services, which can streamline the test environment and reduce the consumption of memory and processor resources.

[0064] Compared with OS-based chip testing, which may increase the difficulty of understanding and debugging in the face of complex logic, writing unit tests for each subroutine in a low-level language can ensure the correctness of the subroutine function while reducing the difficulty of understanding caused by complex code, and it is also easy to debug.

[0065] The solution provided by this application can not only effectively manage the huge amount of code, but also improve the readability and maintainability of the code without sacrificing test efficiency and hardware control capabilities.

[0066] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a chip testing device, etc. The following takes a chip testing device as an example to illustrate this embodiment and the following embodiments.

[0067] Based on this, the present application embodiment provides a chip testing method, referring to Figure 2 , Figure 2This is a flow chart of the first embodiment of the chip testing method of the present application.

[0068] In this embodiment, the chip testing method includes steps S10 to S40:

[0069] Step S10, powering on each core on the chip to be tested, and assigning an identification number to each core;

[0070] It should be noted that a chip core refers to a processing unit that constitutes a processor in a multi-core processor, and a chip core can independently execute instruction streams. It should be noted that an identification number is a unique number assigned to distinguish different entities (such as chip cores).

[0071] All cores on the chip to be tested are powered on to ensure that all cores can be activated in preparation for subsequent testing and task allocation. At the same time, a unique identification number is assigned to each chip core, which helps to identify and distinguish each core in subsequent steps, and can accurately control and monitor the status of each core, making it easier to manage and debug.

[0072] Specifically, the process of powering on each core on the chip to be tested may include:

[0073] Step S101 : determining a temporary main core from the cores on the chip to be tested based on a preset main core selection rule, and powering on the cores through the temporary main core.

[0074] It should be noted that the temporary main core is the core that is temporarily responsible for certain key operations before the official main core is determined. For example, at the beginning of system startup, the temporary main core can be used to initialize the initial main core of other cores.

[0075] In a multi-core chip, you first need to select one core from all the cores as a temporary main core based on the preset main core selection rules (such as the core's performance indicators, stability, reliability, etc.). The preset main core selection rules can be based on the chip's design parameters or historical test data. The specific rules can be set according to actual needs and are not restricted here.

[0076] Once the temporary master core is determined, it will be responsible for powering up all other cores, which may involve sending control signals or executing specific startup procedures to ensure that all cores can be properly activated.

[0077] It is understandable that using one core to control the power-on process of other cores can simplify the control logic and improve the stability and reliability of the system. Centralized management of the power-on process can reduce repeated operations, save time and resources, and improve overall test efficiency. If a problem occurs during the power-on process, the problem core can be quickly located through the temporary main core, which facilitates fault diagnosis and repair, enhances the stability and security of the system, and lays a solid foundation for subsequent testing and verification work.

[0078] Step S20, determining a main core from the cores, and determining a target subprogram from preset functional subprograms through the main core;

[0079] It should be noted that the main core is a designated core in a multi-core architecture, which is responsible for coordinating and managing the work of other cores. For example, if in a quad-core processor, the first core (identification number 0) is selected as the main core, then it will be responsible for scheduling the tasks of the other three cores.

[0080] A functional subroutine is a program code segment written to complete a specific function. For example, in chip testing, it can be a functional subroutine to check the memory access speed.

[0081] One of the cores is determined as the main core, which can be selected according to a preset standard or algorithm. The specific method is not limited here and can be set according to actual needs. The main core is responsible for selecting a target subroutine from a preset functional subroutine library. The subroutine is a program used to test or execute a specific function.

[0082] By setting up a main core, the task allocation of other cores can be centrally controlled and managed to improve efficiency. Selecting appropriate subroutines can ensure that each core can perform the most optimized tasks and improve overall performance.

[0083] Step S30, allocating each of the target subprograms to a target core in each of the cores through the main core, wherein the target core executes the received target subprogram, performs a self-check after the execution is completed, and returns a self-check result;

[0084] The main core distributes the selected target subprogram to other cores, which are called target cores. Each target core executes the subprogram assigned to it and performs self-check after execution to ensure the correctness of execution.

[0085] The target core executes the received target subroutine, and performs a self-check after the execution is completed and returns a self-check result. The self-check step is a key quality control measure, which can timely discover and correct errors in execution.

[0086] Step S40, after receiving the self-test results of each of the cores, returning to the step of determining the target subprogram from the preset functional subprograms by the core, until each of the cores has completed the self-test.

[0087] The master core collects the self-test results of all target cores and decides whether certain test steps need to be repeated based on these results. If a core fails the self-test, it may be necessary to re-execute the subroutine or perform further diagnosis.

[0088] It can be understood that by collecting and analyzing self-test results, it can be ensured that each core has performed the assigned tasks correctly. Repeating the test steps helps to ensure that all cores can achieve the expected performance standards and improve overall reliability and stability. Through orderly management and control, it is ensured that each core of the multi-core chip can perform tasks efficiently and accurately and perform self-verification, thereby improving the overall performance and reliability of the chip.

[0089] It can be understood that this embodiment avoids dependence on the operating system, its framework and runtime library by assigning the test task to a dedicated main core for coordination, and can execute complex test tasks even without an operating system, thereby achieving chip self-test without relying on the operating system. In addition, each core only needs to focus on its own test task, without having to care about the status of other cores or the scheduling of the operating system, which simplifies the test process. Through the coordination of the main core, the test tasks can be more efficiently assigned and executed, reducing the additional overhead caused by the operating system.

[0090] In a feasible implementation manner, before the step of assigning identification numbers to the respective cores, the step further includes:

[0091] Step A01, performing anomaly detection on each of the cores to obtain anomaly detection results of each of the cores;

[0092] It should be noted that anomaly detection is the process of monitoring whether a system or component is in an unexpected state. Before assigning an identification number to a chip core, each chip core is first subjected to anomaly detection. Anomaly detection may include checking the core's voltage, frequency, temperature, response time and other parameters to determine whether they are within the normal working range. The detection results will provide an anomaly detection result for each core, which indicates whether the core is working normally or has some problems.

[0093] Through early anomaly detection, potential problems with the core can be discovered in time, avoiding wasting resources in subsequent tests and ensuring that only normal cores are used for subsequent tests and operations, thereby improving the accuracy and reliability of the overall test and avoiding allocating resources to abnormal cores, thereby making more efficient use of available resources.

[0094] In this implementation manner, the step S10: the step of assigning identification numbers to the respective cores, comprises:

[0095] Step S102: determining a normal core from the cores based on the abnormality detection results, and assigning an identification number to each of the normal cores.

[0096] After the anomaly detection is completed, the normal cores are determined from all the cores based on the detection results, and identification numbers are assigned to these normal cores. Each core will be assigned a unique identification number to facilitate subsequent management and control.

[0097] By assigning identification numbers to normal cores, each core can be managed and controlled more accurately, ensuring the accuracy of testing and operations. It is ensured that the identification number allocation process only involves normal cores, avoiding ineffective management of abnormal cores and improving overall work efficiency. The identification number of each core helps to quickly identify and track problems during the test process, facilitating fault diagnosis and repair.

[0098] It can be understood that by performing anomaly detection before assigning identification numbers and assigning identification numbers based on these detection results, it can be ensured that only normal cores are included in the subsequent testing process, thereby improving the efficiency and accuracy of the test while optimizing resource utilization and problem handling.

[0099] In a feasible implementation manner, the step A01: performing anomaly detection on each core to obtain anomaly detection results of each core, includes:

[0100] Step A011, for any target core among the cores, detecting whether each hardware component of the target core is normal;

[0101] It should be noted that hardware components are physical parts that make up electronic devices, such as instruction cache, data cache, arithmetic logic unit, etc.

[0102] For any target core in each core of the chip, a detailed hardware component detection is performed, which may specifically include checking each hardware component inside the core (such as logic unit, storage unit, input / output interface, etc.) to ensure that they are all in normal working condition.

[0103] By performing comprehensive anomaly detection on the core, we can ensure that the key hardware components of each core are checked, thereby comprehensively evaluating the health status of the core. Through detection, problems with hardware components can be discovered in a timely manner to prevent these problems from causing larger problems in subsequent tests.

[0104] Step A012, if the hardware components are normal, determining that the target core is a normal core;

[0105] If all detected hardware components are working properly, the target core is marked as a normal core. The normal core has passed the basic hardware health check and can continue with subsequent tests and operations. In this implementation, time and resources can be saved by performing more in-depth tests only on the normal core.

[0106] Step A013: If at least one of the hardware components is abnormal, determine that the target core is an abnormal core.

[0107] If the anomaly detection process for the target core finds that at least one hardware component of the target core is abnormal, the target core is marked as an abnormal core, indicating that the core may require further diagnosis or repair.

[0108] By quickly identifying problematic cores, timely measures can be taken to repair or replace them, preventing the problematic cores from affecting the stability and performance of other cores or the entire system. By excluding abnormal cores, only normal cores are involved in subsequent operations, thereby improving the reliability of the entire system.

[0109] It can be understood that through detailed hardware component detection and classification, it is ensured that only healthy chip cores are used for subsequent testing and operations, thereby improving the accuracy of the test and the stability of the entire system.

[0110] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 3 Step S20: The step of determining the target subprogram from the preset functional subprograms by the main core includes:

[0111] Step S201, generating at least one random number based on an assembly random algorithm by the main core;

[0112] It should be noted that the assembly random algorithm is a random number generation algorithm implemented in assembly language, which can be a true random algorithm or a pseudo-random algorithm. There is no restriction here and it can be set according to actual needs. Random numbers are a set of unpredictable and independent values.

[0113] The main core generates at least one random number using a random number generation algorithm implemented in assembly language, which is usually closer to hardware and has higher execution efficiency. The generated random number is used to subsequently select a target subroutine from a preset functional subroutine, which ensures the randomness and fairness of the selection process.

[0114] It can be understood that by selecting subroutines with random numbers, we can avoid always selecting the same subroutine for testing, thereby testing all subroutines more comprehensively, helping to improve test coverage and ensuring that each subroutine has a chance to be executed and tested. The introduction of random numbers makes the testing process more unpredictable and helps to discover potential occasional errors.

[0115] Step S202: determining a target subprogram whose index value is consistent with the at least one random number from preset functional subprograms.

[0116] It should be noted that the index value is usually used to identify and reference the unique identifier of the subroutine.

[0117] From the preset functional subroutines, search for a subroutine whose index value is consistent with the random number generated by the main core. Once a subroutine whose index value matches the random number is found, it is determined as the target subroutine for subsequent testing and execution.

[0118] Selecting subroutines by matching random numbers to index values ​​ensures that all subroutines have an equal chance of being selected, improves the fairness of the test, simplifies the subroutine selection process, makes the selection mechanism more intuitive and easy to implement, helps to improve the efficiency of the entire testing process, and reduces unnecessary waiting and processing time.

[0119] It can be understood that the method of generating random numbers through the main core and selecting target subroutines based on these random numbers not only improves the randomness and coverage of the test, but also simplifies the selection process and improves the efficiency and fairness of the test. This method helps to more comprehensively evaluate and verify the performance and stability of the chip core.

[0120] In a feasible implementation manner, before the step S10: powering on each core on the chip to be tested and assigning an identification number to each core, the method further includes:

[0121] Step B01, obtaining a program source file and determining a program entry address in the program source file, and compiling the program source file into a binary file through a compiler;

[0122] It should be noted that a program source file is a file containing source code, the original text used by programmers to write programs. The program entry address is the starting location of program execution, that is, the memory address where the first instruction of the program starts to execute. The compiler is a software tool that converts source code into target code or executable files. Binary files are machine code files generated by the compiler that can be directly executed by the computer.

[0123] In this implementation, a source code file containing a test program is first obtained, an entry address of the program is determined in the source code, which is the starting point of program execution, and then a compiler is used to compile the source code file into a binary file.

[0124] Through the compilation process, we ensure that the test program meets the standards and specifications of hardware execution. By compiling the source file into a directly executable binary file, we reduce the time of interpreting the source code on the hardware and improve the execution efficiency. In addition, the compiled binary file is easy to manage and deploy in different environments, which improves the management convenience and efficiency.

[0125] Step B02, in a bare metal test environment, loading the binary file into a dynamic random access memory at a preset program start execution address;

[0126] It should be noted that the bare metal test environment refers to a hardware test environment that does not rely on any operating system. Dynamic random access memory is a type of RAM (Random Access Memory) that needs to be refreshed periodically to prevent data loss. The bare metal test environment is to load binary files directly into the dynamic random access memory without the support of an operating system.

[0127] The binary file is loaded to the pre-set program start execution address, which is the location where the program starts executing on the hardware. By testing in a bare metal environment, you can have more direct control over the hardware and the test process, and you can more accurately control all aspects of the test, including memory management, input and output, etc.

[0128] Step B03, after the operating system is initialized, the chip to be tested jumps to the program start execution address, executes the steps of powering on each core on the chip to be tested according to the program code in the dynamic random access memory, and assigning identification numbers to each core.

[0129] It should be noted that the operating system initialization is the process of starting the operating system and preparing to receive user instructions. After the operating system completes the initialization, ensure that the system environment is stable and ready to execute the test program, the chip to be tested jumps to the starting execution address loaded by the binary file and starts to execute the test program: according to the program code stored in the dynamic random access memory, the chip core is powered on and an identification number is assigned.

[0130] The test is performed after the operating system is initialized to ensure the stability and reliability of the system environment. By jumping to the preset execution address, the test program is ensured to be executed in the predetermined order and process. By loading and executing the test program after the operating system is initialized, the stability of the test environment and the correct execution of the test program are ensured, thereby improving the efficiency and accuracy of chip testing.

[0131] For example, to help understand the implementation process of the chip testing method obtained by combining this embodiment with the above-mentioned embodiment 1, please refer to Figure 4 , Figure 4 A brief schematic diagram of a chip testing method is provided, specifically:

[0132] The specific workflow of this embodiment can be described in the following steps.

[0133] (1) Power on all cores: Use the master core to power on all slave cores (that is, power on all cores on the chip to be tested);

[0134] (2) Starting the identification code remapping of all cores: All cores start working and enter the core identification ID (Identity document, unique identifier) ​​remapping procedure (i.e., assigning identification numbers to the cores);

[0135] (3) Locating the main core after the remapping meeting, the main core is configured with an AP (Application Processor Serial Port) serial port to facilitate the printing and output of test information (i.e., determining the main core from the various cores);

[0136] (4) All processor cores obtain the new core ID;

[0137] (5) The master core starts to execute: the application is randomly controlled, and then the functional subroutine is randomly selected, that is, the master core uses an assembly random algorithm (both true random and pseudo random are supported) to randomly select a number of functional subroutines and randomly assign these selected subroutines to the processor core that has obtained the new core ID; the slave core starts to execute: randomly selects a functional subroutine; then checks the functional program assignment, if it is a subroutine that has been assigned (to the slave core), then enters step (6); if it is a subroutine that has not been assigned (to the slave core), then after the system is restored, the loop returns, waits for the global flag, and executes step (5) (that is, the master core determines the target subroutine from the preset functional subroutines; the master core assigns each of the target subroutines to the target core in each of the cores);

[0138] (6) executing the functional subprogram, and performing a program function self-check after the execution is completed (that is, the target core executes the received target subprogram, and performs a self-check after the execution is completed and returns the self-check result);

[0139] (7) returning to step (5) to continue execution (i.e., after receiving the self-test results of each of the cores, returning to the step of determining the target subroutine from the preset functional subroutines by the main core until each of the cores completes the self-test);

[0140] The specific implementation process of this embodiment can be described as the following steps:

[0141] (1) Prepare the subject control framework;

[0142] (2) Write various functional subroutine modules;

[0143] (3) Setting a program entry address, and using the tool chain to compile binary files .elf and .bin files (that is, obtaining a program source file and determining the program entry address in the program source file, and compiling the program source file into a binary file through a compiler);

[0144] (4) On the design verification platform, the hardware design is executed starting from the specified program entry;

[0145] (5) In a bare metal test environment, the bin file is directly loaded (downloaded) into the DDR (Double Data Rate Memory) storage at the specified address, and the OS is allowed to switch to the chip initial execution state after initializing the system, and then directly start execution from the specified entry address (that is, in a bare metal test environment, the binary file is loaded into the dynamic random access memory at the preset program start execution address; after the operating system initialization is completed, the chip to be tested jumps to the program start execution address, and executes the steps of powering on each core on the chip to be tested and assigning an identification number to each core according to the program code in the dynamic random access memory).

[0146] Since there is no need to change any main program code, the elf file running on the design verification platform and the bin file running on the bare chip test platform are of the same origin. If the same pseudo-random number seed is used for both, it is very convenient to put the problems encountered in the bare chip test on the design verification platform for reproduction, and then further find possible bugs in the hardware design (errors or defects in the software or hardware system).

[0147] The embodiments of the present application have the following technical features:

[0148] (1) This embodiment is written in assembly language, does not rely on any framework structure and runtime library of OS code, and has a small amount of code;

[0149] (2) Each functional module of this embodiment is independently developed using assembly language; the instruction sequence for operating the hardware is strictly executed according to the assembly language design, which is more direct and efficient; for personnel involved in design verification, the test hardware is clearer and easier to understand.

[0150] (3) Seamlessly support cross-socket (Socket Connection) testing requirements for large chip systems;

[0151] (4) The test time is controllable, and a certain number of cycles can be set to control the test time;

[0152] (5) The code of this embodiment can be directly run in a design verification environment or in a bare chip test environment.

[0153] In the embodiment of the present application, chip development must go through two stages: design verification and chip testing. In order to perform design verification, the verification engineer will design a series of test cases based on each functional point in the design Spec (Specification). Bare metal test needs to cover as many functions of the chip as possible; since some third-party IPs are used in the design of the chip, the test points related to these IPs (Intellectual Property) are greater than the functional points in the relevant tests in the design verification stage. Therefore, the bare metal test requires a larger amount of tests. In this case, reusing the existing tests in the design verification stage can greatly improve the test efficiency. In addition, the online random program developed in assembly language can directly operate hardware control and memory access, which can be more convenient and direct for bare metal stress testing.

[0154] It should be noted that, in a specific implementation, C / C++ language can be used to replace assembly language development, and assembly code blocks can be nested in C / C++; when the CPU (Central Processing Unit) core is purchased from a third party, most test case (test case) programs verified at the SOC (System on Chip) level can use the framework and process control method of this embodiment. In addition, some functions that control more complex functions can be developed in C / C++, and the functions developed in C / C++ can be called using assembly language, and the framework and process control method of this embodiment can also be used.

[0155] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the chip testing method of the present application. More simple transformations based on this technical concept are all within the protection scope of the present application.

[0156] This application also provides a chip testing device, please refer to Figure 5 , the chip testing device comprises:

[0157] A power-on module 10 is used to power on each core on the chip to be tested and assign an identification number to each core;

[0158] A determination module 20, configured to determine a main core from the cores, and determine a target subprogram from preset functional subprograms through the main core;

[0159] The allocation module 30 is used to allocate each of the target subprograms to a target core in each of the cores through the main core, wherein the target core executes the received target subprogram, performs a self-check after the execution is completed, and returns a self-check result;

[0160] The self-check module 40 is used to return to the step of determining the target subroutine from the preset functional subroutines through the main core after receiving each of the self-check results through the main core, until each of the cores completes the self-check.

[0161] Optionally, the device includes an anomaly detection module, configured to:

[0162] Performing anomaly detection on each of the cores respectively to obtain anomaly detection results of each of the cores;

[0163] The power-on module 10 is also used for:

[0164] A normal core is determined from among the cores based on each of the abnormality detection results, and an identification number is assigned to each of the normal cores.

[0165] Optionally, the anomaly detection module is further used to:

[0166] For any target core among the cores, detecting whether each hardware component of the target core is normal;

[0167] If the hardware components are normal, determining the target core is a normal core;

[0168] If at least one of the hardware components is abnormal, the target core is determined to be an abnormal core.

[0169] Optionally, the determining module 20 is further configured to:

[0170] Generate at least one random number based on an assembly random algorithm by the main core;

[0171] A target subprogram whose index value is consistent with the at least one random number is determined from the preset functional subprograms.

[0172] Optionally, the power-on module 10 is further used for:

[0173] A temporary main core is determined from the cores on the chip to be tested based on a preset main core selection rule, and the cores are powered on through the temporary main core.

[0174] Optionally, the device further comprises a compilation file for:

[0175] Obtaining a program source file and determining a program entry address in the program source file, and compiling the program source file into a binary file through a compiler;

[0176] In a bare metal test environment, loading the binary file into a dynamic random access memory at a preset program start execution address;

[0177] After the operating system is initialized, the chip to be tested jumps to the program start execution address, and executes the steps of powering on each core on the chip to be tested and assigning identification numbers to each core according to the program code in the dynamic random access memory.

[0178] The chip testing device provided by the present application adopts the chip testing method in the above embodiment, which can solve the technical problem that chip testing cannot be directly tested on a bare die or in a verification environment without being separated from the OS. Compared with the prior art, the beneficial effects of the chip testing device provided by the present application are the same as the beneficial effects of the chip testing method provided by the above embodiment, and other technical features in the chip testing device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0179] The present application provides a chip testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the chip testing method in the above-mentioned embodiment one.

[0180] Reference below Figure 6 , which shows a schematic diagram of the structure of a chip test device suitable for implementing the embodiment of the present application. The chip test device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6The chip testing device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0181] like Figure 6 As shown, the chip test equipment may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the chip test equipment are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the chip test device to communicate with other devices wirelessly or wired to exchange data. Although the chip test device with various systems is shown in the figure, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0182] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0183] The chip testing device provided by the present application adopts the chip testing method in the above embodiment, which can solve the technical problem that chip testing cannot be directly tested on a bare die or in a verification environment without being separated from the OS. Compared with the prior art, the beneficial effects of the chip testing device provided by the present application are the same as the beneficial effects of the chip testing method provided by the above embodiment, and the other technical features in the chip testing device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

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

[0185] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0186] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the chip testing method in the above-mentioned embodiment.

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

[0188] The computer-readable storage medium may be included in the chip testing device; or may exist independently without being assembled into the chip testing device.

[0189] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the chip testing equipment, the chip testing equipment: powers on each core on the chip to be tested and assigns an identification number to each core; determines a main core from the cores, and determines a target subroutine from a preset functional subroutine through the main core; allocates each of the target subprograms to a target core among the cores through the main core, wherein the target core executes the received target subprogram, performs self-test after the execution is completed, and returns the self-test result; after receiving each of the self-test results through the main core, returns to the step of determining the target subprogram from the preset functional subprogram through the main core until the self-test of each of the cores is completed.

[0190] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0191] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0192] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0193] The readable storage medium provided in the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned chip testing method, and can solve the technical problem that chip testing cannot be directly tested on a bare die or in a verification environment without being separated from the OS. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in the present application are the same as the beneficial effects of the chip testing method provided in the above-mentioned embodiment, and will not be elaborated here.

[0194] The present application also provides a computer program product, including a computer program, which implements the steps of the chip testing method as described above when executed by a processor.

[0195] The computer program product provided by the present application can solve the technical problem that chip testing cannot be directly tested on a bare chip or in a verification environment without being separated from the OS. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the chip testing method provided by the above embodiment, and will not be elaborated here.

[0196] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A chip testing method, characterized in that: The chip testing method comprises: Powering on each core on the chip to be tested and assigning an identification number to each core; Determine a main core from the cores, and determine a target subprogram from preset functional subprograms through the main core; Allocating each of the target subprograms to a target core in each of the cores through the main core, wherein the target core executes the received target subprogram, performs a self-check after the execution is completed, and returns a self-check result; After receiving each of the self-test results through the main core, return to the step of determining the target subroutine from the preset functional subroutines through the main core until each of the cores completes the self-test.

2. The chip testing method according to claim 1, characterized in that: Before the step of assigning identification numbers to the respective cores, the method further includes: Performing anomaly detection on each of the cores respectively to obtain anomaly detection results of each of the cores; The step of assigning identification numbers to the respective cores comprises: A normal core is determined from among the cores based on each of the abnormality detection results, and an identification number is assigned to each of the normal cores.

3. The chip testing method according to claim 2, characterized in that: The step of performing anomaly detection on each of the cores to obtain anomaly detection results for each of the cores comprises: For any target core among the cores, detecting whether each hardware component of the target core is normal; If the hardware components are normal, determining the target core is a normal core; If at least one hardware component among the hardware components is abnormal, the target core is determined to be an abnormal core.

4. The chip testing method according to claim 1, characterized in that: The step of determining the target subprogram from the preset functional subprograms by the main core includes: Generate at least one random number based on an assembly random algorithm by the main core; A target subprogram whose index value is consistent with the at least one random number is determined from the preset functional subprograms.

5. The chip testing method according to claim 1, characterized in that: The step of powering on each core on the chip to be tested includes: A temporary main core is determined from the cores on the chip to be tested based on a preset main core selection rule, and the cores are powered on through the temporary main core.

6. The chip testing method according to any one of claims 1 to 5, characterized in that: Before the step of powering on each core on the chip to be tested and assigning an identification number to each core, the method further includes: Obtaining a program source file and determining a program entry address in the program source file, and compiling the program source file into a binary file through a compiler; In a bare metal test environment, loading the binary file into a dynamic random access memory at a preset program start execution address; After the operating system is initialized, the chip to be tested jumps to the program start execution address, and executes the steps of powering on each core on the chip to be tested and assigning identification numbers to each core according to the program code in the dynamic random access memory.

7. A chip testing device, characterized in that: The chip testing device comprises: A power-on module, used to power on each core on the chip to be tested and assign an identification number to each core; A determination module, used to determine a main core from the various cores, and determine a target subprogram from preset functional subprograms through the main core; an allocation module, used to allocate each of the target subprograms to a target core in each of the cores through the main core, wherein the target core executes the received target subprogram, performs a self-check after the execution is completed, and returns a self-check result; The self-check module is used to return to the step of determining the target subroutine from the preset functional subroutines through the main core after receiving each of the self-check results through the main core, until each of the cores completes the self-check.

8. A chip testing device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the chip testing method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the chip testing method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the chip testing method according to any one of claims 1 to 6 are implemented.

Images