Tof chip parallel test method, system, terminal device and storage medium

Abstract

The application is suitable for the field of TOF chip automatic testing technology, and provides a TOF chip parallel testing method, a system, terminal equipment and a storage medium, which comprises a TOF chip parallel testing system, the TOF chip parallel testing system comprises a testing device, a control device and a plurality of station Raspberry Pis; the control device synchronously issues a batch testing task to the testing device and all station Raspberry Pis; after the testing device receives the batch testing task, hardware electrical property detection is synchronously performed on all TOF chip testing stations, and a hardware detection result is obtained; after the station Raspberry Pis receive the batch testing task, and after receiving a performance detection starting instruction sent by the control device, performance verification is synchronously performed on the TOF chips that pass the hardware detection, and a performance verification result is obtained. The above method can avoid the calculation power bottleneck of the testing device, and effectively improve the overall TOF chip testing efficiency.

Description

Technical Field

[0001] This application belongs to the field of automated testing technology for TOF chips, and particularly relates to parallel testing methods, systems, terminal equipment and storage media for TOF chips. Background Technology

[0002] Currently, Time of Flight (TOF) chips are widely used in robotics, AR, autonomous driving and other fields. The industry generally uses the Chroma3380P tester to build a wafer CP test platform. Although it can perform parallel hardware testing of DC parameters, registers and basic functions, the existing centralized architecture has to hand over all the massive raw data of dark and bright fields output by the chip to the test machine for unified calculation. This can easily cause overload of the host computing power and transmission lag, limiting the expansion of workstations and testing efficiency, thus resulting in a significant reduction in the testing efficiency of TOF chips. Summary of the Invention

[0003] This application provides a parallel testing method, system, terminal device, and storage medium for TOF chips, which can avoid the bottleneck of computing power in testing equipment and effectively improve the overall testing efficiency of TOF chips.

[0004] In a first aspect, embodiments of this application provide a parallel testing method for a TOF chip, applied to a parallel testing system for a TOF chip. The parallel testing system for a TOF chip includes a test device, a control device, and multiple Raspberry Pi workstations; wherein, one Raspberry Pi workstation corresponds to one TOF chip testing workstation; the control device communicates with both the test device and the Raspberry Pi workstations; the test device communicates with the Raspberry Pi workstations. The control equipment synchronously sends batch test tasks to the test equipment and all Raspberry Pis at the workstations; After receiving the batch test task, the test equipment performs hardware electrical tests on all TOF chip test stations simultaneously to obtain the hardware test results. After the Raspberry Pi at the workstation receives the batch test task and receives the performance test start command sent by the control device, it synchronously performs performance verification on the TOF chip that has passed the hardware test and obtains the performance verification results.

[0005] In this embodiment, the entire system consists of testing equipment, control equipment, and multi-station Raspberry Pis. Each Raspberry Pi corresponds to a single testing station. The control equipment communicates with both the testing machine and the Raspberry Pis, and the testing machine and Raspberry Pis interact bidirectionally. When testing starts, the control equipment sends the same batch of test tasks to the testing machine and all station Raspberry Pis. The testing equipment synchronously completes the hardware electrical testing of all station chips and outputs hardware test data. After receiving the task and the performance test start command from the control equipment, each station Raspberry Pi synchronously performs multi-scenario optical performance calculation verification only for chips with qualified hardware electrical properties, generating corresponding performance verification results. In this application, the hardware electrical testing and power control are handled by the testing equipment, while data acquisition, preprocessing, and multi-scene ranging algorithm calculations are split and executed independently in parallel on a dedicated Raspberry Pi at each workstation. The computing power is distributed and shared, and the performance verification of each workstation does not compete for resources. If the testing equipment is used to process the massive amount of raw sampling data of multiple chips in bright and dark fields and the calculation of different scene algorithms at the same time, the limited computing power of a single device will result in queuing and waiting at multiple workstations and stuttering delays in serial calculations. Therefore, this application avoids the performance testing bottleneck caused by insufficient computing power of the testing equipment by adding independent Raspberry Pis at each workstation to share the optical algorithm calculation tasks, and significantly improves the overall throughput efficiency of the parallel testing of the entire batch of TOF chips.

[0006] In one possible implementation of the first aspect, the TOF chip parallel testing system also includes multiple differentiated optical reflection devices; wherein, one differentiated optical reflection device is used to construct a differentiated optical scene; the control device synchronously issues batch test tasks to the test equipment and all Raspberry Pis at the workstations, including: The control device receives multiple differentiated scene algorithms and configuration parameters uploaded by the user through an encrypted interface; among them, the configuration parameters include the differentiated optical scene bound to the differentiated scene algorithm, the TOF chip test station, and the Raspberry Pi information of the station; After the control device receives multiple differentiated scenario algorithms uploaded by the user, it verifies the multiple differentiated scenario algorithms according to the configuration parameters and obtains the verification results. After the verification result indicates that the verification has passed, the control device synchronously sends batch test tasks to the test device and all Raspberry Pis at the workstations.

[0007] In this embodiment, by controlling the device to pre-verify the differentiated algorithm parameters of the binding workstation and optical scene and uniformly distribute test tasks, test failures caused by the mismatch between the algorithm and the optical scene and workstation can be avoided. At the same time, distributed computing and overcoming the computing power bottleneck of the test machine can ensure the stable and efficient parallel testing of multi-workstation TOF chips.

[0008] In one possible implementation of the first aspect, the method further includes: The testing equipment filters out unqualified TOF chips based on the hardware test results and marks the unqualified TOF chips. The testing equipment selects qualified TOF chips based on the hardware test results and sends a start trigger signal to the control equipment to perform performance testing on the qualified TOF chips. After receiving the start trigger signal, the control device sends a performance test start command for the qualified TOF chip to the Raspberry Pi at the workstation.

[0009] In this embodiment, faulty chips are first screened out before optical performance testing is triggered, and performance testing instructions are only issued to electrically qualified chips. This reduces the amount of invalid algorithm computation, lowers the computing power consumption of the Raspberry Pi, and further improves the overall parallel testing efficiency.

[0010] In one possible implementation of the first aspect, the workstation Raspberry Pi party simultaneously performs performance verification on the TOF chip that has passed hardware testing, and obtains the performance verification results, including: The Raspberry Pi at the workstation controls the TOF chips at all TOF chip testing workstations to collect raw sampling data under their respective differentiated optical scenarios; The Raspberry Pi at the workstation acquires the raw sampling data and preprocesses it to obtain the preprocessed raw sampling data. The Raspberry Pi at the workstation performs performance verification on the TOF chip that has passed hardware testing based on the pre-processed raw sampling data, and obtains the performance verification results.

[0011] In this embodiment, each Raspberry Pi independently completes data acquisition, preprocessing, and performance algorithm calculation in a dedicated and differentiated optical environment, distributing computing power to avoid the computing power bottleneck of the Chroma test machine, enabling multi-station synchronous parallel testing, and significantly improving the batch testing efficiency of TOF chips.

[0012] In one possible implementation of the first aspect, the batch testing task includes a differentiated scenario algorithm; the workstation Raspberry Pi synchronously performs performance verification on the TOF chip that has passed hardware testing based on the preprocessed raw sampled data, and obtains the performance verification results, including: The Raspberry Pi at the workstation loads the corresponding differentiated scenario algorithms from the batch test tasks; The Raspberry Pi at the workstation runs differentiated scenario algorithms based on the preprocessed raw sampled data and outputs performance verification results.

[0013] In this embodiment, the Raspberry Pi at the workstation directly loads the differentiated scene algorithm that matches the optical scene of the workstation and is uniformly issued by MES for independent operation, realizing distributed computing power allocation, eliminating the computing power bottleneck of the Chroma test machine, and enabling synchronous parallel operation at multiple workstations, effectively improving the overall efficiency of batch performance testing of TOF chips.

[0014] In one possible implementation of the first aspect, the method further includes: The Raspberry Pi at the workstation sends the performance verification results to the testing equipment. The testing equipment will send the hardware test results and performance verification results to the control equipment; After receiving the hardware test results and performance verification results, the control device generates a test report based on the hardware test results and performance verification results.

[0015] In this embodiment, hardware and performance test data are aggregated at each level along the entire chain and a complete test report is generated uniformly by the control equipment. This enables the chip's electrical and optical performance data to be bound and collected one by one, ensuring data integrity and traceability. At the same time, the layered transmission distributes data pressure and ensures stable and smooth data transmission for multi-station parallel testing.

[0016] Secondly, embodiments of this application provide a TOF chip parallel testing system, comprising: a control device, a testing device, multiple Raspberry Pi workstations, and multiple TOF chip testing workstations; the TOF chip parallel testing system is used to implement the TOF chip parallel testing method as described in any of the first aspects above.

[0017] In one possible implementation of the second aspect, the TOF chip parallel testing system also includes multiple differentiated scene reflection devices; wherein, the differentiated scene reflection devices are used to construct differentiated optical scenes.

[0018] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the TOF chip parallel testing method as described in any of the first aspects above.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the TOF chip parallel testing method as described in any of the first aspects above.

[0020] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the TOF chip parallel testing method of any one of the first aspects described above.

[0021] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of a parallel testing system for a TOF chip provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a parallel testing method for a TOF chip provided in an embodiment of this application. Figure 3 This is a schematic diagram of a parallel testing system for a TOF chip provided in another embodiment of this application; Figure 4 This is a schematic diagram of the process for issuing batch test tasks according to an embodiment of this application; Figure 5 This is a schematic diagram of the chip screening process provided in an embodiment of this application; Figure 6 This is a schematic diagram of the performance verification process provided in one embodiment of this application; Figure 7 This is a schematic diagram of the performance verification process provided in another embodiment of this application; Figure 8 This is a schematic flowchart illustrating the feedback detection results provided in one embodiment of this application; Figure 9 This is a schematic diagram of the overall architecture of a parallel testing system for TOF chips provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation

[0024] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0025] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0026] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0027] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0028] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0029] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0030] When TOF chips are widely used in fields such as robotics, AR, and autonomous driving, the industry generally uses the Chroma 3380P tester to build a wafer CP test platform. Although it can perform parallel hardware testing of DC parameters, registers, and basic functions, the existing centralized architecture entrusts all the massive amounts of raw data from the chip's dark and bright fields to the test machine for unified processing. This can easily cause overload of the host computing power and transmission lag, limiting the expansion of workstations and testing efficiency, thus resulting in a significant reduction in the testing efficiency of TOF chips.

[0031] To address the aforementioned technical challenges, this application provides a parallel testing method and system for TOF chips. Based on a Chroma 3380P tester, a wafer-level circuit probing (CP) platform is built. Each test station is configured with an independent Raspberry Pi edge computing node, constructing a distributed edge processing + Manufacturing Execution System (MES) centralized management two-layer architecture. A layered testing mode is adopted, characterized by a unified hardware foundation testing environment across all stations and differentiated algorithm verification scenarios for each station. The MES serves as the sole entry point for algorithm distribution and data aggregation, achieving permission isolation and security control. Edge nodes locally complete the preprocessing of massive bright and dark field test data for TOF and the calculation of ranging algorithms. This not only solves the problems of test machine computing power lag and limited parallel expansion caused by traditional centralized processing, but also enables simultaneous completion of dToF / iToF chip DC (Direct Current) tests in the same batch of mass production testing. Standardized selection of good products for Curren (DC) parameters, register communication, hardware functions, etc., and robustness verification of algorithms in multiple scenarios such as multiple reflectivities, different illuminations, and multiple ranging distances, clarify the division of labor between testing plants and customers, balance testing efficiency, algorithm iteration flexibility and mass production security, shorten chip R&D cycle, fully reuse multi-station hardware resources, and reduce overall testing and R&D operation costs.

[0032] See Figure 1 This is a schematic diagram of a parallel testing system for TOF chips provided in an embodiment of this application, including testing equipment, control equipment, and multiple Raspberry Pi workstations; wherein, one Raspberry Pi workstation corresponds to one TOF chip testing workstation; the control equipment communicates with both the testing equipment and the Raspberry Pi workstations; the testing equipment communicates with the Raspberry Pi workstations.

[0033] In this embodiment, the test equipment in the TOF chip parallel test system can be a Chroma3380P tester, responsible for the unified mass production test of chip hardware DC parameters, registers, and basic functions; the control equipment can be a MES, which globally and uniformly manages all tasks, algorithms, data, and permissions; each test station is equipped with a dedicated Raspberry Pi edge computing node, bound one-to-one, with one Raspberry Pi dedicated to each station, independently processing the raw test data of the chip at that station and running the ranging algorithm.

[0034] Each workstation Raspberry Pi is paired with a test workstation. The MES control terminal connects to both the test machine and all Raspberry Pis. The test machine can also interact directly with each workstation Raspberry Pi, forming a complete communication link for global MES control, unified hardware testing by the test machine, and local data processing by each Raspberry Pi at its own workstation.

[0035] Each workstation has its own dedicated Raspberry Pi edge computing node, which communicates one-to-one with the TOF chip under test at its corresponding workstation via a General Purpose Input Output (GPIO), Serial Peripheral Interface (SPI), or IIC interface. This node independently handles data acquisition, preprocessing, and local algorithm execution for its single workstation chip, enabling on-site processing and load balancing of massive amounts of test data. The MES system, acting as the global control hub, establishes bidirectional communication via Ethernet with all Raspberry Pi edge nodes, the Chroma 3380P test machine, and the client server. It is designated as the sole entry point for algorithm distribution, the node for issuing test tasks, and the central node for collecting and relaying test data, achieving unified management and control of data, algorithms, and tasks across the entire system.

[0036] The MES system builds a customer operation channel based on a standardized RESTful API interface, supporting customers to independently upload algorithm packages, configure algorithm parameters, and specify the corresponding test workstations and production batches for each algorithm. As the sole algorithm entry point, the MES system performs version registration, permission classification, and security verification on all uploaded algorithms, intercepting illegal and abnormal algorithm programs. After verification, the corresponding algorithm is precisely pushed to the edge nodes of the designated workstations as needed, achieving a balance between flexible algorithm iteration and production safety control. Furthermore, it pre-stores a differentiated scenario parameter library for each test workstation, including core parameters such as light tube reflectivity, background light intensity, ranging calibration values, and reflective target material. Based on customer algorithm verification needs, it binds fixed, differentiated environmental attributes for each workstation, matching corresponding algorithm parameters and sending them to the edge nodes, realizing a differentiated verification logic of "fixed workstation scenarios and precise algorithm adaptation." It also centrally receives test data uploaded from all workstation edge nodes, completing unified classification and storage, preliminary data analysis, and abnormal data screening. On one hand, it outputs hardware test pass / fail criteria to the Chroma 3380P test machine; on the other hand, it simultaneously forwards complete test data and algorithm verification results to the customer's server, achieving bidirectional empowerment of test data.

[0037] In addition, this system provides a probe station, which adopts the UF200 model, and is equipped with a customized 8-station dedicated probe card to meet the requirements of wafer-level multi-chip synchronous contact testing; the Chroma 3380P tester establishes high-speed communication with the probe station through the MXBUS bus to uniformly manage the hardware test process and parameters of all stations.

[0038] Each test station is independently configured with one Raspberry Pi 4B (8GB version) edge computing node, which interacts with the TOF chip under test at high speed through the SPI interface and precisely controls the chip's power supply and reset operations through the GPIO interface, realizing independent data processing and algorithm control for each station.

[0039] All Raspberry Pi edge nodes are connected to the factory LAN via gigabit Ethernet switches, establishing a stable long-term connection with the MES system to ensure the real-time performance and stability of algorithm delivery and data upload.

[0040] See Figure 2 This is a flowchart illustrating a parallel testing method for a TOF chip provided in an embodiment of this application. It is intended as an example and not a limitation. The method may include the following steps: S101, the control device synchronously sends batch test tasks to the test equipment and all Raspberry Pis at the workstations.

[0041] In this embodiment, the MES (control device), which serves as the control center, sends a complete set of test instructions corresponding to the same batch of wafers to the Chroma test machine (test device) and the Raspberry Pi edge nodes of each workstation after all pre-test configurations are completed. This unifies the test sequence of all devices. The test machine receives the standardized hardware test process, and each Raspberry Pi receives the exclusive scenario parameters and verification algorithms to carry out hardware testing and multi-scenario algorithm verification.

[0042] In another embodiment, see Figure 3 This is a schematic diagram of a parallel testing system for a TOF chip provided in another embodiment of this application. The parallel testing system for a TOF chip also includes multiple differentiated optical reflection devices; wherein, one differentiated optical reflection device is used to construct a differentiated optical scene.

[0043] In this embodiment of the application, the TOF parallel testing system is additionally equipped with multiple sets of differentiated optical reflection devices. Each device can build a unique optical testing environment. Different devices provide different lighting conditions such as reflectivity, background light, and reflective target material, allowing each workstation to conduct multi-scenario algorithm verification simultaneously.

[0044] For example, it can be paired with different devices such as standard light tubes with different reflectivities of 10%, 30%, 50%, 70%, and 90%, strong light background light sources, and long-distance special reflective targets to build different optical test environments such as low reflection, conventional, high reflection, outdoor strong light, and long-distance ranging. Each workstation can be equipped with the corresponding device to simultaneously complete the verification of the TOF ranging algorithm under multiple working conditions.

[0045] In one embodiment, see Figure 4 This is a schematic diagram of the process for issuing batch test tasks according to an embodiment of this application, as shown below. Figure 4 As shown, step S101 includes: S201, the test equipment receives multiple differentiated scene algorithms and configuration parameters uploaded by the user through an encrypted interface; among them, the configuration parameters include the differentiated optical scene bound to the differentiated scene algorithm, the TOF chip test station and the station Raspberry Pi information.

[0046] In this embodiment of the application, before issuing batch test tasks, the algorithm upload and binding configuration work must be completed. That is, MES relies on the encrypted security interface to receive multiple sets of algorithms and supporting configuration parameters adapted to different optical environments uploaded by the customer. The configuration parameters predefine the optical test scene, test station and Raspberry Pi corresponding to each set of algorithms, and establish the binding relationship between algorithm, scene, station and edge node.

[0047] For example, customers can upload multiple sets of differentiated scenario algorithms adapted to different working conditions such as low reflection, strong light, and long distance through the MES's encrypted HTTPS interface, and fill in the corresponding configuration parameters. The parameters clearly indicate the differentiated optical reflection device, target test station, and corresponding Raspberry Pi bound to each algorithm. For example, while the hardware electrical and mechanical testing environments are completely unified across 8 workstations, algorithm verification scenarios are configured differently: workstations 1-5 are configured with standard light tubes with gradient reflectivity of 10%, 30%, 50%, 70%, and 90% respectively, to verify the ranging performance of the algorithm under different reflective media; workstation 6 is configured with an adjustable high-brightness background light source to simulate complex outdoor strong light conditions; workstation 7 is configured with a dedicated reflective target with a fixed calibration distance of 2 meters to verify the accuracy of long-distance ranging algorithms; workstation 8 is set as a standard control workstation, configured with a 50% reflectivity light tube and a conventional indoor standard environment for data comparison and reference. The algorithm adapted to the 10% low reflectivity light tube scenario is bound to workstation 1 and run by the Raspberry Pi at workstation 1, while the algorithm adapted to the outdoor strong light scenario is bound to workstation 6 and run by the Raspberry Pi at workstation 6.

[0048] S202: After the control device receives multiple differentiated scenario algorithms uploaded by the user, it performs verification processing on the multiple differentiated scenario algorithms according to the configuration parameters and obtains the verification results.

[0049] In this embodiment of the application, after receiving various algorithm files uploaded by the customer that are adapted to different optical scenarios, MES will read the corresponding configuration parameters, perform security and compliance verification on all algorithms, and generate corresponding verification results.

[0050] For example, MES reads the differentiated scene algorithms, optical scenes, workstations, and Raspberry Pi binding information recorded in the configuration parameters. It then performs program security scanning, version information verification, and parameter matching detection on each differentiated scene algorithm in turn, checking for anomalies such as illegal scripts, missing parameters, and scene-algorithm mismatch. After all the tests are completed, a complete verification result including the reasons for passing / failing is generated. If the verification is successful, the algorithm is saved and awaits distribution. If the verification fails, the abnormal information is reported to the customer, and the algorithm cannot enter the subsequent test task distribution process.

[0051] S203: After the verification result indicates that the verification has passed, the control device synchronously sends batch test tasks to the test device and all Raspberry Pis at the workstations.

[0052] In this embodiment of the application, after the MES system completes algorithm security verification, version registration and confirms that there are no problems, it will simultaneously push the entire batch test task to the Chroma test machine and all Raspberry Pis at the workstations, in preparation for starting the chip parallel test.

[0053] For example, assuming all verification results show that the verification is passed, MES integrates a unified hardware testing process, dedicated optical scene parameters for each workstation, and matching differentiated algorithms. Then, through the communication link, it simultaneously sends standardized hardware testing instructions such as DC parameters and register detection to the Chroma test machine, and sends the corresponding scene configuration and matching algorithm package to each Raspberry Pi at each workstation, completing the task distribution of all devices at once and unifying the test start sequence of all workstations.

[0054] In the above method, by controlling the equipment to pre-verify the differentiated algorithm parameters of the binding station and optical scene and uniformly distribute the test tasks, it is possible to avoid test failure caused by the mismatch between the algorithm and the optical scene and station. At the same time, the distributed computing power bottleneck of the test machine is broken through, ensuring the stable and efficient parallel testing of multi-station TOF chips.

[0055] S102, after receiving the batch test task, the test equipment synchronously performs hardware electrical tests on all TOF chip test stations and obtains the hardware test results.

[0056] In this embodiment, after receiving the batch test task issued by the MES, the Chroma tester will simultaneously start the electrical performance test of the TOF chip at all test stations, collect various electrical indicators, and finally output the hardware test results that distinguish the good and bad of the chip hardware.

[0057] For example, the Chroma tester parses the unified hardware testing standards and timing instructions in the batch testing task, synchronously drives all station probes to contact the TOF chip under test, and performs DC parameter testing such as OS testing and Leakage testing in parallel, as well as register communication function verification; then, it synchronously sends calibration instructions to each station Raspberry Pi node, and the edge node independently controls the chip to complete the binary method parameter calibration, the calibration parameters are burned into the chip body, and the calibration results are sent back to the tester; finally, it completes the basic TOF function test under the standard chip environment, accurately screening out good and bad hardware products.

[0058] For example, standard test voltages are applied simultaneously to the TOF chips installed at workstations 1 to 8, and the power supply current and signal pin conduction status data of each chip are collected simultaneously. After all electrical items at all workstations have been tested, the equipment compares the measured values ​​with the preset pass thresholds and generates a complete hardware test result that includes the chip number of each workstation, the measured values ​​of each electrical item, and the hardware pass / fail judgment.

[0059] In one embodiment, see Figure 5 This is a schematic diagram of a chip screening process provided in an embodiment of this application, as shown below. Figure 5 As shown, it includes: S301, the testing equipment screens out unqualified TOF chips based on the hardware test results and marks the unqualified TOF chips.

[0060] In this embodiment, the Chroma testing machine compares the electrical test data with the pass standard to screen out TOF chips with substandard parameters, and at the same time marks these faulty chips to facilitate subsequent sorting and removal.

[0061] For example, the Chroma tester retrieves the preset electrical thresholds within the batch test task and compares them one by one with the hardware test data of each chip at each station. If any of the following indicators—exceeding the standard range: leakage current exceeding the standard, register communication failure, or power supply short circuit—is exceeded, the chip is judged as unqualified. The station number and fault type of the chip are recorded and marked simultaneously. For example, if the static current of the TOF chip at station 3 exceeds the upper limit and the chip at station 7 has a short circuit in the power supply pin, the equipment will mark the two chips with the corresponding fault codes and save the marking information to be uploaded to the MES for subsequent probe station sorting and collection of defective products.

[0062] S302, the testing equipment selects qualified TOF chips based on the hardware test results and sends a start trigger signal to the MES to perform performance testing on the qualified TOF chips.

[0063] In this embodiment, the Chroma tester selects TOF chips that meet the standards based on electrical test data, and then sends a trigger signal to MESMES to notify the system to start the optical ranging performance test process for qualified chips.

[0064] For example, the Chroma tester compares the hardware test values ​​of each chip with the preset pass threshold one by one, and removes unqualified chips marked as short circuit, leakage, or communication abnormality. Only qualified chips with all electrical parameters meeting the standards are retained. After the screening is completed, a unified performance test start trigger signal is generated and uploaded to the MES. For example, chips No. 2 and No. 5 in stations 1-8 are screened out because they are electrically unqualified. The station information corresponding to the remaining qualified chips No. 1, 3, 4, 6, 7, and 8 is sent along with the trigger signal. After receiving the signal, the MES can schedule the Raspberry Pi in each station to cooperate with the differentiated optical device to carry out ranging performance verification.

[0065] S303: After receiving the start trigger signal, the control device sends a performance test start command for the qualified TOF chip to the Raspberry Pi at the workstation.

[0066] In this embodiment, after receiving the performance test trigger signal from the Chroma tester, the MES (mes) will send a start command to the Raspberry Pi at each workstation, allowing the Raspberry Pi to perform optical ranging performance testing on the electrically qualified TOF chip.

[0067] For example, the MES parses the list of qualified chips for each workstation carried in the trigger signal, retrieves the pre-bound differentiated scene algorithms and corresponding optical scene parameters, and then sends a performance test start command to all Raspberry Pis at workstations containing qualified TOF chips. At the same time, it also sends supporting data such as the workstation's exclusive algorithm and reflectivity parameters. For example, if the trigger signal shows that the chip hardware of workstations 1, 3, 4, 6, 7, and 8 is qualified, the MES will push start commands to the Raspberry Pis at these six workstations respectively.

[0068] In the above method, faulty chips are first screened out before optical performance testing is triggered, and performance testing instructions are only issued to electrically qualified chips. This reduces the amount of invalid algorithm computation, lowers the computing power consumption of the Raspberry Pi, and further improves the overall parallel testing efficiency.

[0069] S103: After receiving the batch test task and the performance test start command sent by the control device, the Raspberry Pi at the workstation performs performance verification on the TOF chip that has passed the hardware test, and obtains the performance verification result.

[0070] In this embodiment, the Raspberry Pi at the workstation first receives the complete batch test task. After receiving the performance test start command issued by MES, it uniformly performs optical ranging performance verification on the TOF chips with qualified hardware electrical properties, and finally outputs the performance test data of each chip.

[0071] In the above method, by adding an independent Raspberry Pi to the workstation to share the optical algorithm computing task, the performance testing bottleneck caused by insufficient computing power of the testing equipment can be avoided, and the overall throughput efficiency of parallel testing of the entire batch of TOF chips can be greatly improved.

[0072] In one embodiment, see Figure 6 This is a schematic diagram of a performance verification process provided in an embodiment of this application, as shown below. Figure 6 As shown, step S103 includes: S401, the Raspberry Pi at the workstation controls all TOF chip test workstations to collect raw sampling data under their respective differentiated optical scenarios.

[0073] In this embodiment, the Raspberry Pi at each workstation controls the TOF chip at its corresponding workstation, allowing the chip to simultaneously collect two types of raw sampling data—dark field and bright field—in its own unique and differentiated optical environment, providing basic raw data for subsequent performance calculations.

[0074] For example, the Raspberry Pi at each workstation controls the TOF chip to switch between dark field acquisition mode and bright field acquisition mode in a time-division manner based on the pre-issued differentiated optical scene configuration parameters. It collects two sets of raw data in the environment of the dedicated reflective device provided at the workstation. In the dark field stage, the external reflective light source is turned off and only the chip noise data is collected. In the bright field stage, the corresponding reflectivity target surface, background strong light and other optical devices are turned on to collect imaging data with reflected echoes. For example, workstation 3 is equipped with a 50% reflectivity light tube. The Raspberry Pi at this workstation first controls the chip to turn off the light source to collect the raw pixels in the dark field, and then turns on the 50% reflective device to collect the sampling data in the bright field. Workstation 8 is equipped with a long-distance strong light target and simultaneously completes the dark and bright field data collection under its own working conditions. All raw data is temporarily stored locally on the Raspberry Pi to wait for algorithm processing.

[0075] S402, the Raspberry Pi at the workstation acquires the raw sampling data and preprocesses the raw sampling data to obtain the preprocessed raw sampling data.

[0076] In this embodiment, after the Raspberry Pi at the workstation collects the original dark and bright field sampling data output by the TOF chip, it performs preprocessing operations such as noise reduction and differential operation, and outputs the optimized and corrected sampling data.

[0077] For example, the Raspberry Pi at the workstation reads the original pixel data of the dark and bright fields from the local cache. First, it performs differential noise reduction on the bright field data by using the dark field noise floor value to remove inherent chip noise and ambient stray light interference. Then, it performs standardization processing such as pixel amplitude normalization and removal of abnormal jump points. For example, the original data of the 10% reflection scene collected at workstation 1 has noise floor offset and sporadic abrupt pixel changes. The Raspberry Pi calls the preset preprocessing program to remove dark field noise and filter abnormal pixels, outputting clean and regular preprocessed sampling data for subsequent calculation of ranging performance by differentiated scene algorithms.

[0078] S403, the Raspberry Pi at the workstation performs performance verification on the TOF chip that has passed hardware testing based on the pre-processed raw sampling data, and obtains the performance verification results.

[0079] In this embodiment, each Raspberry Pi at each workstation uses the noise-reduced and corrected sampling data to simultaneously perform ranging performance calculations on electrically qualified TOF chips, ultimately generating a performance judgment result for each chip.

[0080] In the above method, each Raspberry Pi independently completes data acquisition, preprocessing, and performance algorithm calculation in a dedicated and differentiated optical scenario, distributing computing power to avoid the computing power bottleneck of the Chroma test machine, and enabling multi-station synchronous parallel testing, which greatly improves the batch testing efficiency of TOF chips.

[0081] In another embodiment, see Figure 7This is a schematic diagram of the performance verification process provided in another embodiment of this application, such as... Figure 7 As shown, step S403 includes: S501, the workstation Raspberry Pi loads the corresponding differentiated scenario algorithms from the batch test task.

[0082] In this embodiment, the Raspberry Pi at the workstation reads the batch test task file stored locally and retrieves the exclusive algorithm bound to the optical scene of the workstation for subsequent TOF chip performance calculation.

[0083] For example, when batch test tasks are issued, the MES has pushed the differentiated scenario algorithms matched for each workstation to the corresponding Raspberry Pi and stored them locally. When the performance verification stage is entered, the Raspberry Pi reads the workstation binding identifier in the task and automatically loads the matching algorithm. For example, if workstation 4 is equipped with a 90% high reflectivity optical device, the Raspberry Pi will load a high reflectivity scenario-specific ranging algorithm. If workstation 7 is equipped with a strong light background device, it will load an anti-strong light correction algorithm. After loading, the algorithm can be called to process the preprocessed sampled data.

[0084] The S502 Raspberry Pi at the workstation runs differentiated scenario algorithms based on the pre-processed raw sampled data and outputs performance verification results.

[0085] In this embodiment, the Raspberry Pi at the workstation takes the noise-corrected bright and dark field sampling data as input, calls the workstation's proprietary differentiated scene algorithm to perform calculations, calculates various ranging indicators of the TOF chip and compares them with standards, and outputs the chip's performance test results.

[0086] For example, the Raspberry Pi at each workstation inputs the pre-processed, noise-reduced, and abnormal pixel-removed standardized sampling data into the already loaded differentiated scene algorithm. The algorithm calculates performance parameters such as depth accuracy, ranging error, and point cloud quality according to the calculation logic of the corresponding optical scene, and then compares the measured parameters with the preset qualified threshold to complete the good or bad judgment. For example, workstation 2 is equipped with a 10% low-reflection optical device, and the Raspberry Pi runs a low-reflection dedicated algorithm, substitutes the pre-processed data of the scene to calculate the weak reflection ranging deviation, and workstation 5 is equipped with a strong light source, and runs an anti-strong light algorithm to verify the ranging stability under strong light. After the two workstations are calculated synchronously, they each generate performance verification results containing measured values, defect types, and qualified marks.

[0087] In the above method, the Raspberry Pi at the workstation directly loads the differentiated scene algorithm that matches the optical scene of the workstation and is uniformly distributed by MES for independent operation, realizing distributed computing power allocation, eliminating the computing power bottleneck of the Chroma test machine, and enabling synchronous parallel operation at multiple workstations, which effectively improves the overall efficiency of batch performance testing of TOF chips.

[0088] In one embodiment, see Figure 8This is a schematic diagram of the feedback detection result provided in an embodiment of this application, as shown below. Figure 8 As shown, it includes: S601, the Raspberry Pi at the workstation sends the performance verification results to the test device.

[0089] In this embodiment of the application, after the Raspberry Pi at each workstation completes the optical performance measurement of the TOF chip, it will upload the generated performance verification results to the Chroma tester for the Chroma tester to integrate the complete set of test data.

[0090] For example, the Raspberry Pi at each workstation compiles a complete performance verification data package containing the workstation number, chip number, measured values ​​of each ranging indicator, pass / fail judgment, and corresponding optical scene information. This data package is then transmitted to the Chroma tester via a preset communication link. For instance, the Raspberry Pi at workstation 1 uploads the ranging error results of the chip in a 10% low-reflection scene, and the Raspberry Pi at workstation 6 uploads the chip's anti-interference performance data in a strong light scene. After receiving all the data returned from the workstations, the Chroma tester simultaneously stores all the chip's electrical and performance test records.

[0091] S602, the test equipment sends the hardware test results and performance verification results to the control equipment.

[0092] In this embodiment, the Chroma tester aggregates the previously collected chip hardware electrical test data and the optical performance verification data returned by the Raspberry Pi at each workstation, and uploads them to the MES in a unified manner to complete the collection of all test data.

[0093] For example, the Chroma tester binds a unique number to each TOF chip and packages the hardware test indicators such as short circuit and leakage current corresponding to the same chip, as well as the performance verification results such as ranging error and signal-to-noise ratio, into a complete data message, which is sent to the MES through the communication channel. For example, if the chip at station 1 passes the hardware test but the ranging error exceeds the standard in the 10% low reflection scenario, the Chroma tester binds the electrical pass record and the performance failure record of the chip and uploads them synchronously. The data from multiple stations are summarized in sequence and then uniformly pushed to the MES for archiving and review.

[0094] S603: After receiving the hardware test results and performance verification results, the control device generates a test report based on the hardware test results and performance verification results.

[0095] In this embodiment, the MES receives the chip electrical test data and optical performance verification data from the Chroma tester, combines the two sets of test data to comprehensively determine the overall quality of the chip, and automatically generates a complete batch test report.

[0096] For example, the MES reads the hardware electrical specifications, performance parameters under different optical scenarios, and pass / fail criteria corresponding to each TOF chip, correlates and matches the results of hardware testing and performance verification, and summarizes and statistically analyzes them by workstation, chip number, and defect type. At the same time, it calculates the batch yield and the proportion of each type of defect, and generates a standardized test report. For example, if a chip meets all hardware electrical standards, but the ranging error exceeds the threshold in a 90% high-reflection scenario, the MES will mark the chip as hardware qualified but optically defective in the report, and count the number of chips with hardware defects, performance defects, and fully qualified chips in this batch, and retain all original test data for future reference.

[0097] In addition, the entire set of test data and the generated complete test report are simultaneously pushed to the customer's server for archiving via the manufacturing execution system. The Chroma tester first marks the hardware faulty chips based on electrical data. Then, the customer combines the algorithm performance results of various optical scenarios to classify and categorize chips that meet both hardware and performance standards, classifying them into product levels suitable for different operating conditions. For example, if the customer retrieves multi-scenario performance verification data from the server for comprehensive evaluation, chips that meet the ranging accuracy standard in a standard 50% reflection scenario and pass the anti-interference parameter test in a strong light scenario are classified as strong light environment suitable level; chips whose long-distance ranging error meets the standard are classified as long-distance operating condition suitable level; and chips that meet all general requirements are classified as standard environment suitable level. This completes the refined classification and selection of qualified chips.

[0098] In the above method, hardware and performance test data are aggregated step by step throughout the entire chain and a complete test report is generated uniformly by the control equipment. This enables the chip's electrical and optical performance data to be bound and collected one by one, ensuring data integrity and traceability. At the same time, the layered transmission distributes data pressure and ensures stable and smooth data transmission for multi-station parallel testing.

[0099] See Figure 9 This is a schematic diagram of the overall architecture of a parallel testing system for a TOF chip provided in an embodiment of this application, as shown below. Figure 9 As shown, the system is divided into five major functional module clusters, with the control and data transmission interaction relationships between the modules clearly marked. A detailed list of test items is attached on the right. Optical hardware environment layer: differentiated light source and reflection environment, probe station and basic environment, responsible for providing physical test conditions for the chip under test; The core component under test: the TOF chip under test, which is the object of all electrical and optical performance tests; Test control and computing layer: Chroma test machine (hardware electrical main controller) and Raspberry Pi (optical algorithm computing unit), the two interact bidirectionally to control and test results; Data aggregation and transfer: The MES (Manufacturing Execution System) receives all test data, distributes algorithm files, and connects to the customer's server; Terminal storage layer: client server, permanently storing batch algorithms and test data; right-hand sub-box: breaks down all test sub-items, including DC electrical performance, storage communication, parameter calibration, Raspberry Pi algorithm operation, TOF general function, and multi-scenario differentiated optical testing; arrows in the diagram indicate the interaction logic: control commands, test results, large amounts of sampled data, algorithm distribution, bin sorting results, data synchronization and other transmission links.

[0100] The specific steps for implementing parallel testing of OF chips using the overall architecture of the above-mentioned parallel testing system for TOF chips include: Step 1: Set up the physical test conditions Differentiated light sources and reflective environments, combined with probe stations and basic environments, provide optical testing scenarios with multiple reflectivities and different light intensities for the TOF chip under test. At the same time, the probe station provides basic electrical testing conditions such as standard power supply current and voltage. The probes physically contact the TOF chip under test to complete the hardware connection.

[0101] Step 2: Start the Chroma tester for full hardware electrical testing. The Chroma tester, acting as the main hardware test controller, first performs the hardware test items listed on the right for the TOF chip under test: DC parameter test, communication and register test, and parameter calibration. Simultaneously collect hardware electrical data such as short circuit, leakage current, power supply voltage, and register read / write of all workstation chips; Automatically compare thresholds, filter out faulty chips and generate sub-bin tags, and record hardware detection results; After the hardware test is completed, the test status is sent to the MES system in sync, and a performance test start control signal is sent to the Raspberry Pi at the same time.

[0102] Step 3: Raspberry Pi receives instructions and loads differentiated scene algorithms. The MES system receives algorithm data packets from the client server in advance and sends them to the local storage of the Raspberry Pi. After receiving the start-up trigger signal from the Chroma test machine, the Raspberry Pi loads a differentiated algorithm that matches the optical scene of the current workstation. The Raspberry Pi establishes numerous data transmission channels with the TOF chip under test, and the control chip synchronously acquires raw sampling data of dark and bright fields under differentiated optical reflection environments.

[0103] Step 4: Raspberry Pi completes optical performance verification calculations. The raw sampling data of bright and dark fields collected by Raspberry Party are preprocessed with noise reduction, differential correction and other methods; Run the workstation-specific differentiated scenario algorithm to complete the right-side TOF function test and TOF differentiated multi-scenario test; Calculate performance indicators such as ranging error, signal-to-noise ratio, strong light resistance, and long-distance ranging, and generate performance verification results for each chip; All performance data is sent back to the Chroma test machine.

[0104] Step 5: The testing machine summarizes all the test data and uploads it to the MES system. The Chroma tester is bound to a unique serial number for each chip. It packages and integrates the hardware electrical test results of the same chip with the optical performance verification results returned by the Raspberry Pi. After confirming that all data transmission is completed, it is uploaded to the MES system.

[0105] Step 6: MES system data transfer and synchronization with client server MES collects full batch hardware and performance testing data and generates complete batch testing reports. MES synchronously forwards the original data of the algorithm and the complete set of test reports to the customer's server for archiving. MES synchronously receives the hardware defect sorting results from the Chroma tester and records the defective chip information.

[0106] Step 7: Customer segmentation and sorting (application at the end of the process) Customers retrieve full-scenario performance data from the server. Based on the hardware's qualification, qualified chips are classified according to multi-scenario algorithm verification indicators: standard environment adaptation, strong light environment adaptation, and long-distance working condition adaptation level. Combined with the hardware defects marked by the test machine, the final sorting and warehousing are completed.

[0107] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0108] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0109] Figure 10 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. For example... Figure 10 As shown, the terminal device 10 of this embodiment includes: at least one processor 100 ( Figure 10 (Only one is shown in the diagram) a processor, a memory 101, and a computer program 102 stored in the memory 101 and capable of running on at least one processor 100. When the processor 100 executes the computer program 102, it implements the steps in any of the above embodiments of the parallel testing method for TOF chips.

[0110] The terminal device can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. This terminal device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 10 This is merely an example of terminal device 10 and does not constitute a limitation on terminal device 10. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0111] The processor 100 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0112] In some embodiments, memory 101 may be an internal storage unit of terminal device 10, such as a hard disk or memory of terminal device 10. In other embodiments, memory 101 may be an external storage device of terminal device 10, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on terminal device 10. Furthermore, memory 101 may include both internal and external storage units of terminal device 10. Memory 101 is used to store operating system, applications, boot loader, data, and other programs, such as program code of computer programs. Memory 101 may also be used to temporarily store data that has been output or will be output.

[0113] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0114] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the steps described in the various method embodiments above.

[0115] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / terminal equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0116] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0117] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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.

[0118] In the embodiments provided in this application, it should be understood that the disclosed apparatus / terminal devices and methods can be implemented in other ways. For example, the apparatus / terminal device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0120] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A parallel testing method for a TOF chip, characterized in that, A parallel testing system for TOF chips is provided, comprising testing equipment, control equipment, and multiple Raspberry Pi workstations; wherein each Raspberry Pi workstation corresponds to one TOF chip testing workstation; the control equipment communicates with both the testing equipment and the Raspberry Pi workstations; the testing equipment communicates with the Raspberry Pi workstations. The control device synchronously sends batch test tasks to the test device and all the Raspberry Pis at the workstations. After receiving the batch test task, the test equipment simultaneously performs hardware electrical tests on all TOF chip test stations to obtain hardware test results. After receiving the batch test task, and after receiving the performance test start command sent by the control device, the Raspberry Pi at the workstation synchronously performs performance verification on the TOF chip that has passed the hardware test, and obtains the performance verification result.

2. The parallel testing method for TOF chips as described in claim 1, characterized in that, The TOF chip parallel testing system also includes multiple differentiated optical reflection devices; one of these devices is used to construct a differentiated optical scene; the control device synchronously sends batch test tasks to the testing equipment and all the Raspberry Pis at the workstations, including: The control device receives multiple differentiated scene algorithms and configuration parameters uploaded by the user through an encrypted interface; wherein, the configuration parameters include the differentiated optical scene bound to the differentiated scene algorithm, the TOF chip test station, and the Raspberry Pi information of the station; After the control device receives multiple differentiated scenario algorithms uploaded by the user, it performs verification processing on the multiple differentiated scenario algorithms according to the configuration parameters to obtain the verification result; After the verification result indicates that the verification has passed, the control device synchronously sends batch test tasks to the test device and all the Raspberry Pis at the workstations.

3. The parallel testing method for TOF chips as described in claim 2, characterized in that, The method further includes: The testing equipment filters out unqualified TOF chips based on the hardware test results and marks the unqualified TOF chips. The testing equipment selects qualified TOF chips based on the hardware test results and sends a start trigger signal to the control equipment to perform performance testing on the qualified TOF chips. After receiving the start trigger signal, the control device sends a performance test start command for the qualified TOF chip to the Raspberry Pi at the workstation.

4. The parallel testing method for TOF chips as described in claim 2, characterized in that, The TOF chips that pass the hardware testing at the Raspberry Pi booth undergo simultaneous performance verification, and the performance verification results are as follows: The Raspberry Pi at the workstation controls the TOF chips at all TOF chip testing workstations to collect raw sampling data under their respective differentiated optical scenarios; The Raspberry Pi at the workstation acquires the raw sampling data and preprocesses the raw sampling data to obtain preprocessed raw sampling data. The Raspberry Pi at the workstation performs performance verification on the TOF chip that has passed hardware testing based on the preprocessed raw sampling data, and obtains the performance verification results.

5. The parallel testing method for TOF chips as described in claim 4, characterized in that, The batch testing task includes differentiated scenario algorithms; the Raspberry Pi at the workstation synchronously performs performance verification on the TOF chip that has passed hardware testing based on the preprocessed raw sampled data, and obtains the performance verification results, including: The Raspberry Pi at the workstation loads the corresponding differentiated scenario algorithm from the batch test task; The Raspberry Pi runs the differentiated scenario algorithm based on the preprocessed raw sampled data and outputs the performance verification results.

6. The parallel testing method for a TOF chip as described in any one of claims 1-5, characterized in that, The method further includes: The Raspberry Pi at the workstation sends the performance verification results to the testing device; The testing equipment sends the hardware test results and the performance verification results to the control equipment; After receiving the hardware detection results and the performance verification results, the control device generates a detection report based on the hardware detection results and the performance verification results.

7. A parallel testing system for a TOF chip, characterized in that, It includes a control device, a testing device, multiple Raspberry Pi workstations, and multiple TOF chip testing workstations; the TOF chip parallel testing system is used to implement the TOF chip parallel testing method as described in claim 1 above.

8. The parallel testing system for TOF chips as described in claim 7, characterized in that, The TOF chip parallel testing system also includes multiple differentiated scene reflection devices; wherein, the differentiated scene reflection devices are used to construct differentiated optical scenes.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 6.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

Images