Management system for integrated circuit test

Abstract

The invention discloses a management system for an integrated circuit test, and relates to the technical field of integrated circuit test management, and the system comprises a task scheduling module which is used for receiving a plurality of test task requests, and generating a test task scheduling sequence based on the priority parameter of each test task, the current state of a test resource, and a historical execution result; and the resource coordination module is used for acquiring the running states of the plurality of test devices, executing resource allocation operation according to the test task scheduling sequence, and generating a coordination abnormal event if resource conflict or scheduling failure is detected in the execution process. According to the invention, a dependency graph between test equipment and bottom hardware resources is constructed through the resource coordination module, and accurate modeling of a resource mutual exclusion relationship, concurrent capacity and conflict risk is supported, so that resource conflicts are pre-judged before scheduling, and the problems of resource scrambling and deadlock are effectively avoided.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit test management technology, specifically to an integrated circuit test management system. Background Technology

[0002] As the core component of modern electronic devices, integrated circuits play an important role in the entire production process. To meet the development trend of continuously expanding chip scale and increasing testing accuracy, testing platforms are gradually evolving from single-device control to multi-device collaboration and distributed scheduling.

[0003] In existing technologies, test tasks are typically allocated to various test devices by a scheduling module according to certain priority rules, and the task execution process is tracked by a status management module. Some test systems also support resource scheduling and exception handling functions to improve the stability and efficiency of the overall test process. These technologies provide a solid foundation for batch testing of integrated circuits and are widely used in semiconductor test platforms (such as ATE systems) and automated test pipelines.

[0004] However, with the increasing complexity of chips and the rise of parallel testing tasks, existing scheduling mechanisms still face certain challenges in the following aspects, such as:

[0005] When multiple test tasks are executed in parallel, there are problems such as resource mutual exclusion and device contention. Without an effective coordination mechanism, it is easy to cause task conflicts or scheduling failures.

[0006] The status awareness of test equipment is mainly focused on the operational level, lacking structured management of the underlying hardware resources of the equipment (such as power supply, cache, communication channels, etc.), making it difficult to achieve fine-grained scheduling;

[0007] The anomaly detection and feedback mechanism is relatively static and fails to fully utilize the trend information of historical task execution behavior or test parameters to optimize subsequent scheduling strategies.

[0008] The scheduling system primarily responds passively to changes in task status and anomaly feedback, lacking a dynamic and adaptive scheduling optimization closed loop.

[0009] Therefore, there is an urgent need for a new integrated circuit test management system that can support multi-device coordination, resource conflict identification, behavior avoidance scheduling, parameter trend feedback and scheduling optimization closed loop, in order to meet the requirements of efficient operation in complex test environments. Therefore, this application proposes an integrated circuit test management system. Summary of the Invention

[0010] The purpose of this invention is to provide a management system for integrated circuit testing to solve the problems mentioned in the background art.

[0011] The present invention can be achieved through the following technical solution: an integrated circuit testing management system, comprising: a task scheduling module, a resource coordination module, a task status management module, an anomaly judgment module, an anomaly handling module, and a feedback linkage module;

[0012] The task scheduling module is used to receive multiple test task requests and generate a test task scheduling sequence based on the priority parameters of each test task, the current status of the test resources, and the historical execution results.

[0013] The resource coordination module is used to obtain the operating status of multiple test devices and perform resource allocation operations according to the test task scheduling sequence in order to coordinate parallel test tasks among multiple devices.

[0014] If a resource conflict or scheduling failure is detected during execution, a coordination exception event is generated.

[0015] The task status management module is used to record the status information of each test task from scheduling and execution to completion or interruption, and maintain the task execution path, device allocation record and status label;

[0016] The anomaly detection module is used to receive anomaly events from the resource coordination module or the task status management module, determine the anomaly type, and determine the anomaly handling path according to preset rules. The anomaly types include fatal anomalies, recoverable anomalies, and negligible anomalies.

[0017] The exception handling module is used to execute a corresponding exception handling strategy based on the output of the exception judgment module, including:

[0018] For recoverable anomalies, resource replacement, task rescheduling, or process redirection should be performed.

[0019] The test is terminated upon encountering a fatal exception, and a termination message is sent back to the task scheduling module.

[0020] Mark negligible exceptions and continue executing subsequent test tasks;

[0021] The feedback linkage module is used to synchronously feed back the anomaly handling results and task status change information to the task scheduling module and resource coordination module, so as to realize the adaptive update of subsequent scheduling strategies and resource usage schemes.

[0022] The modules work together to form a control loop for dynamic scheduling, parallel coordination, and anomaly handling of test tasks, which improves the execution efficiency, resource utilization, and anomaly response capabilities of the integrated circuit testing process.

[0023] A further technical improvement of the present invention is that the method for generating the test task scheduling sequence includes:

[0024] A1. The test equipment resources are divided into functional zones for management, forming multiple resource functional zones;

[0025] Each test task to be executed is automatically mapped to a resource function area that matches its resource requirements and test characteristics, forming a corresponding sub-task queue.

[0026] A2. Establish a historical behavior record library for each test task, including the results of the previous M executions, the frequency of interruptions, records of abnormal terminations, and whether resource conflicts have occurred.

[0027] For test tasks that meet preset abnormal conditions in historical behavior records, the system sets them to "suspended state" and does not enter the current scheduling process for the time being;

[0028] The remaining test tasks that were not set to "suspended" status are marked as "stable" status;

[0029] In the current scheduling cycle, only test tasks with a "stable" status participate in task sequence generation;

[0030] A3. Each resource function area has an independent scheduling sliding window, which is used to dynamically scan and select test tasks that can be executed under the current test equipment status.

[0031] If the test device is idle and the task is active, the task will be temporarily added to the partition execution candidate list;

[0032] A4. Each candidate task is assigned a time window for scheduling by the system upon submission, including the earliest scheduling time and the latest deadline.

[0033] Tasks within the sliding window are prioritized for scheduling those with the shortest remaining available time.

[0034] When the remaining schedulable time of a task is less than the minimum remaining scheduling time threshold set by the system, the system automatically raises the priority of the task to the highest level and executes it first in the subsequent scheduling order.

[0035] A5. Each resource function area outputs the tasks in its current sliding window, sorted by time.

[0036] The system aggregates the results from each partition to form the final test task scheduling sequence.

[0037] A further technical improvement of the present invention is that step A3 specifically includes:

[0038] a31. Equipment Status Detection: The system first obtains the current operating status of all test equipment in the resource functional area, including whether the test equipment is idle, whether it is under maintenance, whether a fault has occurred, and whether a test task is being executed.

[0039] a32. Subtask queue reading: The system reads the task sub-queue corresponding to the resource function area. The queue stores all test tasks that have been mapped to the resource function area and are in a "stable" state and are waiting to be scheduled.

[0040] a33. State Matching Judgment: For each test task, the system determines whether the following two conditions are met simultaneously:

[0041] The corresponding test equipment is in an idle state;

[0042] The test task is in an "active" state, meaning it is not in a suspended state, and its scheduling time window is within the validity period.

[0043] a34. Candidate Task Cache: If all the conditions in a33 above are met, the test task is marked as "currently executable" and temporarily stored in the execution candidate task list of this resource function area;

[0044] a35, Sliding window advancement: The system repeats steps a31 to a34 at the beginning of each new scheduling cycle.

[0045] A further technical improvement of the present invention is that: the task status management module includes a parameter trend analysis unit, used to detect the cross-cycle change trend of key test parameters in the test task, including:

[0046] P1. After each round of testing is completed, the system extracts the corresponding key test parameters.

[0047] Furthermore, the system uses test task identifiers and timestamps as indexes to build a parameter time series database;

[0048] P2. The system periodically performs trend modeling on the parameter time series, using any one of the moving average, linear fitting, or filtering algorithms to determine whether there is a persistent shift in the test parameters.

[0049] P3. If a certain test parameter shows a change in the same direction in multiple consecutive rounds of testing, and the change in the same direction exceeds the set change threshold, a "parameter drift anomaly" status label will be generated and attached to the current test task status record.

[0050] A further technical improvement of the present invention is that: after step P3, the abnormal trend marker will be fed back to the abnormal judgment module and the feedback linkage module, triggering the evaluation of the effectiveness of the current chip test. At the same time, the scheduling module can reduce the priority of subsequent tasks of the chip or execute additional verification rounds accordingly.

[0051] A further technical improvement of the present invention is that: the resource coordination module establishes a resource dependency graph for all test devices and their underlying hardware resources, and each resource is marked with its mutual exclusion and maximum concurrent usage capability;

[0052] Before scheduling test tasks, the system extracts a list of hardware resources required for the test tasks and cross-compares it with the current resource occupancy status.

[0053] If multiple test tasks compete for the same exclusive resource and are in the same time slot's scheduling queue, the system determines that there is a risk of resource conflict and generates a conflict flag.

[0054] For test tasks that pose a risk of conflict, the system will postpone or re-queue them based on factors such as task priority and remaining time in the scheduling window.

[0055] A further technical improvement of the present invention is that: during the initialization phase, the system establishes a resource mutual exclusion structure for all test equipment resources that can be shared and called by multiple test tasks;

[0056] During the scheduling process, resource occupancy checks are performed on the resources required for each test task. If the concurrency limit has been reached, the task is added to the resource queuing queue, and the queuing order is dynamically adjusted according to its priority, submission time, and remaining scheduling time.

[0057] When resources are released, the highest priority task in the queue is automatically activated;

[0058] If the test task queue wait time exceeds the preset period or multiple rounds of scheduling fail, the exception will be reported through the feedback linkage module and the exception handling process will be initiated.

[0059] A further technical improvement of the present invention is that, in step A3, the system periodically extracts the list of currently executing candidate test tasks from each resource functional area and performs the following fusion and sorting operation:

[0060] Perform a preliminary global sorting based on the current priority of each test task;

[0061] If multiple test tasks have the same priority, they are further sorted in ascending order of their remaining schedulable time.

[0062] For test tasks with remaining scheduling time below the system's set threshold, the system temporarily raises their priority and places them at the top of the sorting sequence;

[0063] The final result is a cross-partition fusion scheduling sequence containing all resource functional area test tasks;

[0064] Subsequently, the system transmits the scheduling sequence to the resource coordination module, which performs parallel distribution of test tasks and resource binding operations based on the availability of the test equipment, the mutual exclusion of hardware resources, and the current priority strategy.

[0065] A further technical improvement of the present invention is that, in step A4, the system iterates through all candidate test tasks in each scheduling cycle to obtain their current remaining schedulable time. And perform the following operations:

[0066] a41. Regarding the remaining schedulable time Test tasks with less than the minimum remaining scheduling time threshold set by the system are marked as "scheduling urgent" and their current priority is increased.

[0067] a42. Sort all candidate test tasks in descending order of priority;

[0068] For test tasks with the same priority, sort them from shortest to longest remaining schedulable time;

[0069] a43. Construct the sorting results into a test task scheduling sequence that can be executed in this round.

[0070] A further technical improvement of this invention is that, in step A2, the system establishes an independent behavior recording unit for each test task and records the corresponding test task's metrics, including execution result sequence, interruption event count, abnormal termination flag, and resource conflict record.

[0071] When any indicator meets the preset abnormal conditions, the task is marked as "temporarily suspended" and its participation in the current scheduling process is suspended.

[0072] Tasks not marked as "delayed" are marked as "stable" and participate in task selection and sorting in subsequent scheduling cycles;

[0073] For tasks in a "suspended state", the system sets an observation period. If no abnormalities are recorded during the observation period, the task's scheduling eligibility is restored.

[0074] When a recovered test task re-participates in scheduling and reordering for the first time, it is given a priority weight lower than that of a task in a stable state.

[0075] If the task triggers any abnormal condition again, its observation period will be extended or the exception handling module will take over.

[0076] Compared with the prior art, the present invention has the following beneficial effects:

[0077] This invention constructs a dependency graph between test equipment and underlying hardware resources through a resource coordination module, supporting accurate modeling of resource mutual exclusion relationships, concurrent capacity, and conflict risks. This allows for the prediction of resource conflicts before scheduling, effectively avoiding resource contention and deadlock issues. Furthermore, the system dynamically sets the schedulable state of tasks based on information such as historical execution results, abnormal interruption records, and resource conflict status, preventing unstable tasks from frequently being added to the scheduling sequence and improving the overall operational stability of the system.

[0078] Meanwhile, this invention utilizes a sliding scheduling window and a remaining schedulable time-driven mechanism to dynamically filter and sort candidate tasks within different resource functional areas, ensuring that time-critical tasks receive priority scheduling opportunities, thereby improving the real-time performance and fairness of the scheduling strategy. Furthermore, the system uses a task status management module to track the entire process of each test task from creation, allocation, execution to completion or interruption, and combines this with an anomaly judgment module to provide comprehensive anomaly type identification and classification processing, facilitating the optimization and adjustment of the scheduling system.

[0079] On the other hand, the results of anomaly handling and the status of task execution can be synchronized to the scheduling module and resource coordination module in real time through the feedback linkage module, so as to realize the adaptive update of the scheduling strategy, enabling the system to have dynamic evolution and long-term optimization capabilities. The system can also perform cross-cycle trend modeling of key parameters in the test task. If continuous drift is detected to exceed the threshold, the corresponding task will be marked as an "abnormal task" and the scheduling priority adjustment or additional verification will be triggered to improve the chip test quality control capability. Attached Figure Description

[0080] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0081] Figure 1 This is a schematic diagram of the system logic of the present invention. Detailed Implementation

[0082] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.

[0083] Please see Figure 1 As shown, the present invention provides a management system for integrated circuit testing, including: a task scheduling module, a resource coordination module, a task status management module, an exception judgment module, an exception handling module, and a feedback linkage module;

[0084] The task scheduling module is used to receive multiple test task requests and generate a test task scheduling sequence based on the priority parameters of each test task, the current status of test resources, and historical execution results.

[0085] The test task scheduling sequence generation method includes:

[0086] A1. Resource structure partitioning and task mapping:

[0087] The test equipment resources are managed by functional partitions, forming multiple resource functional areas;

[0088] Each test task to be executed is automatically mapped to a resource function area that matches its resource requirements and test characteristics, forming a corresponding sub-task queue.

[0089] A2. Initialization of Task Behavior Avoidance Mechanism:

[0090] Establish a historical behavior record library for each test task, including its most recent execution results, interruption frequency, abnormal termination records, and whether it has caused resource conflicts;

[0091] For test tasks that meet preset abnormal conditions in historical behavior records, the system sets them to a "suspended state" and temporarily prevents them from entering the current scheduling process; in this embodiment, the preset abnormal conditions include the following:

[0092] The last two tests failed;

[0093] The frequency of interruptions within a specified number of past occurrences has reached the preset upper limit;

[0094] The most recent scheduling process was abnormally aborted;

[0095] Resource conflicts have occurred multiple times in previous scheduling processes.

[0096] The remaining test tasks that were not set to "suspended" status are marked as "stable" status;

[0097] In the current scheduling cycle, only test tasks with a "stable" status participate in task sequence generation;

[0098] In step A2, the system establishes an independent behavior recording unit for each test task, recording quantitative information including the following metrics:

[0099] Execution result sequence: Records the results of M consecutive tests, marked as success or failure;

[0100] Interrupt event count: Counts the number of interrupts that occurred within the previous K scheduling cycles;

[0101] Abnormal termination flag: Marks whether the previous round of testing was terminated due to system interruption, fault, or abnormality;

[0102] Resource conflict log: Records whether the task caused device mutual exclusion conflicts or resource preemption events during the past P scheduling processes.

[0103] The system sets the following pre-defined exception conditions. When a test task meets any of these conditions, it will be marked as "suspended" and will not enter the current scheduling process:

[0104] Both rounds of scheduling execution were recorded as "failure" results;

[0105] The number of interrupts within the past K scheduling cycles is greater than or equal to the interrupt threshold;

[0106] There was an "abnormal termination" flag in the previous round of scheduling execution;

[0107] In the first P task scheduling cycles, the number of resource conflict records is greater than or equal to the conflict threshold.

[0108] Furthermore, the above rules can be adjusted through parameter configuration to improve their scalability.

[0109] Test tasks that are not marked as "suspended" are considered to be in a normal state, marked as "stable", and are included as eligible tasks in the current scheduling cycle, participating in the sliding window task extraction and sorting process.

[0110] For test tasks that have been marked as "suspended", the system sets a fixed-length observation and counting period and executes the following re-evaluation mechanism:

[0111] Tasks that do not add new abnormal records during the observation period can be switched back to the "schedulable" state after the observation period ends.

[0112] Tasks that are re-evaluated and are in normal condition will be added to the tail of the scheduling queue and re-enter the scheduling process in a low-priority mode for trial operation and observation.

[0113] If any abnormal condition is triggered again after re-entry, the observation period will be extended or manual intervention will be initiated.

[0114] A3. Partition task extraction based on sliding window:

[0115] Each resource function area has an independent scheduling sliding window, which is used to dynamically scan and select test tasks that can be executed under the current test equipment status;

[0116] If the test device is idle and the task is active, the task will be temporarily added to the partition execution candidate list;

[0117] Specifically, it includes:

[0118] a31. Equipment Status Detection: The system first obtains the current operating status of all test equipment in the resource functional area, including whether the test equipment is idle, whether it is under maintenance, whether a fault has occurred, and whether a test task is being executed.

[0119] a32. Subtask queue reading: The system reads the task sub-queue corresponding to this resource function area. The queue stores all test tasks that have been mapped to this resource function area and are in a "stable" state and are waiting to be scheduled.

[0120] a33. State Matching Judgment: For each test task, the system determines whether the following two conditions are met simultaneously:

[0121] The corresponding test equipment is in an idle state;

[0122] The test task is in an "active" state, meaning it is not in a suspended state, and its scheduling time window is within the validity period.

[0123] a34. Candidate Task Cache: If all the conditions in a33 above are met, the test task is marked as "currently executable" and temporarily stored in the execution candidate task list of this resource function area;

[0124] a35. Sliding window advancement: At the beginning of each new scheduling cycle, the system repeats steps a31 to a34 to continuously update the list of candidate tasks for execution in each resource functional area, thereby realizing periodic filtering and real-time refreshing during the scheduling process.

[0125] In step A3, the system periodically extracts the list of currently executing candidate test tasks from each resource functional area and performs the following fusion and sorting operation:

[0126] First, perform a preliminary global sorting based on the current priority of each test task;

[0127] If multiple test tasks have the same priority, they are further sorted in ascending order of their remaining schedulable time.

[0128] For test tasks with remaining scheduling time below the system's set threshold, the system temporarily raises their priority and places them at the top of the sorting sequence;

[0129] The final result is a cross-partition fusion scheduling sequence that includes all resource functional area test tasks.

[0130] Subsequently, the system transmits the scheduling sequence to the resource coordination module. The resource coordination module performs parallel distribution of test tasks and resource binding operations based on the availability status of the test equipment, the mutual exclusion of hardware resources, and the current priority strategy.

[0131] A4. Task sorting based on scheduling time windows:

[0132] Each candidate task is assigned a time window for scheduling by the system when it is submitted, including the earliest scheduling time and the latest deadline.

[0133] Tasks within the sliding window are prioritized for scheduling those with the shortest remaining available time.

[0134] When the remaining schedulable time of a task is less than the minimum remaining scheduling time threshold set by the system, the system automatically raises the priority of the task to the highest level and executes it first in the subsequent scheduling order, so as to avoid the task being unable to be executed due to exceeding the latest scheduling time.

[0135] In step A4, the system calculates the remaining schedulable time for the current scheduling period. That is, remaining schedulable time = latest scheduling time - current system time;

[0136] In each scheduling cycle, the system iterates through all candidate test tasks and obtains their current remaining schedulable time. ;

[0137] for For test tasks whose remaining time is less than the minimum scheduling threshold set by the system, the system marks them as "scheduling urgent" and dynamically increases their current priority, so that they are scheduled to be executed before other test tasks in the scheduling order, in order to ensure that they are processed before the latest scheduling time.

[0138] For other test tasks with sufficient remaining time, their original priority should be maintained or they should be placed at the end of the queue. If resources are limited, scheduling can be postponed.

[0139] All candidate tasks are globally sorted according to the following rules:

[0140] Arranged in descending order of priority;

[0141] For tasks with the same priority, sort them from shortest to longest remaining schedulable time.

[0142] The sorting results are used to construct the sequence of executable scheduled tasks for this round.

[0143] A5. Scheduling sequence fusion and output:

[0144] Each resource function area outputs the tasks within its current sliding window, sorted by time.

[0145] The system aggregates the results from each partition to form the final test task scheduling sequence. Specifically, the aggregation steps include:

[0146] Globally sort each test task according to its current priority;

[0147] For tasks with the same priority, they are arranged from shortest to longest remaining schedulable time.

[0148] The test tasks are organized into a final test task scheduling sequence according to the sorting results.

[0149] If there are insufficient resources, insufficient tasks, or empty windows, the system can retrieve the suspended tasks that have reached the end of the observation period and re-participate them in the subsequent scheduling.

[0150] The resource coordination module is used to obtain the operating status of multiple test devices and perform resource allocation operations according to the test task scheduling sequence in order to coordinate parallel test tasks among multiple devices.

[0151] If a resource conflict or scheduling failure is detected during execution, a coordination exception event is generated.

[0152] Specifically, the resource coordination module periodically or when task scheduling is triggered, obtains the operating status information of all test devices in the system, including but not limited to:

[0153] Is it in an idle state?

[0154] Are there any test tasks currently assigned?

[0155] Is it under maintenance, experiencing an error, or offline?

[0156] The resource functional area to which the current device belongs;

[0157] Estimated remaining time to complete the task;

[0158] All operational status data will be standardized and stored in the device status cache for subsequent scheduling and matching.

[0159] The resource coordination module receives the test task scheduling sequence generated by the task scheduling module, parses the task items in sequence, and executes the following matching logic in turn:

[0160] Read the resource types, test modes, and execution duration required for each test task;

[0161] Locate the currently idle test devices within the corresponding resource function area;

[0162] If a match is found, the device will be marked as "assigned" and the task will be bound to that device.

[0163] If this type of device is temporarily unavailable, it is recorded as pending allocation and handed over to the scheduling module for retry in the next scheduling cycle.

[0164] Furthermore, to enable parallel testing collaboration among multiple test devices, the resource coordination module supports the following mechanisms:

[0165] Multi-threaded resource allocation ensures that multiple tasks can enter the device matching process in parallel.

[0166] If multiple tasks compete for the same type of device resources, the system will prioritize them based on task priority and remaining scheduling time.

[0167] If a test device supports multiple channels, concurrent task allocation will be performed according to the test device's parallel execution strategy.

[0168] Once a test task is assigned to the test equipment:

[0169] The resource coordination module sets the test device to "running" status;

[0170] The task assignment results are then sent to the task status management module for registration.

[0171] At the same time, the test task-test equipment binding relationship is fed back to the scheduling module so that the scheduling plan can be updated in the next cycle;

[0172] If a resource conflict occurs during the test (such as two modules being incorrectly assigned to the same device), the resource coordination module will interrupt the conflict task and report it to the exception judgment module.

[0173] If the following abnormal situations occur during resource coordination, the system will trigger the abnormal coordination mechanism:

[0174] All similar equipment is either out of service or under maintenance;

[0175] A task failed to be assigned in two consecutive scheduling cycles;

[0176] A certain test device was repeatedly marked by multiple tasks within a short period of time;

[0177] At this point, the resource coordination module generates a coordination exception event and sends it to the exception judgment module, which determines whether to perform task rescheduling, resource replacement, or process jump operation.

[0178] The resource coordination module establishes a resource dependency graph for all test devices and their underlying hardware resources (such as power supply channels, cache interfaces, and data transmission paths). Each resource is labeled with its mutual exclusion and maximum concurrent usage capacity. In this embodiment, the establishment of the resource dependency graph includes the following steps:

[0179] R1. The system first performs a resource structure scan on all test devices to identify the underlying hardware resources they depend on. Each test device needs to specify the following dependency information:

[0180] Required power supply channel markings (e.g., PWR-A, PWR-B);

[0181] The connected cache / temporary storage modules (such as Cache-1, Cache-2);

[0182] The communication channel or data transmission path used (such as BUS-1, BUS-2).

[0183] Other shared resources include test instruments, switch arrays, multiplexers, etc.

[0184] Each resource is represented by a unique identifier, and a dependency mapping table of "device → resource" is established.

[0185] R2. Treat all the identified hardware resources as "nodes" in the graph, and define the following attribute fields for each resource node:

[0186] Resource types (such as power supply, transmission, buffering, etc.);

[0187] Mutual exclusion flag (indicates whether parallel access is supported, such as "mutually exclusive" or "shared");

[0188] Maximum concurrent usage (used for sharing resources, such as supporting a maximum of 3 tasks in parallel);

[0189] Bandwidth or resource consumption weight (optional, used for subsequent optimization of scheduling strategies).

[0190] R3, represented by the graph structure G=(V,E):

[0191] Node set V: includes all test devices and their dependent resources;

[0192] Edge set E: Each variable ( , ), indicating the testing equipment Dependency resources ;

[0193] Furthermore, this graph structure supports:

[0194] Many-to-one relationship (multiple devices depend on the same resource);

[0195] One-to-many relationship (one device depends on multiple resources);

[0196] Nodes and edges are added or deleted during environment updates to achieve dynamic maintenance of resource topology.

[0197] R4. The resource dependency graph is stored in the resource management subunit of the coordination module in the form of structured data, and supports the following interface calls:

[0198] Dependency query interface: Retrieves all resource nodes that a test task will use;

[0199] Conflict detection interface: Determines whether multiple candidate tasks conflict with a certain resource at the same time.

[0200] Availability assessment interface: At a given scheduling time, determine the load and availability of each resource node;

[0201] Structure update interface: Automatically update the graph structure when a new device is added, a resource becomes invalid, or a resource is replaced.

[0202] Before scheduling test tasks, the system extracts a list of hardware resources required for the test tasks and cross-compares it with the current resource occupancy status.

[0203] If multiple test tasks compete for the same exclusive resource and are in the same time slot's scheduling queue, the system determines that there is a risk of resource conflict and generates a conflict flag.

[0204] For test tasks with conflict risks, the system will postpone or re-queue them based on factors such as task priority and remaining time in the scheduling window to avoid resource contention and improve resource utilization efficiency. The specific steps include:

[0205] Z1. The system performs conflict analysis on test tasks that are about to enter the scheduling queue. If a conflict is detected:

[0206] The same resource node (such as the same power supply path or data channel) is depended on by two or more test tasks in the same time period;

[0207] And the resource node is marked as "mutually exclusive" or the current remaining concurrency is 0;

[0208] It is then marked as a "task group with a risk of conflict".

[0209] Z2. For each task within this task group, the system extracts the following two scheduling elements as priority rearrangement factors:

[0210] z21. Current task priority value The higher the value, the greater the urgency.

[0211] z21. Remaining time in the scheduling window The value is derived by subtracting the current time from the latest available time; the smaller the value, the more urgent the situation.

[0212] Z3. The system adjusts the task scheduling order according to the following logic:

[0213] z31. Reordering: For task groups with conflicts, sort them according to the comprehensive ranking index. Sort the tasks, prioritizing those with high priority and urgent scheduling windows.

[0214] z32. Scheduling strategy: The first test task retains the scheduling right for the current round, and subsequent test tasks will be delayed for one or more scheduling cycles and re-queued depending on the resource recovery status;

[0215] If the remaining scheduling time of a test task is lower than the minimum schedulable time threshold, the system will mark it as an "urgent task" and give it priority for retry in the next round of scheduling.

[0216] Z4. For test tasks that are delayed in their scheduling, the system will record the conflict occurrence in the task status management module and simultaneously report it back to:

[0217] Task scheduling module: Used for state awareness during the generation of the next round of scheduling sequence;

[0218] Resource Coordination Module: Updates resource usage expectations to prevent duplicate conflicts.

[0219] The task status management module is used to record the status information of each test task from scheduling, execution to completion or interruption, and maintain the task execution path, device allocation record and status label. Specifically, when a test task is included in the scheduling queue by the scheduling module, the task status management module receives the scheduling start instruction.

[0220] The task status management module includes the scheduling timestamp, the scheduling batch to which it belongs, the task priority, and the estimated scheduling time window.

[0221] The status label is initially set to "Pending Assignment" and is updated to "Assigned" after successful assignment.

[0222] After the resource coordination module successfully assigns a task to a test device, the task status management module synchronously records the following data:

[0223] Assign equipment numbers;

[0224] The resource functional area where the equipment is located;

[0225] Device status change (idle → running);

[0226] The time point at which tasks are bound to devices;

[0227] The system generates a complete task execution path record for this test task. The path content includes the scheduling module, resource coordination module, target device number, and information of each time node, which is used for subsequent traceability analysis.

[0228] During the execution of the test task, the task status management module continuously receives execution status feedback from the device layer or resource coordination module, including:

[0229] Did the task start on time?

[0230] Was the task interrupted due to equipment failure?

[0231] Did the task complete successfully?

[0232] Does it trigger abnormal behavior during the test (such as signal loss or test failure)?

[0233] For each status change, the task status management module updates the status label (e.g., executing, completed, interrupted, exception) and records the change time.

[0234] If the task is interrupted during execution, the system will:

[0235] Mark the task as "abnormal interruption" status;

[0236] Synchronously record the interruption time and cause classification (such as resource conflict, equipment failure, test failure, etc.).

[0237] Update the state at the end of its execution path;

[0238] Interruption information can be used by the exception detection module to determine whether the task should be rescheduled or terminated.

[0239] When a test task is successfully completed, the task status management module will:

[0240] Update the status label to "Completed";

[0241] Archive its complete execution path and all status change records;

[0242] Transfer it from the active task pool to the historical task library;

[0243] The task status management module supports setting data retention policies to periodically clean up or compress historical status data, thereby improving system operating efficiency.

[0244] The task status management module sets a unified status label field for each test task, including but not limited to the status labels shown in Table 1:

[0245] Table 1

[0246] Status Label Meaning Explanation Pending allocation It has entered the scheduling sequence but has not yet been assigned a device. Allocated Test device has been bound and is ready to begin execution. In progress Currently being executed by the device Completed The test task has been completed successfully. Interruption Abnormal termination occurred during the test. Abnormal termination The system terminates the task proactively (e.g., due to a serious error). Postponed Dispatch temporarily suspended due to abnormal historical behavior

[0247] Status tags will be used throughout each scheduling cycle and provided to other modules (such as the feedback linkage module and the exception judgment module) as a basis for judgment.

[0248] The task status management module includes a parameter trend analysis unit, used to detect the cross-cycle change trends of key test parameters in the test task, including:

[0249] P1. Time series archiving of test parameters:

[0250] After each round of testing is completed, the system extracts the corresponding key test parameters, including threshold voltage, current, charge response time, etc.

[0251] Furthermore, the system uses test task identifiers and timestamps as indexes to build a parameter time series database;

[0252] P2. Trend Analysis and Judgment:

[0253] The system periodically performs trend modeling on the parameter time series, using any one of the moving average, linear fitting, or filtering algorithms to determine whether there is a persistent shift in the test parameters.

[0254] P3. Anomaly Trend Marking and Output:

[0255] If a test parameter shows a consistent change in the same direction in multiple consecutive rounds of testing, and the consistent change exceeds the set change threshold, a "parameter drift anomaly" status label will be generated and attached to the current test task status record.

[0256] After step P3, the abnormal trend marker will be fed back to the anomaly judgment module and the feedback linkage module, triggering an evaluation of the effectiveness of the current chip test. At the same time, the scheduling module can reduce the priority of subsequent tasks for the chip or execute additional verification rounds accordingly.

[0257] The exception judgment module is used to receive exception events from the resource coordination module or the task status management module, determine the exception type, and determine the exception handling path according to preset rules. The exception types include fatal exceptions, recoverable exceptions, and ignoreable exceptions.

[0258] In this embodiment, the exception handling path includes:

[0259] When the abnormal event is "resource conflict continues to time out", the system will transfer the test task to "requeuing mode" and reduce its initial priority in the next round of scheduling.

[0260] When the abnormal event is "multi-round scheduling failure" or "queue expired", the system triggers the "task replacement mechanism" to try to replace the current task with a candidate task with similar test requirements;

[0261] When the abnormal event is "equipment failure" or "test data abnormality", the system suspends task scheduling and transfers the abnormal task to the manual review queue;

[0262] For other non-critical anomalies, the task is marked as "needs observation", the anomaly level is recorded, and the scheduling frequency is reduced in subsequent scheduling.

[0263] The exception handling module is used to execute the corresponding exception handling strategy based on the output of the exception judgment module, including:

[0264] For recoverable anomalies, resource replacement, task rescheduling, or process redirection should be performed.

[0265] The test is terminated upon encountering a fatal exception, and a termination message is sent back to the task scheduling module.

[0266] Mark negligible exceptions and continue executing subsequent test tasks;

[0267] The feedback linkage module is used to synchronously feed back the results of exception handling and task status changes to the task scheduling module and resource coordination module, enabling adaptive updates to subsequent scheduling strategies and resource usage plans. Specifically:

[0268] The feedback linkage module receives processing results from the exception handling module in real time, including but not limited to:

[0269] Anomaly type (recoverable, fatal, negligible);

[0270] The handling strategies already adopted (such as task termination, resource replacement, process redirection, etc.);

[0271] At the same time, the feedback linkage module also receives task status change information provided by the task status management module, including whether the task is completed, interrupted, failed, or delayed.

[0272] The feedback linkage module integrates the exception handling results with the task status change and models them as a "scheduling feedback event", which includes the following fields:

[0273] Associated task number;

[0274] This involves equipment serial numbers and resource functional areas;

[0275] Exception types and handling actions;

[0276] Task execution result status;

[0277] Timestamps and associated scheduling cycle information;

[0278] The "scheduling feedback event" will serve as the trigger for updating the scheduling module and resource coordination module's strategies.

[0279] After the feedback linkage module sends a scheduling feedback event to the task scheduling module, the task scheduling module executes the following strategy update logic based on the feedback information:

[0280] If a task experiences consecutive anomalies or failures, the scheduling module will downgrade its priority or put it into a "suspended state".

[0281] If the proportion of tasks continuously interrupted or failed in a certain resource function area exceeds the set threshold, the scheduling module will reduce the task allocation ratio of that area in the next round of scheduling, or adjust the size of the sliding window.

[0282] If resource conflicts occur frequently within a certain period of time, the scheduling module will automatically increase the conflict avoidance time interval or adopt a peak-shifting strategy.

[0283] If some tasks are successfully recovered through alternative devices, the scheduling module records the device as a "priority alternative device" for subsequent similar scheduling.

[0284] The feedback linkage module synchronously feeds back the following content to the resource coordination module:

[0285] If a device is marked as a "risk device" due to frequent malfunctions or anomalies, the system will restrict its task allocation frequency or mark it for maintenance.

[0286] If a certain type of device exhibits a higher success rate or a shorter execution cycle, the system will increase its scheduling priority within the partition;

[0287] If anomalies occur frequently in a specific resource functional area, the system will temporarily reduce the number of concurrent test tasks in that functional area to improve stability.

[0288] The load distribution strategy for various testing devices is dynamically adjusted based on success rate and task completion cycle.

[0289] Scheduling feedback events are periodically written to the "policy state buffer," which is read by the scheduling module and resource coordination module before each new scheduling initialization.

[0290] By dynamically updating the strategy and equipment allocation logic each cycle, continuous optimization of scheduling behavior and resource usage can be achieved.

[0291] If the feedback event continuously meets a certain policy transition condition (such as an abnormal density threshold), the system will automatically perform a policy switch, for example, switching from normal scheduling logic to "high fault tolerance mode".

[0292] The modules work together to form a control loop for dynamic scheduling, parallel coordination, and anomaly handling of test tasks, which improves the execution efficiency, resource utilization, and anomaly response capabilities of the integrated circuit testing process.

[0293] During the initialization phase, the system establishes a resource mutual exclusion structure for all test device resources that can be shared and accessed by multiple test tasks. Specifically, this includes:

[0294] Establish resource identifiers for the underlying hardware resources of each test device (such as multimeters, power supply channels, interface conversion modules, etc.);

[0295] Set a concurrent usage limit for each shared resource (such as exclusive use or maximum number of simultaneous uses);

[0296] It maintains the current usage status, the number of tasks occupied, and the queue list of tasks to be scheduled.

[0297] After the resource coordination module receives the scheduling sequence output by the task scheduling module, it performs the following operations:

[0298] Perform access status checks on the resources required by each test task in the scheduling sequence;

[0299] If a shared resource is currently occupied and has reached its concurrency limit, the system determines that the test task has a conflict risk.

[0300] The test task is not immediately assigned for execution, but is instead placed in the scheduling queue for that resource.

[0301] For test tasks identified as having resource conflicts, the system performs the following actions:

[0302] Dynamic priority is calculated by combining the original priority of the test task, the submission time, and the remaining schedulable time.

[0303] The test task was added to the queue of the corresponding resource and set to "waiting in queue" status;

[0304] The system periodically checks the release status of the resource, and triggers the test task re-entry allocation process as soon as it becomes available.

[0305] Once a test task is completed, the test equipment resources it occupied are released, and the resource coordination module performs the following steps:

[0306] Update the current usage status of the resource;

[0307] If the queue is not empty, the test task with the highest priority in the queue is selected, marked as "Scheduling Activated", and the task scheduling module is notified to include it in the next round of scheduling sequence generation.

[0308] The system continuously tracks the waiting time and number of attempts for test tasks in the queue. If any of the following conditions are met:

[0309] The queuing time exceeds the maximum waiting period set by the system.

[0310] Multiple scheduling attempts still failed to successfully allocate the required resources;

[0311] The abnormal status is then reported to the abnormal judgment module through the feedback linkage module, which then initiates the corresponding rescheduling or task replacement process.

[0312] By introducing the aforementioned mutual exclusion judgment, queuing management, and dynamic priority update mechanisms into the resource coordination module, the system can achieve:

[0313] Conflict identification and management of shared resources among multiple test tasks;

[0314] Avoid resource contention, scheduling deadlock, and interference between different processes;

[0315] Improve the resource utilization efficiency and task scheduling success rate of the testing process under concurrent conditions.

[0316] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0317] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A management system for integrated circuit testing, characterized in that, include: The task scheduling module is used to receive multiple test task requests and generate a test task scheduling sequence based on the priority parameters of each test task, the current status of test resources, and historical execution results. The resource coordination module is used to obtain the operating status of multiple test devices, perform resource allocation operations according to the test task scheduling sequence, and generate coordination exception events if resource conflicts or scheduling failures are detected during the execution process. The task status management module is used to record the status information of each test task from scheduling and execution to completion or interruption, and maintain the task execution path, device allocation record and status label; An anomaly detection module is used to receive anomaly events from the resource coordination module or the task status management module, determine the anomaly type, and determine the anomaly handling path according to preset rules. An exception handling module is used to execute a corresponding exception handling strategy based on the output of the exception judgment module. The feedback linkage module is used to synchronously feed back the results of exception handling and task status changes to the task scheduling module and resource coordination module.

2. The integrated circuit testing management system according to claim 1, characterized in that, The test task scheduling sequence generation method includes: A1. The test equipment resources are divided into functional zones for management, forming multiple resource functional zones; Each test task to be executed is automatically mapped to a resource function area that matches its resource requirements and test characteristics, forming a corresponding sub-task queue. A2. Establish a historical behavior record library for each test task, including the results of the previous M executions, the frequency of interruptions, records of abnormal terminations, and whether resource conflicts have occurred. For test tasks that meet preset abnormal conditions in historical behavior records, the system sets them to "suspended state" and does not enter the current scheduling process for the time being; The remaining test tasks that were not set to "suspended" status are marked as "stable" status; In the current scheduling cycle, only test tasks with a "stable" status participate in task sequence generation; A3. Each resource function area has an independent scheduling sliding window, which is used to dynamically scan and select test tasks that can be executed under the current test equipment status. If the test device is idle and the task is active, the task will be temporarily added to the partition execution candidate list; A4. Each candidate task is assigned a time window for scheduling by the system upon submission, including the earliest scheduling time and the latest deadline. Tasks within the sliding window are prioritized for scheduling those with the shortest remaining available time. When the remaining schedulable time of a task is less than the minimum remaining scheduling time threshold set by the system, the system automatically raises the priority of the task to the highest level and executes it first in the subsequent scheduling order. A5. Each resource function area outputs the tasks in its current sliding window, sorted by time. The system aggregates the results from each partition to form the final test task scheduling sequence.

3. The integrated circuit testing management system according to claim 2, characterized in that, Step A3 specifically includes: a31. Equipment Status Detection: The system first obtains the current operating status of all test equipment in the resource functional area, including whether the test equipment is idle, whether it is under maintenance, whether a fault has occurred, and whether a test task is being executed. a32. Subtask queue reading: The system reads the task sub-queue corresponding to the resource function area. The queue stores all test tasks that have been mapped to the resource function area and are in a "stable" state and are waiting to be scheduled. a33. State Matching Judgment: For each test task, the system determines whether the following two conditions are met simultaneously: The corresponding test equipment is in an idle state; The test task is in an "active state", meaning it is not in a suspended state, and its scheduling time window is within the validity period. a34. Candidate Task Cache: If all the conditions in a33 above are met, the test task is marked as "currently executable" and temporarily stored in the execution candidate task list of this resource function area; a35, Sliding window advancement: The system repeats steps a31 to a34 at the beginning of each new scheduling cycle.

4. The integrated circuit testing management system according to claim 1, characterized in that, The task status management module includes a parameter trend analysis unit, used to detect the cross-cycle change trend of key test parameters in the test task, including: P1. After each round of testing is completed, the system extracts the corresponding key test parameters. Furthermore, the system uses test task identifiers and timestamps as indexes to build a parameter time series database; P2. The system periodically performs trend modeling on the parameter time series, using any one of the moving average, linear fitting, or filtering algorithms to determine whether there is a persistent shift in the test parameters. P3. If a certain test parameter shows a change in the same direction in multiple consecutive rounds of testing, and the change in the same direction exceeds the set change threshold, then a "parameter drift anomaly" status label will be generated and attached to the current test task status record.

5. The integrated circuit testing management system according to claim 1, characterized in that, The resource coordination module establishes a resource dependency graph for all test devices and their underlying hardware resources, and marks the mutual exclusion and maximum concurrent usage capacity of each resource. Before scheduling test tasks, the system extracts a list of hardware resources required for the test tasks and cross-compares it with the current resource occupancy status. If multiple test tasks compete for the same exclusive resource and are in the same time slot's scheduling queue, the system determines that there is a risk of resource conflict and generates a conflict flag. For test tasks that pose a risk of conflict, the system will postpone or re-queue them based on factors such as task priority and remaining time in the scheduling window.

6. The integrated circuit testing management system according to claim 1, characterized in that, During the initialization phase, the system establishes a resource mutual exclusion structure for all test equipment resources that can be shared and accessed by multiple test tasks. During the scheduling process, resource occupancy checks are performed on the resources required for each test task. If the concurrency limit has been reached, the task is added to the resource queuing queue, and the queuing order is dynamically adjusted according to its priority, submission time, and remaining scheduling time. When resources are released, the highest priority task in the queue is automatically activated; If the test task queue wait time exceeds the preset period or multiple rounds of scheduling fail, the exception will be reported through the feedback linkage module and the exception handling process will be initiated.

7. The integrated circuit testing management system according to claim 2, characterized in that, In step A3, the system periodically extracts the list of currently executing candidate test tasks from each resource functional area and performs the following fusion and sorting operation: Perform a preliminary global sorting based on the current priority of each test task; If multiple test tasks have the same priority, they are further sorted in ascending order of their remaining schedulable time. For test tasks with remaining scheduling time below the system's set threshold, the system temporarily raises their priority and places them at the top of the sorting sequence; The final result is a cross-partition fusion scheduling sequence containing all resource functional area test tasks; Subsequently, the system transmits the scheduling sequence to the resource coordination module, which performs parallel distribution of test tasks and resource binding operations based on the availability of the test equipment, the mutual exclusion of hardware resources, and the current priority strategy.

8. The integrated circuit testing management system according to claim 2, characterized in that, In step A4, the system iterates through all candidate test tasks in each scheduling cycle to obtain their current remaining schedulable time. And perform the following operations: a41. Regarding the remaining schedulable time Test tasks with less than the minimum remaining scheduling time threshold set by the system are marked as "scheduling urgent" and their current priority is increased. a42. Sort all candidate test tasks in descending order of priority; For test tasks with the same priority, sort them from shortest to longest remaining schedulable time; a43. Construct the sorting results into a test task scheduling sequence that can be executed in this round.

9. The integrated circuit testing management system according to claim 3, characterized in that, In step A2, the system establishes an independent behavior recording unit for each test task and records the corresponding test task's metrics, including execution result sequence, interruption event count, abnormal termination flag, and resource conflict record: When any indicator meets the preset abnormal conditions, the task is marked as "temporarily suspended" and its participation in the current scheduling process is suspended. Tasks not marked as "delayed" are marked as "stable" and participate in task selection and sorting in subsequent scheduling cycles; For tasks in a "suspended state", the system sets an observation period. If no abnormalities are recorded during the observation period, the task's scheduling eligibility is restored. When a recovered test task re-participates in scheduling and reordering for the first time, it is given a priority weight lower than that of a task in a stable state. If the task triggers any abnormal condition again, its observation period will be extended or the exception handling module will take over.

Images