Probe table-based zynq multi-core test system
By using a probe station testing system based on the ZYNQ multi-core architecture, efficient parallel processing of task scheduling and data transmission is achieved, solving the problems of low resource utilization and insufficient data synchronization in single-core testing systems, improving testing efficiency and response speed, and adapting to complex testing needs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SUZHOU GST INFOMATION TECH CO LTD
- Filing Date
- 2026-04-23
- Publication Date
- 2026-06-26
AI Technical Summary
Existing single-core testing systems cannot effectively utilize multiple processor cores for parallel testing. Task scheduling and execution priorities are difficult to manage in a fine-grained manner, software coupling is high, and data synchronization mechanisms are insufficient, resulting in low testing efficiency, uncertain response, and lack of scalability.
The probe station testing system adopts a ZYNQ multi-core architecture. Through shared memory and the collaborative work of multiple processing units, it achieves centralized task scheduling and status management and periodic monitoring. It utilizes a soft interrupt mechanism for efficient scheduling and data transmission and supports flexible expansion.
It significantly improves testing efficiency and response speed, ensures data integrity and system robustness, and supports flexible adaptation and smooth expansion for complex testing needs.
Smart Images
Figure CN122283399A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of electrical performance testing technology, and in particular to a ZYNQ multi-core testing system based on a probe station. Background Technology
[0002] Chip testing is a crucial part of the chip design and manufacturing process, designed to ensure that the chip's functionality and performance meet design requirements and to screen out defective chips.
[0003] However, existing chip testing still has the following problems:
[0004] 1. Current single-core test system chips have multiple idle processor cores, and their computing power cannot be effectively utilized to execute multiple test items in parallel, resulting in the overall test time being limited by the processing speed of a single core.
[0005] 2. In a "single-core polling" or "simple interrupt" architecture, it is difficult to achieve fine-grained management of the scheduling and execution priorities of all tasks.
[0006] 3. Existing single-core test programs typically highly couple communication, scheduling, and business logic. When new test items need to be added or existing test processes need to be modified, the entire software often needs to be refactored, introducing higher error risks and development costs.
[0007] 4. In existing technologies, task status, control commands, and feedback data are usually exchanged through shared memory, but there is a lack of effective synchronization and mutual exclusion mechanisms for accessing them, which can easily lead to data competition and inconsistent status in a multi-core environment.
[0008] Therefore, existing technologies have shortcomings in terms of testing efficiency, real-time response, scalability, and software reliability, which need to be addressed. Summary of the Invention
[0009] Therefore, it is necessary to provide a probe station-based ZYNQ multi-core testing system to address the aforementioned technical issues, effectively improving testing efficiency and response speed, providing strong scalability, and ensuring system robustness and data integrity.
[0010] This application provides a probe station-based ZYNQ multi-core testing system, including:
[0011] Shared memory is used to store task registers, control registers, task status flags, and the working status of the first processing unit, the second processing unit, and the third processing unit.
[0012] The first processing unit is used to receive instructions from the host computer via the LWIP protocol, set the task register of the pending task according to the instruction frame header, and poll the return control register of each task.
[0013] The second processing unit is used to poll the control registers of all tasks except the return control register, as well as the working status of the third processing unit. Based on the polling results, the status flag of the pending task is set to pending status, and a soft interrupt is sent to the third processing unit whose working status is idle.
[0014] At least one third processing unit is used to execute a service task in response to a soft interrupt. Before executing the service task, it accesses the task status flag in the shared memory to determine whether execution is required. If execution is required, the returned data is stored in the shared memory after execution and the corresponding task return control register is set.
[0015] When the first processing unit detects that the task feedback control register is set, it sends the feedback data to the host computer.
[0016] In one embodiment, the first processing unit is further configured to poll the first timer flag bit and the second timer flag bit, the first timer flag bit corresponding to a fast timing event and the second timer flag bit corresponding to a slow timing event, for maintaining the timing processing of the LWIP protocol stack.
[0017] In one embodiment, the second processing unit has a built-in triple timer counter and scheduler. The triple timer counter triggers a polling operation every 1ms. The scheduler sets the status flag of the pending task to the pending state according to the polling result and sends a soft interrupt to the third processing unit whose working state is idle.
[0018] In one embodiment, the second processing unit is configured to: during the periodic polling of shared memory, if any task register is detected to be set, set the status flag of the corresponding task in the shared memory to the pending state.
[0019] During the periodic polling of shared memory, if an idle third processing unit is detected and there are tasks in a pending state, a soft interrupt is sent to the idle third processing unit.
[0020] In one embodiment, the third processing unit is configured to: upon receiving a soft interrupt, execute multiple service tasks in the order of the local service program, wherein each service task reads the corresponding status flag in the shared memory before execution, and executes the service task only when the status flag indicates that it is pending processing.
[0021] In one embodiment, the system runs on the ZYNQ platform, the first processing unit, the second processing unit, and the third processing unit are multiple independent CPU cores in the ZYNQ processor system, the shared memory is an on-chip shared storage area, and the system development environment is Vitis.
[0022] In one embodiment, the system further includes a general interrupt controller, through which the second processing unit sends a soft interrupt to the third processing unit.
[0023] In one embodiment, the first processing unit sends a soft interrupt to the second and third processing units through the interrupt controller according to the instructions from the host computer.
[0024] In one embodiment, the system is deployed on a probe station.
[0025] The aforementioned probe-station-based ZYNQ multi-core testing system includes: shared memory for storing task registers, control registers, task status flags, and the working status of a first processing unit, a second processing unit, and a third processing unit; a first processing unit for receiving instructions from the host computer via the LWIP protocol, setting the task registers of pending tasks according to the instruction frame header, and simultaneously polling the return control registers of each task; a second processing unit for polling the control registers of all tasks except the return control registers, and the working status of the third processing unit, setting the status flags of pending tasks to the pending state according to the polling results, and sending a soft interrupt to the third processing unit whose working state is idle; at least one third processing unit for responding to the soft interrupt, executing a service task, accessing the task status flags in the shared memory before executing the service task to determine whether execution is required, and if execution is required, storing the return data in the shared memory after execution and setting the corresponding task return control register; wherein, when the first processing unit polls and finds that the task return control register is set, it sends the return data to the host computer. The system schedules tasks through multi-core collaborative work logic and centrally and periodically monitors and manages the status, thereby achieving automated and parallel testing of chips. Attached Figure Description
[0026] Figure 1 This is a flow diagram of a probe station-based ZYNQ multicore testing system in one embodiment. Detailed Implementation
[0027] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0028] This application provides a probe station-based ZYNQ multi-core testing system, employing a Xilinx ZYNQ series processor. In the Vitis development environment, this processor includes a dual-core or quad-core ARM Cortex-A9 architecture. This embodiment uses a quad-core configuration as an example for illustration. Figure 1 As shown, it includes shared memory, a first processing unit, a second processing unit, and a third processing unit.
[0029] The shared memory is used to store Task-Reg, Ctrl_Reg, task status identifiers, and the working status of the first processing unit, the second processing unit, and the third processing unit.
[0030] CPU0, as the first processing unit, runs the LWIP protocol stack and is responsible for Ethernet communication with the host computer. Specifically, it receives instructions from the host computer via the LWIP protocol, sets the task registers of pending tasks according to the instruction frame header, and polls the return control registers of each task.
[0031] CPU1, acting as the second processing unit, runs the task scheduler. Specifically, it polls the control registers of all tasks except the return control register, as well as the working status of the third processing unit. Based on the polling results, it sets the status flag of the pending tasks to the pending state and sends a soft interrupt to the third processing unit whose working state is idle.
[0032] CPU2 and CPU3, acting as the third processing unit, run the test service program. Specifically, in response to a software interrupt, they execute a service task. Before executing the service task, they access the task status flag in shared memory to determine whether execution is necessary. If execution is necessary, after completion, they store the returned data in shared memory and set the corresponding task return control register. When the first processing unit detects that the task return control register is set, it sends the returned data to the host computer.
[0033] The complete operation process includes the following operations:
[0034] S1. The host computer sends a test command to the ZYNQ's PS (Processing System) via LWIP (Lightweight IP) Ethernet. The command format includes fields such as frame header, task type, and task parameters. After receiving the command, CPU0 parses the frame header and sets the corresponding task register (Task_Reg) to 1 according to the task type. The task register is used to describe or control a task and typically contains fields such as task status (ready / running / completed / error, etc.), task ID, and task pointer.
[0035] Meanwhile, CPU0 continuously polls TcpFastTmrFlag and TcpSlowTmrFlag, these two flags being periodically set by a hardware timer. When the flag is 1, CPU0 calls the tcp_fasttmr() and tcp_slowtmr() functions of the LWIP protocol stack to maintain the TCP connection state.
[0036] TcpFastTmrFlag and TcpSlowTmrFlag are the TCP fast timer flag and TCP slow timer flag, respectively. The former typically has a very short period, usually 200ms or less, and is responsible for handling time-sensitive tasks that require fast retransmission or fast response; the latter typically has a longer period, usually 500ms or 1 second, and is responsible for handling tasks that do not require high precision, have high overhead, or have long time cycles.
[0037] S2 and CPU1 are internally configured with a Triple Timer Counter (TTC) and a scheduler, operating at a frequency of 100kHz. This timer triggers an interrupt every 1ms. In the interrupt service routine, CPU1 polls the control registers (Ctrl_Reg) of all tasks except those sending back data. The control registers are used to control the global behavior, enabling, and mode selection of the hardware modules.
[0038] If a task's Ctrl_Reg is detected to be 1, the corresponding task's status token in shared memory is set to pending status.
[0039] CPU1 continuously polls the status registers of CPU2 and CPU3. When an idle CPU is detected with a task pending processing, the scheduler sends a soft interrupt (i.e., the Software_intr_Send function) to the idle CPU, triggering that CPU to execute the test task.
[0040] S3, CPU2, and CPU3 wait for a software interrupt (i.e., Software_intr_Receive) while in idle state. When CPU2 or CPU3 receives a software interrupt, it enters the interrupt service routine and executes all registered service tasks in sequence.
[0041] The execution logic for each Service is as follows:
[0042] S301. First, read the corresponding task status identifier Token (i.e., Token_Read_EN) from the shared memory.
[0043] S302. If the Token is in a pending state, then perform specific test operations (i.e., Service_Caculate) (such as sending control signals to the probe station, reading measurement data, etc.).
[0044] S303. After execution, the test result data is written to the return data area in shared memory;
[0045] S304. Set the corresponding task return control register Ctrl_Reg to 1 to indicate that there is data to be returned.
[0046] S4. CPU0 polls the task return control register (i.e., Service_Send_Back) in shared memory. When it detects that a certain Ctrl_Reg is 1, CPU0 reads the corresponding return data from shared memory, encapsulates it through the LWIP protocol stack, and sends it to the host computer via Ethernet. After sending, it clears the Ctrl_Reg to zero and waits for the next return.
[0047] In one embodiment, the system further includes a Generic Interrupt Controller (GIC), through which the second processing unit sends soft interrupts to the third processing unit.
[0048] In one embodiment, the first processing unit can send interrupt commands to the second and third processing units via GIC under the instruction of the host computer.
[0049] Existing technologies suffer from the following problems: lack of efficient parallel testing solutions for multi-core heterogeneous chips; insufficient real-time scheduling capabilities of the test system, resulting in low test throughput and uncertain response; rigid test software architecture, unable to flexibly adapt to dynamic and complex test processes; and inefficient and unreliable inter-core task collaboration and data synchronization mechanisms.
[0050] To address the aforementioned issues, this invention, based on the ZYNQ platform and the Vitis development environment, constructs a logical multi-core real-time scheduling system with four processor cores working collaboratively. It centrally and periodically monitors and manages the system's task scheduling and core status; on the computing cores receiving scheduling instructions, it automates and pipelines the execution of test tasks and data retrieval; and based on a multi-core collaborative testing process, it uses the ZYNQ chip to automate and parallelize the testing and evaluation of various functions and performance indicators.
[0051] Compared to existing solutions, the improvements are as follows: First, the first processing unit focuses on network communication and data backhaul, the second processing unit focuses on task scheduling, and the third processing unit focuses on test execution. Each unit performs its specific function without interfering with the others, significantly improving system response speed. The second processing unit monitors the task queue and processing unit status in real time through a combination of timed polling and main loop polling, and uses a soft interrupt mechanism to efficiently schedule idle cores, achieving dynamic load balancing of tasks. Second, test data is stored in shared memory by the third processing unit and the backhaul control register is set. The first processing unit independently polls for backhaul, decoupling data transmission from test execution and reducing the uncertainty of data backhaul latency. Third, the number of third processing units can be flexibly configured according to test task requirements, and the system architecture supports smooth expansion to meet the needs of different scale test scenarios. Fourth, through multi-core parallel processing and idle core scheduling, the utilization of processor resources is maximized.
[0052] The beneficial effects of this invention include:
[0053] 1. Significantly improves testing efficiency and throughput, fully unleashing the potential of multi-core hardware;
[0054] 2. Achieve highly deterministic real-time response to ensure critical test timing;
[0055] 3. The architecture is flexible and highly scalable, making it easy to adapt to complex testing needs;
[0056] 4. Establish a stable and reliable inter-core collaboration mechanism to ensure system robustness and data integrity.
[0057] In summary, the ZYNQ multi-core chip testing system based on a probe station provided by this invention achieves efficient parallel processing of test tasks and low-latency data return through multi-core division of labor and an efficient soft interrupt scheduling mechanism. It can be widely used in semiconductor wafer testing, chip functional verification, multi-channel parallel testing and other fields, and has high industrial practical value.
[0058] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0059] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0060] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A probe-station-based ZYNQ multi-core testing system, characterized in that, The system includes: Shared memory is used to store task registers, control registers, task status flags, and the working status of the first processing unit, the second processing unit, and the third processing unit. The first processing unit is used to receive instructions from the host computer via the LWIP protocol, set the task register of the pending task according to the instruction frame header, and poll the return control register of each task. The second processing unit is used to poll the control registers of all tasks except the return control register, as well as the working status of the third processing unit. Based on the polling results, the status flag of the pending task is set to the pending state, and a soft interrupt is sent to the third processing unit whose working state is idle. At least one of the third processing units is configured to respond to a soft interrupt, execute a service task, access the task status flag in the shared memory before executing the service task to determine whether execution is required, and if execution is required, store the returned data in the shared memory after execution and set the corresponding task return control register. When the first processing unit detects that the task feedback control register is set, it sends the feedback data to the host computer.
2. The system according to claim 1, characterized in that: The first processing unit is also used to poll the first timer flag bit and the second timer flag bit. The first timer flag bit corresponds to a fast timing event, and the second timer flag bit corresponds to a slow timing event, in order to maintain the timing processing of the LWIP protocol stack.
3. The system according to claim 1, characterized in that: The second processing unit has a built-in triple timer counter and scheduler. The triple timer counter triggers a polling operation every 1ms. The scheduler sets the status flag of the pending task to the pending state according to the polling result and sends a soft interrupt to the third processing unit whose working state is idle.
4. The system according to claim 1, characterized in that: The second processing unit is configured to: during the periodic polling of the shared memory, if any task register is detected to be set, then set the status flag of the corresponding task in the shared memory to the pending state; During the periodic polling of the shared memory, if an idle third processing unit is detected and there is a task in a pending state, a soft interrupt is sent to the idle third processing unit.
5. The system according to claim 1, characterized in that: The third processing unit is configured to: upon receiving a soft interrupt, execute multiple service tasks in the order of the local service program. Each service task reads the corresponding status flag in the shared memory before execution, and executes the service task only when the status flag indicates that it is pending processing.
6. The system according to claim 1, characterized in that: The system runs on the ZYNQ platform. The first processing unit, the second processing unit, and the third processing unit are multiple independent CPU cores in the ZYNQ processor system. The shared memory is an on-chip shared storage area. The system development environment is Vitis.
7. The system according to claim 1, characterized in that: The system also includes a general interrupt controller, through which the second processing unit sends a soft interrupt to the third processing unit.
8. The system according to claim 7, characterized in that: The first processing unit sends a soft interrupt to the second processing unit and the third processing unit through the interrupt controller according to the host computer instruction.
9. The system according to claim 1, characterized in that: The system is deployed on a probe station.