A software-defined seeker signal processing system based on multi-core integration

Abstract

The application relates to the fields of seeker signal processing and heterogeneous multi-chip computing control, and particularly relates to a software-defined seeker signal processing system based on multi-core integration, which comprises the following steps: a task feature extraction step: receiving a front-end input data stream, combining a high-speed serial interface, bus arbitration, cache statistics and node logical states to generate source link health, resource invasion risk, time limit sensitivity and node availability; a service grading step: dividing processing tasks into time window locking type tasks, continuous stable type tasks or degradation tolerance type tasks according to quantitative feature labels and node availability, and binding corresponding control strategy identifiers; a buffer release and resource control step: writing back the classification results to a task queue and sending the task queue to a subsequent module for continuous processing; the application uniformly maps complex hardware states into standardized labels, reduces scheduling link state dislocation, and improves the accuracy and continuity of task scheduling in a multi-core heterogeneous environment.

Description

Technical Field

[0001] This invention relates to the field of seeker signal processing and heterogeneous multi-chip computing control, specifically to a software-defined seeker signal processing system based on multi-chip integration. Background Technology

[0002] Currently, multi-core heterogeneous seeker signal processing systems typically use a master control side to collect front-end input data and distribute tasks to back-end processing chips according to fixed priorities or static rules. When sudden increases in input data flow, fluctuations in inter-chip link status, changes in cache usage, and local anomalies in execution nodes occur simultaneously, existing methods struggle to uniformly quantify and determine tasks based on task time limits, link quality, resource usage, and node availability. This can easily lead to high-time-limit tasks entering restricted nodes and low-quality tasks continuously consuming critical computing power, reducing the stability of task scheduling and resource release under heterogeneous processing architectures. Summary of the Invention

[0003] The purpose of this invention is to provide a software-defined seeker signal processing system based on multi-core integration, which solves the problem that existing methods cannot uniformly quantify and determine tasks by combining task time limits, link quality, resource consumption, and node availability status, leading to high-time-limit tasks entering restricted nodes and low-quality tasks continuously consuming critical computing power. Furthermore, it effectively improves the stability of task scheduling and resource release under heterogeneous processing architectures. Specifically, the technical solution of this invention includes: The task feature extraction module is used to receive the front-end input data stream, parse the hardware registers and node logic status information of the multi-core execution node, and generate quantitative feature labels for the processing tasks corresponding to the front-end input data stream. The quantitative feature labels include at least the source link health, resource encroachment risk, time limit sensitivity, and node availability. The business classification module is used to classify processing tasks into time-window locked tasks, continuous stable tasks, or degradation-tolerant tasks based on quantitative feature labels and node availability, and generate corresponding control policy identifiers. The transition buffer management module is used to calculate the burst level index based on the occupancy depth of the front-end buffer corresponding to the front-end input data stream and the throughput status of the direct memory access controller of the multi-core execution node, and to initiate a pre-activation action to the target multi-core execution node when the burst level index exceeds the preset threshold; and after the pre-activation is completed, to calculate the dynamic release rate based on the resource encroachment risk and task classification results, and to control the release of the front-end input data stream to the back-end processing chip according to the dynamic release rate. The resource orchestration and control module is used to issue grouped action chains to the underlying hardware resources according to the control policy identifier. The grouped action chains include a sequence of control instructions for the direct memory access controller, cache and bus arbitrator of the target multi-core execution node. The hardware status proxy module is used to obtain the underlying physical anomaly status during the execution of processing tasks. Based on the cumulative integral of physical anomaly events within a preset time window, it maps the multi-core execution node to a logical availability status and feeds it back to the task feature extraction module and the resource orchestration control module.

[0004] Optionally, the task feature extraction module, when generating quantized feature labels, is specifically used for: The source link health is quantified based on the error retransmission count and the cumulative cycle of synchronization pulse loss of the high-speed serial interface within the current acquisition period. The risk of resource encroachment is assessed based on the number of congestion wait requests from the bus arbitrator, the instantaneous current change rate of the power supply sample, and the cache hit rate. The time limit sensitivity is quantified based on the processing deadline timestamp in the task descriptor corresponding to the processing task and the current global synchronization timestamp of the system. Node availability is generated based on the logical availability status mapping fed back by the hardware status agent module.

[0005] Optionally, the business hierarchy module is specifically used for: Pre-configure time limit thresholds, health thresholds, and risk thresholds; when the time limit sensitivity is greater than or equal to the preset time limit threshold, the source link health is greater than or equal to the preset health threshold, and the node availability is in an available state, the processing task is divided into a time window locking task and bound to a pass-through policy. When the conditions for time-window locking tasks are not met, and the risk of resource encroachment is less than or equal to the preset risk threshold and the node availability is not in a confirmed failure state, the processing task will be classified as a continuous stable task and bound to a smooth release strategy. The remaining processing tasks are divided into degradation-tolerant tasks and bound to rate limiting or degradation policies.

[0006] Optionally, the transition buffer management module calculates the dynamic release rate in the following way: The transition buffer management module calculates the dynamic release rate based on the base throughput rate, combined with a first adjustment factor that is negatively correlated with the risk of resource encroachment, and a second adjustment factor preset based on the task classification results.

[0007] Optionally, when issuing grouped action chains, the resource orchestration control module is specifically used for: For time-window locked tasks, execute pre-activation action chains, safeguard action chains, or abnormal rollback action chains; For continuous and stable tasks, the single burst length limit parameter of direct memory access is dynamically adjusted according to the resource encroachment risk and node logical state, and the data transfer task is divided into multiple time slices. For degradation-tolerant tasks, a non-critical protocol blocking command is issued to the communication bridging module, or the processing depth mode in the task descriptor is downgraded to a fast coarse screening mode that skips preset high-computing-power-consuming operators. The preset high-computing-power-consuming operators include multi-dimensional feature joint estimation operators and high-order time-frequency transformation operators.

[0008] Optionally, the exception rollback action chain for time-window locked tasks specifically includes: When the hardware status agent module reports that the target execution node has entered a restricted availability state, it immediately migrates the time-window locked tasks that have not yet been executed to the standby node and releases the reserved dedicated direct memory access channel and cache area on the original target execution node.

[0009] Optionally, the hardware status agent module is specifically used for: The cumulative integral of the abnormal events is calculated by weighting the Boolean values ​​of physical anomalies reported by the underlying hardware within a preset sliding time window based on the time decay mechanism. When the cumulative score of abnormal events is less than the warning threshold, it is determined that the underlying jitter is recoverable and the usable status is fed back. When the accumulated score of abnormal events is greater than or equal to the warning threshold and less than the failure threshold, the restricted availability status is fed back, triggering the resource orchestration control module to suspend the allocation of new time-window locked tasks to this node. When the accumulated score of abnormal events is greater than or equal to the failure threshold, feedback confirms the failure status and triggers a global task migration.

[0010] Optionally, the hardware status agent module is also used for: When the cumulative score of abnormal events of a multi-core execution node drops below the warning threshold and remains stable for a period of time exceeding the set recovery window duration, the recovery availability event is proactively reported.

[0011] Optionally, if during the front-end input data stream release process, the hardware status proxy module updates the status of the target multi-core execution node to a restricted available state or a confirmed failure state, the transition buffer management module is used for: Recalculate the dynamic release rate, pause the injection of new tasks into the target multi-core execution node, and return any unreleased processing tasks to the task queue of the business hierarchy module to select a new execution target.

[0012] Optionally, the system is deployed in a heterogeneous computing architecture that includes a main control processing unit, a field-programmable gate array (FPGA), and a digital signal processor (DSP); the task feature extraction module, the service classification module, and the transition buffer management module are deployed on the main control computing side; and the resource orchestration control module and the hardware state proxy module are set in the interface abstraction layer between each processor chip.

[0013] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention uses a task feature extraction module to uniformly quantify and map the source link health, resource encroachment risk, time limit sensitivity, and node availability of the processing task corresponding to the front-end input data stream. It also integrates the link, bus, cache, power supply, and node logical status into standardized labels. This allows the previously scattered hardware status and task attributes to be incorporated into the same scheduling and judgment system, thereby solving the problem that existing technologies cannot uniformly quantify and judge task time limits, link quality, resource usage, and node availability. This improves the consistency and accuracy of task scheduling judgment in multi-core heterogeneous seeker signal processing systems.

[0014] 2. This invention, through a business classification module, categorizes processing tasks into time-window locked tasks, continuous stable tasks, and degradation-tolerant tasks based on time sensitivity, source link health, resource encroachment risk, and node availability. It then binds these tasks to pass-through strategies, smooth release strategies, and rate limiting or degradation strategies, respectively. This prevents high-time-limit tasks from entering restricted nodes and low-quality or high-impact tasks from continuously consuming critical computing power, thereby improving the matching processing capability of different types of tasks in a heterogeneous processing architecture and the overall stability of resource utilization. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application and the prior art, the accompanying drawings used in the description of the embodiments and the prior art will be briefly introduced below: Figure 1 This is a schematic diagram of a software-defined seeker signal processing system based on multi-core integration, provided as an embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0017] In application scenarios where the front-end detection channel continuously outputs echo data streams, the main control processing unit organizes each segment of data to be processed into a task descriptor, and sends it together with the high-speed serial interface register, bus arbitration status, cache statistics, and node logic status returned by the interface abstraction layer into the task feature extraction module. In a multi-core heterogeneous processing environment consisting of a main control processing unit, a field-programmable gate array (FPGA), and a digital signal processor (DSP), the system first generates a unified label for the input task that can be used for scheduling and judgment, then completes the task classification based on this label, and hands the classification result over to the subsequent buffer release and resource control links for further processing. In this embodiment, the task feature extraction module does not directly use the original data stream as the scheduling basis. Instead, it first reads the link, power supply, cache and node status information related to the task within the current system cycle, and generates the source link health, resource encroachment risk, time limit sensitivity and node availability accordingly. The health of the source link is characterized by the error retransmission count of the high-speed serial interface in the current acquisition cycle and the cumulative number of synchronization pulse loss cycles, which is used to distinguish whether the current input data still has the value of continuing to invest in backend computing power for processing; the risk of resource encroachment is characterized by the number of congestion waiting requests in the bus arbitrator, the instantaneous current change rate obtained from power supply sampling, and the cache hit rate, which is used to reflect the degree of occupation of inter-chip bus, cache and power supply margin once the task enters the execution plane; The time limit sensitivity is obtained by comparing the processing deadline timestamp in the task descriptor with the current global synchronization timestamp of the system, and is used to reflect the remaining processing capacity of the task; the node availability is obtained by mapping the logical availability status output by the hardware status agent module, and is used to limit whether the candidate execution node can continue to accept this type of task. To achieve accurate calculation of the aforementioned quantified feature labels, this embodiment uses structured normalized weighted logic to complete the mapping; taking resource encroachment risk as an example, its quantification calculation formula is as follows: in: The quantified risk value of resource encroachment, with a range of values ​​as follows: Dimensionless; This is a sample value representing the current congestion wait request count of the bus arbitrator. The maximum number of allowed requests is set during the system design phase; The instantaneous rate of change of the current sampled by the current power supply; The maximum safe current change rate set for the system; This is a real-time sampled value of the cache hit rate; The ideal cache hit rate set for the system; , , These are preset weight coefficients, and satisfy... In the above formula, based on the negative correlation between cache hit rate and cache breach risk, numerical values ​​are used... Construct a reverse mapping relationship for cache occupancy risk components; The aforementioned preset weighting coefficients are calibrated based on the prior resource bottleneck test results of the system. For example, for an architecture with a prominent inter-chip bus bottleneck, the weights of the congestion waiting request count, instantaneous current change rate, and cache occupancy risk components can be set to 0.5, 0.3, and 0.2, respectively. For different scenarios, the weighting coefficients are calibrated using the analytic hierarchy process (AHP). By constructing a judgment matrix to compare the impact of each risk component on the overall system processing latency, the eigenvector corresponding to the largest eigenvalue is calculated and normalized to obtain a weighting coefficient suitable for the current hardware architecture. , and Values; The maximum allowed number of requests, maximum safe current change rate, ideal hit rate, and subsequent preset time limit thresholds, preset health thresholds, and preset risk thresholds were all determined during the system design phase by injecting extreme full-load workloads into the multi-core execution nodes and measuring and recording their stable operation critical point state data. For example, the preset risk threshold was set to 80% of the quantized risk peak under extreme stable conditions to leave a reasonable safety control margin. The criterion for determining the stable operation critical point is: the highest load state in which the task processing error rate of the multi-core execution node does not exceed the system design tolerance limit and does not trigger a reset anomaly. The conversion formulas for the preset time limit thresholds and preset health thresholds are: the preset time limit threshold is set to the maximum task processing time measured under extreme full-load workload normalized to... The reciprocal of the result is used to set the preset health threshold as the lowest quantified value of the link health measured under the critical point of stable operation. The module calculates the remaining deadline for the task using the following formula. This ensures that the time sensitivity is numerically positively correlated with the urgency of task processing, thus adapting to the subsequent threshold judgment logic: in, This refers to the processing deadline timestamp in the task descriptor. This is the current global synchronization timestamp of the system; To prevent quantization overflow due to task timeouts or extremely early arrivals, boundary limiting calculation rules are set here, with time sensitivity. The formula for segmented calculation is as follows: in: As a time-sensitive quantization, it strictly converges to Range. Dimensionless; The maximum tolerable queuing time of the system, in the dimension of time; The value range is set to 3 to 5 times the typical execution cycle of a single processing task. The calibration method is as follows: Under fault-free, full-load operation, the maximum delay time from when a task enters the front-end buffer to when it is read by the back-end processing chip is calculated, and this maximum delay time is multiplied by a safety redundancy coefficient to obtain the maximum tolerable queuing time of the system; when a task has timed out, i.e. At that time, assign the highest sensitivity value. When there is ample remaining time for the task, assign the lowest sensitivity value. ; The source link health score is also obtained based on the inversion result after normalizing the cumulative error value; in specific calculations, the mathematical expression for calculating the source link health score by the task feature extraction module is as follows: in: The final source link health score has a value range of [value range missing]. Dimensionless; This is the error retransmission count for the current acquisition period; The maximum permissible retransmission threshold is defined by the communication protocol specification; This represents the cumulative number of cycles in which synchronization pulses have been lost. The maximum number of out-of-step tolerance cycles set for the system; the formula includes the arithmetic mean of the bit error attenuation component and the out-of-step attenuation component, which characterizes the overall anomaly rate, and is expressed numerically. Subtracting this anomaly rate achieves the reverse mapping; the communication protocol specification is based on the high-speed serial standard. The value ranges from 10 to 50. The value ranges from 5 to 20 cycles, and its calibration method is as follows: it is set according to the maximum number of retransmissions that the system can maintain without interrupting the link during the bit error rate test. And set according to the maximum number of clock cycles required to recapture after the phase-locked loop loses lock. ; Through these defined logical operation rules, complex hardware states are uniformly mapped to standardized tags in the range of 0 to 1; after each tag is generated, it is written into the scheduling field of the task descriptor and simultaneously sent to the service classification module; through the above mechanism, subsequent classification and control links directly read the same tag record, no longer repeatedly accessing the original register, reducing state misalignment in the scheduling link. Based solely on a one-time sampling when a task enters the queue, there may be situations where the status used in subsequent release stages has changed but the tag has not been updated. To ensure process continuity, the task feature extraction module can reread the node logical status returned by the hardware status proxy module and update the node availability during each system cycle of task queuing, pre-activation, and before release. If a register sample fails to return a valid value in the current period, the system determines whether the task is in its first sampling period of its lifecycle. If so, all quantization feature labels are forcibly initialized to the system's preset conservative safety threshold, where node availability is set to a limited availability state. The conservative safety threshold is a set of preset constants: source link health is 0.5, resource intrusion risk is 1.0, and time sensitivity is 1.0, to ensure that the system performs conservative scheduling based on the highest risk state when valid samples are missing. If not, the corresponding label value from the previous valid period of the task is retained. At the same time, a replacement identifier is added to the task descriptor to avoid the entire hierarchical process from stalling due to a single point of sampling failure. After receiving the above tags, the business classification module classifies the tasks into time-window locked tasks, continuous stable tasks, or degradation-tolerant tasks according to deterministic rules. For tasks with time sensitivity greater than or equal to the preset time threshold, source link health greater than or equal to the preset health threshold, and node availability in an available state, the business classification module determines them as time-window locked tasks and writes them into the pass-through policy identifier, so that such tasks can enter the target processing chip first in the subsequent release process. If a task does not meet the aforementioned conditions, but its resource encroachment risk is less than or equal to the preset risk threshold and the node availability is not in a confirmed failure state, then the task is classified as a continuous stable task and bound with a smooth release strategy so that it can be injected into the execution surface in batches according to a controlled rhythm. Tasks that do not meet the aforementioned two conditions are classified as degradation-tolerant tasks and bound with rate limiting or degradation strategies to prevent low-quality or high-impact tasks from continuing to occupy critical resources. In this implementation, when classifying services, node availability, task time sensitivity, and source link health are used as joint constraints for classification. When a task is close to its time limit but the node availability is no longer available, the service classification module no longer assigns a pass-through strategy to the task, but instead switches to a continuous stable or degradation-tolerant channel so that subsequent buffering and resource control links can rearrange the processing rhythm according to the current acceptable capacity. After the business classification is completed, the classification results and control strategy identifiers are written back to the task queue and simultaneously sent to the transition buffer management module and the resource orchestration control module. The former determines whether to trigger pre-activation and what release rate to use based on the task type, while the latter selects the corresponding underlying control instruction sequence based on the task type. After the front-end input data stream is transformed from its original data form into a processing task object with clear scheduling semantics, subsequent stages continue to run based on the same classification results, without reinterpreting the front-end input state.

[0018] Please see Figure 1 A software-defined seeker signal processing system based on multi-core integration, comprising: The task feature extraction module is used to receive the front-end input data stream, parse the hardware registers and node logic status information of the multi-core execution node, and generate quantitative feature labels for the processing tasks corresponding to the front-end input data stream. The quantitative feature labels include at least the source link health, resource encroachment risk, time limit sensitivity, and node availability. The business classification module is used to classify processing tasks into time-window locked tasks, continuous stable tasks, or degradation-tolerant tasks based on quantitative feature labels and node availability, and generate corresponding control policy identifiers. The transition buffer management module is used to calculate the burst level index based on the occupancy depth of the front-end buffer corresponding to the front-end input data stream and the throughput status of the direct memory access controller of the multi-core execution node, and to initiate a pre-activation action to the target multi-core execution node when the burst level index exceeds the preset threshold; and after the pre-activation is completed, to calculate the dynamic release rate based on the resource encroachment risk and task classification results, and to control the release of the front-end input data stream to the back-end processing chip according to the dynamic release rate. The resource orchestration and control module is used to issue grouped action chains to the underlying hardware resources according to the control policy identifier. The grouped action chains include a sequence of control instructions for the direct memory access controller, cache and bus arbitrator of the target multi-core execution node. The hardware status proxy module is used to obtain the underlying physical abnormal status during the execution of the processing task. Based on the cumulative integral of physical abnormal events within a preset time window, it maps the multi-core execution node to the logical availability status and feeds it back to the task feature extraction module and the resource orchestration control module. The task feature extraction module is specifically used to generate quantized feature labels for: The source link health is quantified based on the error retransmission count and the cumulative cycle of synchronization pulse loss of the high-speed serial interface within the current acquisition period. The risk of resource encroachment is assessed based on the number of congestion wait requests from the bus arbitrator, the instantaneous current change rate of the power supply sample, and the cache hit rate. The time limit sensitivity is quantified based on the processing deadline timestamp in the task descriptor corresponding to the processing task and the current global synchronization timestamp of the system. Node availability is generated based on the logical availability status mapping fed back by the hardware status agent module; The business hierarchy module is specifically used for: Pre-configure time limit thresholds, health thresholds, and risk thresholds; when the time limit sensitivity is greater than or equal to the preset time limit threshold, the source link health is greater than or equal to the preset health threshold, and the node availability is in an available state, the processing task is divided into a time window locking task and bound to a pass-through policy. When the conditions for time-window locking tasks are not met, and the risk of resource encroachment is less than or equal to the preset risk threshold and the node availability is not in a confirmed failure state, the processing task will be classified as a continuous stable task and bound to a smooth release strategy. The remaining processing tasks are divided into degradation-tolerant tasks and bound to rate limiting or degradation policies.

[0019] When a short period of high-density data arrives at the front-end probe channel, multiple input queues in the front-end buffer grow simultaneously within the same system cycle. At this point, if the classification results have been generated but the backend execution node has not yet completed the corresponding preparations, directly sending the task to the field programmable gate array or digital signal processor may easily lead to concentrated contention between inter-chip links, direct memory access channels and buffers. After completing the task classification, the transition buffer management module and the resource orchestration control module adopt different release and execution control methods for different types of tasks; In this embodiment, the transition buffer management module first reads the occupancy depth of the front-end buffer in the main control processing unit's memory and the throughput status of the direct memory access controller to form the burst level index for the current period. The preset threshold here is set based on the stress test results of the system throughput capacity. Specifically, 75% to 85% of the stress-resistant critical burst index measured by the front-end system under full load operation is used as the preset threshold, for example, it is set to 0.8, to ensure that a buffer time for triggering pre-activation actions can be reserved before actual congestion occurs. The judgment criterion for the stress-resistant critical burst index is: when the effective throughput of the direct memory access controller stops increasing linearly and packet loss errors occur during the process of gradually increasing the front-end input data stream injection rate, the arithmetic mean of the front-end buffer occupancy rate and the direct memory access bandwidth occupancy rate of the previous stable period. When the indicator does not exceed the preset threshold, the system does not insert an additional pre-activation stage, but directly enters the release calculation based on the task classification result; when the indicator exceeds the preset threshold, the transition buffer management module first initiates a pre-activation action to the target multi-core execution node, requesting the resource orchestration control module to coordinate the direct memory access controller, cache and bus arbitrator of the target processing chip to enter the bearable state; the specific implementation of this pre-activation action is to write a configuration descriptor to the direct memory access controller of the target node and issue a cache lock release instruction; the condition for the pre-activation to be completed is to receive a hardware response signal from the target node indicating that the channel reservation is successful and the cache is ready; its exit logic is that if no hardware response signal is received within the preset system cycle, a timeout exit is triggered and the pre-activation action is revoked. In the calculation of the aforementioned burst level index, to clarify the congestion quantification rules, the module specifically calculates the arithmetic mean of the front-end buffer occupancy rate and the direct memory access bandwidth occupancy rate to obtain the burst level index. The calculation formula is as follows: in: This is a dimensionless percentage indicator representing the current period's level of suddenness. This represents the current percentage of queue depth occupied by the front buffer. This represents the percentage of bandwidth currently occupied by the direct memory access controller; this formula characterizes the overall congestion level of the data flow channel. Wherein, the basic throughput rate refers to the standard value of the maximum amount of data that can be transferred within a single system cycle in an ideal, congestion-free state using the currently allocated direct memory access channels; after the pre-activation completion confirmation signal is returned, the transition buffer management module begins to calculate the dynamic release rate, and its calculation formula is: in: The dynamic release rate of the target task queue, in terms of data throughput, such as bytes per cycle; The base throughput rate is the standard value of the maximum amount of data that can be transferred in a single cycle of the current direct memory access channel under ideal conditions without congestion. As the first coefficient, through Subtract the resource encroachment risk value generated by the aforementioned quantification To obtain, in order to construct a strict linear negative feedback control over risk; The second coefficient represents the preset level adjustment weight for different task levels. Based on the lookup table mapping rules: when the task is a time-window locked task... For continuous and stable tasks For degradation-tolerant tasks ; After this processing, although different tasks in the same front-end input channel share the same basic throughput rate, the actual pace at which they enter the back-end processing chip is determined by both risk and task classification. This implementation uses the resource encroachment risk as a direct correction parameter for the dynamic release rate, and dynamically feeds back and adjusts the data release rate by utilizing the characteristic changes of bus congestion waiting request number, instantaneous current change rate and cache hit rate. For time-window locked tasks, the second coefficient corresponds to a higher level of adjustment weight, so that such tasks can maintain a higher release rate when the risk is acceptable; for continuous stable tasks, the second coefficient corresponds to an intermediate level of adjustment weight, so that they can still be injected smoothly when the execution surface capability changes; for degradation tolerant tasks, the second coefficient corresponds to a lower level of adjustment weight, so that their occupation is compressed first when the system is under pressure. To prevent tasks from being sent out prematurely before pre-activation is completed, the transition buffer management module temporarily stores the tasks to be released in the corresponding queue of the front-end buffer after initiating the pre-activation action and marks the queue as a waiting state; if no pre-activation completion confirmation signal is received within a continuous system cycle, the queue is kept frozen and no new tasks are written to the target node. Meanwhile, to prevent buffer queue deadlock caused by permanent loss of response signals due to unresponsive underlying hardware or packet loss in bus communication, the transitional buffer management module simultaneously enables a hardware timeout timer. If the queue freeze state continues for more than the preset maximum waiting tolerance period, the system immediately triggers a timeout escape interrupt, forcibly unfreezes the waiting queue, and issues a cancellation signal to release the initiated pre-activation request. Upon receiving the cancellation signal, the underlying resource orchestration and control module must truncate the ongoing direct memory access channel reservation action and forcibly clear the cache lock, and return a cancellation completion confirmation frame to the main control computing side; the main control side transition buffer management module must receive this confirmation frame before it can officially unfreeze the queue; and return the delayed pending tasks to the business classification module to rematch available nodes; Until the next state update result is available; the above mechanism keeps the front-end task in a recyclable buffer area, ensuring that the control link has a closed-loop jump-out mechanism, avoiding the additional overhead caused by the rollback operation after it enters the execution plane; After receiving the control policy identifier sent by the service classification module, the resource orchestration control module issues grouped action chains according to the task type. For time window locked tasks, the resource orchestration control module first executes the pre-activation action chain to reserve direct memory access channels and cache areas for the target processing chip. After the task is released, a protection action chain is executed to ensure that the first frame of data is protected when it enters the buffer and bus arbitration path. This implementation establishes a task release and resource exit mechanism after the underlying node state changes by configuring an abnormal rollback action chain. When the hardware status agent module reports that the target execution node has entered a restricted availability state, the resource orchestration control module immediately migrates the time-window locked tasks that have not yet been executed to the standby node and releases the reserved dedicated direct memory access channel and cache area on the original target execution node. The migrated tasks retain the original task descriptors and classification identifiers, and only update the target node information, so that the subsequent release and execution processes can continue to use the previously formed scheduling results; For continuous and stable tasks, the resource orchestration control module does not adopt the exclusive protection method for time window locking tasks. Instead, it dynamically adjusts the single burst length limit parameter of direct memory access based on the risk of resource encroachment and the logical state of nodes, dividing the data transfer that could have been completed in one go into multiple time slices. Specifically, for continuous and stable tasks, the resource orchestration control module dynamically adjusts the burst length limit parameter for direct memory access, and its segmented control formula is as follows: in: The burst length limit parameter for the current period, in units of data length, such as words or bytes; The maximum hardware burst length value preset for the system; This represents the quantified risk of resource encroachment. The logical availability status of the target node; when the node is in a limited availability state, the limiting reference is forcibly reduced to half, thereby achieving dynamic current limiting of the continuous stable task bus usage; The system limits the amount of continuous data transported in a single burst by dynamically adjusting the burst length limiting parameter, and discretely distributes the bus usage of continuous and stable tasks across multiple system cycles. For degradation-tolerant tasks, the resource orchestration control module executes non-critical protocol blocking or processing depth degradation based on the current control strategy identifier. The former reduces additional interactions not directly related to the main processing link by issuing non-critical protocol blocking instructions to the communication bridging logic protocol layer configured inside the field-programmable gate array or digital signal processor. The communication bridging module is a hardware communication interface logic developed based on a universal asynchronous transceiver or serial peripheral interface protocol. Its data input is connected to the system bus inside the field-programmable gate array, and its data output is connected to the physical pins of external debugging equipment. Non-critical protocols not directly related to the main processing link include: the system log upload protocol for device background monitoring, and the debug handshake protocol for internal status detection; the specific execution logic of the non-critical protocol blocking instruction is: by setting the port enable register corresponding to the above non-critical protocol in the communication bridging logic protocol layer to a low level, the communication bridging module is forced to discard the corresponding port's transmit and receive data packets at the hardware level, thereby immediately releasing the transmission bandwidth of the inter-chip link. The latter modifies the processing depth mode flag in the task descriptor, enabling the target multi-core execution node to implement algorithm bypass control when scheduling and parsing the task: by switching the data flow selector of the data path, the multi-dimensional feature joint estimation operator and the high-order time-frequency transformation operator in the original processing flow are bypassed, and the front-end data path is directly connected to the back-end energy threshold comparison operator, reducing the original processing process to a fast coarse screening mode that only outputs the result of whether the target exists or not, and clearing the backlog of tasks according to the preset minimum computing power consumption mode; If the degradation instruction corresponding to the degradation-tolerant task is not successfully written within the current system cycle, the task remains in the rate-limiting queue and is not promoted to a higher-level channel, thereby avoiding the situation where the task execution depth is inconsistent with the scheduling expectation when the control state is inconsistent. After the above processing, the transition buffer management module outputs a release sequence after rate correction, and the resource orchestration control module outputs a hardware control instruction sequence corresponding to the task category. The two work together to the back-end processing chip, so that high-time-limit tasks, regular stable tasks and degradeable tasks can enter execution in different ways within the same multi-core architecture.

[0020] The transition buffer management module calculates the dynamic release rate in the following way: The transition buffer management module calculates the dynamic release rate based on the base throughput rate, combined with a first adjustment factor that is negatively correlated with the risk of resource encroachment, and a second adjustment factor preset based on the task classification results. When issuing grouped action chains, the resource orchestration control module is specifically used for: For time-window locked tasks, execute pre-activation action chains, safeguard action chains, or abnormal rollback action chains; For continuous and stable tasks, the single burst length limit parameter of direct memory access is dynamically adjusted according to the resource encroachment risk and node logical state, and the data transfer task is divided into multiple time slices. For degradation-tolerant tasks, a non-critical protocol blocking command is issued to the communication bridging module, or the processing depth mode in the task descriptor is downgraded to a fast coarse screening mode that skips preset high-computing-power-consuming operators. The preset high-computing-power-consuming operators include multi-dimensional feature joint estimation operators and high-order time-frequency transformation operators. The specific rollback action chain for time-window locked tasks includes: When the hardware status agent module reports that the target execution node has entered a restricted availability state, it immediately migrates the time-window locked tasks that have not yet been executed to the standby node and releases the reserved dedicated direct memory access channel and cache area on the original target execution node.

[0021] When multiple execution nodes in the backend process the seeker echo task in parallel, the underlying hardware may experience short-term anomalies such as link retry, local back voltage, temperature rise exceeding the limit, or power supply fluctuation. If these exceptions are received directly by the main control unit one after another and immediately trigger task reordering, the task queue will change frequently, and the front-end buffer will also need to be repeatedly adjusted to release targets. The system sets up an interface abstraction layer between each processor chip to uniformly converge low-level exceptions, and uses the converged logical state to restrict new task injection, trigger migration, and restore node acceptance capabilities. In this embodiment, the hardware status agent module continuously collects physical anomaly Boolean values ​​reported by the underlying hardware from each execution node; after the Boolean value enters a preset sliding time window in units of system cycles, it is exponentially weighted and summed by a time decay function to form the cumulative integral of the anomaly event; The specific attenuation weighting calculation logic is as follows: traverse the Boolean values ​​of physical anomalies in each sampling period in order from farthest to nearest within the time window. Specifically, the underlying physical anomalies include link retry state variables. Local back pressure state quantity Temperature rise exceeding the limit state quantity and power supply fluctuation state quantities Physical anomaly Boolean value The mapping calculation formula is: in, The logical OR operator; when the current sampled value of any of the above underlying physical anomalies is logically true, the output physical anomaly Boolean value within the current system cycle. If all abnormal sampled values ​​are logically false, then the value is 1. =0; The hardware status proxy module performs an exponentially weighted summation of the Boolean values ​​of physical anomalies within a preset sliding time window. The formula for calculating the cumulative integral of the anomaly events is as follows: in: Accumulate points for abnormal events in the current system; The preset sliding time window length and number of cycles; A non-negative integer index representing the historical span, corresponding to the current system cycle. The previous historical cycle corresponds to And so on; For the historical span of The boolean value of physical anomalies output within the period, taking values ​​of or ; The time decay factor is a fixed value, and its range is set to... ; This formula introduces a time decay factor, causing the weights of anomalous features in each period to decrease positively correlated with the span from the current period, resulting in an exponential decay of the product of anomalous feature quantities across different historical periods. The Boolean value records within each period are directly multiplied by a decay factor that is a fixed constant between 0 and 1. of The power of, where, A non-negative integer index representing the historical span, corresponding to the current system cycle. for The previous historical cycle corresponds to for And so on; the product of all cycles within the current window is summed to obtain the integral value; Through the above exponential weighted summation calculation, the integral increment generated by a single physical anomaly decreases exponentially as the historical span of the system cycle increases. The above mechanism is used to distinguish between occasional single anomalies and continuous anomalies: the weight of anomalies that are far from the current period gradually decreases in the integral, while anomalies that occur continuously close to the current period maintain a high cumulative value; the hardware status agent module does not send single anomalies to the main control computing side as is, but maps the multi-core execution node to an available state, a limited available state, or a confirmed failure state based on the relationship between the cumulative integral of the anomaly event and the warning threshold and the failure threshold. The specific values ​​of the warning threshold and the failure threshold are calculated and calibrated based on the convergence characteristics of the aforementioned time decay function: using the decay factor... Taking 0.8 as an example, according to the formula for the sum of a geometric series: in: For continuous occurrence The theoretical maximum value of the cumulative integral during an anomaly in a given period; The term is the number of terms in the geometric sequence, which in this formula represents the total number of system cycles in which anomalies occur consecutively; The system sets the warning threshold to 2.4, corresponding to the continuous abnormal integral magnitude over 3 consecutive cycles, with a theoretical maximum value of 2.44; and sets the failure threshold to 3.6, corresponding to the continuous abnormal integral magnitude over 6 consecutive cycles, with a theoretical maximum value of 3.689, thereby quantifying the distinction between occasional jitter and substantial failure; the recovery window duration is determined based on the typical number of cycles required for link re-establishment or hardware reset in the underlying communication protocol of the system, such as setting it to 100 system cycles; When the cumulative score of abnormal events is less than the warning threshold, the hardware status agent module determines that the node is still within the recoverable jitter range and feeds back the available status to the task feature extraction module and the resource orchestration control module. At this time, the business classification module can still assign tasks that meet the conditions to the node, and the transition buffer management module will not suspend the release of tasks separately due to this anomaly. If the accumulated score of the anomaly event reaches or exceeds the warning threshold but is still less than the failure threshold, the hardware status agent module will report the restricted availability status. After receiving this status, the resource orchestration control module will suspend the allocation of new time-window locked tasks to the node. When updating node availability in the next round, the task feature extraction module will also mark the node as restricted availability to prevent subsequent high-time-limit tasks from entering again. If the accumulated score of abnormal events reaches or exceeds the failure threshold, the hardware status agent module will report a confirmation of the failure status and trigger a global task migration, so that the processing tasks originally planned to be sent to this node will be taken over by other available nodes. When performing task takeover and allocation, the main control computing side reads the quantitative feature tags of other nodes in the current system in real time, filters out the set of standby nodes whose availability is available, compares the resource encroachment risk value of each standby node, and prioritizes dispatching tasks to the available node with the lowest current resource encroachment risk value. This implementation is configured with an anomaly recovery determination mechanism based on continuous and stable duration. When the hardware status agent module detects that the cumulative score of an anomaly event of a multi-core execution node drops below the warning threshold and remains continuously stable for a duration exceeding the set recovery window duration, it actively reports a recovery available event. After receiving the event, the business classification module does not immediately restore the node's ability to accept all tasks at once. Instead, it first allows the node to re-enter the normal classification and judgment process, so that it can gradually accept and process tasks when the label conditions are met. This can avoid the node taking on too many tasks as soon as it exits the abnormal state and triggering the restricted state again. Even after the front-end input data stream has started to be released, the node status may still change. If the hardware status proxy module updates the status of the target multi-core execution node to a restricted available status or a confirmed failure status during this process, the transition buffer management module immediately recalculates the dynamic release rate and suspends the injection of new tasks into the target multi-core execution node. Processing tasks that have not yet been released no longer remain in the sending queue corresponding to the original target node, but are returned to the task queue of the business classification module, and the execution target is reselected according to the principle of prioritizing the lowest resource encroachment risk. Tasks that are being released and those that have not yet been released need to be handled separately: tasks that have already entered the execution plane are determined by the resource orchestration control module to decide whether to continue, limit, or migrate based on the current node status; tasks that have not yet entered the execution plane are directly returned to the hierarchical stage to rematch available nodes, thereby reducing invalid injections; To ensure the stable operation of the above-mentioned state processing links in the system, in this embodiment, the task feature extraction module, business classification module and transition buffer management module are deployed on the main control computing side, and the main control processing unit uniformly maintains the task queue, classification results and release records. The resource orchestration control module and hardware status proxy module are located in the interface abstraction layer between each processor chip. The interface abstraction layer is a firmware driver running inside the heterogeneous multi-core interconnect bus controller. This deployment structure enables it to receive the underlying physical abnormal status nearby and write control instructions directly to the direct memory access controller, cache and bus arbitrator. With this arrangement, the main control computing side is responsible for forming task judgment results and release decisions, the interface abstraction layer is responsible for receiving the underlying execution status and implementing control actions, and the front and back sides are connected through node logical status, control strategy identifiers and task migration information. If the interface abstraction layer does not return a new status record to the main control computing side within a certain system cycle, the main control computing side will continue to use the node logical state of the previous valid cycle for conservative processing and maintain the current pause or rate limiting decision until a new valid state is received; this can avoid the node being re-entered into high-time-limit tasks under unknown conditions due to the interruption of status feedback.

[0022] The hardware status agent module is specifically used for: The cumulative integral of the abnormal events is calculated by weighting the Boolean values ​​of physical anomalies reported by the underlying hardware within a preset sliding time window based on the time decay mechanism. When the cumulative score of abnormal events is less than the warning threshold, it is determined that the underlying jitter is recoverable and the usable status is fed back. When the accumulated score of abnormal events is greater than or equal to the warning threshold and less than the failure threshold, the restricted availability status is fed back, triggering the resource orchestration control module to suspend the allocation of new time-window locked tasks to this node. When the accumulated score of abnormal events is greater than or equal to the failure threshold, feedback is provided to confirm the failure status and trigger a global task migration. The hardware status agent module is also used for: When the cumulative score of abnormal events of a multi-core execution node drops below the warning threshold and remains stable for a period of time exceeding the set recovery window duration, the recovery availability event is proactively reported. If, during the front-end input data stream release process, the hardware status proxy module updates the status of the target multi-core execution node to a restricted available state or a confirmed failure state, the transition buffer management module is used for: Recalculate the dynamic release rate, pause the injection of new tasks into the target multi-core execution node, and return the unreleased processing tasks to the task queue of the business hierarchy module to reselect the execution target; The system is deployed in a heterogeneous computing architecture that includes a main control processing unit, a field-programmable gate array (FPGA), and a digital signal processor (DSP). The task feature extraction module, the service classification module, and the transition buffer management module are deployed on the main control computing side. The resource orchestration control module and the hardware state proxy module are set in the interface abstraction layer between the processor chips.

[0023] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A software-defined seeker signal processing system based on multi-core integration, characterized in that, include: The task feature extraction module is used to receive the front-end input data stream, parse the hardware registers and node logic status information of the multi-core execution node, and generate a quantitative feature label for the processing task corresponding to the front-end input data stream. The quantitative feature label includes at least the source link health, resource encroachment risk, time limit sensitivity, and node availability. The business classification module is used to classify the processing tasks into time-window locked tasks, continuous stable tasks, or degradation-tolerant tasks based on the quantized feature labels and node availability, and generate corresponding control strategy identifiers. The transition buffer management module is used to calculate the burst level index based on the occupancy depth of the front-end buffer corresponding to the front-end input data stream and the throughput status of the direct memory access controller of the multi-core execution node, and to initiate a pre-activation action to the target multi-core execution node when the burst level index exceeds a preset threshold; and after the pre-activation is completed, to calculate the dynamic release rate based on the resource encroachment risk and task classification results, and to control the release of the front-end input data stream to the back-end processing chip according to the dynamic release rate. The resource orchestration and control module is used to issue grouped action chains to the underlying hardware resources according to the control policy identifier. The grouped action chains include a sequence of control instructions for the direct memory access controller, cache and bus arbitrator of the target multi-core execution node. The hardware status proxy module is used to obtain the underlying physical abnormal status during the execution of the processing task. Based on the cumulative integral of physical abnormal events within a preset time window, the multi-core execution node is mapped to a logical availability status and fed back to the task feature extraction module and the resource orchestration control module.

2. The software-defined seeker signal processing system based on multi-core integration according to claim 1, characterized in that, When generating the quantized feature labels, the task feature extraction module is specifically used for: The source link health is quantified based on the error retransmission count and the cumulative period of synchronization pulse loss of the high-speed serial interface within the current acquisition cycle. The resource encroachment risk is assessed based on the number of congestion wait requests from the bus arbitrator, the instantaneous current change rate of the power supply sample, and the cache hit rate. The time limit sensitivity is quantified based on the processing deadline timestamp in the task descriptor corresponding to the processing task and the current global synchronization timestamp of the system. The node availability is generated based on the logical availability status mapping fed back by the hardware status agent module.

3. The software-defined seeker signal processing system based on multi-core integration according to claim 1, characterized in that, The business classification module is specifically used for: Pre-configure time limit thresholds, health thresholds, and risk thresholds; when the time limit sensitivity is greater than or equal to the preset time limit threshold, the source link health is greater than or equal to the preset health threshold, and the node availability is in an available state, the processing task is divided into a time window locking task and bound to a pass-through policy. When the conditions for time-window locking tasks are not met, and the risk of resource encroachment is less than or equal to the preset risk threshold and the node availability is not in a confirmed failure state, the processing task will be classified as a continuous stable task and bound to a smooth release strategy. The remaining processing tasks are divided into degradation-tolerant tasks and bound to rate limiting or degradation policies.

4. The software-defined seeker signal processing system based on multi-core integration according to claim 1, characterized in that, The specific method by which the transitional buffer management module calculates the dynamic release rate is as follows: The transition buffer management module calculates the dynamic release rate based on the base throughput rate, combined with a first adjustment factor negatively correlated with the resource encroachment risk, and a second adjustment factor preset based on the task classification results.

5. The software-defined seeker signal processing system based on multi-core integration according to claim 1, characterized in that, When issuing the grouped action chain, the resource orchestration control module is specifically used for: For time-window locked tasks, execute pre-activation action chains, safeguard action chains, or abnormal rollback action chains; For continuous and stable tasks, the single burst length limit parameter of direct memory access is dynamically adjusted according to the resource encroachment risk and node logical state, and the data transfer task is divided into multiple time slices. For degradation-tolerant tasks, a non-critical protocol blocking command is issued to the communication bridging module, or the processing depth mode in the task descriptor is downgraded to a fast coarse screening mode that skips preset high-computing-power-consuming operators. The preset high-computing-power-consuming operators include multi-dimensional feature joint estimation operators and high-order time-frequency transformation operators.

6. The software-defined seeker signal processing system based on multi-core integration according to claim 5, characterized in that, The specific abnormal rollback action chain for time-window locked tasks includes: When the hardware status agent module reports that the target execution node has entered a restricted availability state, it immediately migrates the time-window locked tasks that have not yet been executed to the standby node and releases the reserved dedicated direct memory access channel and cache area on the original target execution node.

7. The software-defined seeker signal processing system based on multi-core integration according to claim 1, characterized in that, The hardware status proxy module is specifically used for: The cumulative integral of the abnormal events is calculated by weighting the Boolean values ​​of physical anomalies reported by the underlying hardware within a preset sliding time window based on the time decay mechanism. When the cumulative integral of the abnormal event is less than the warning threshold, it is determined that the underlying recovery jitter is available and the usable status is fed back. When the cumulative score of the abnormal event is greater than or equal to the warning threshold and less than the failure threshold, the restricted availability status is fed back, triggering the resource orchestration control module to suspend the allocation of new time-window locked tasks to the node. When the accumulated score of the abnormal event is greater than or equal to the failure threshold, feedback confirms the failure status and triggers a global task migration.

8. A software-defined seeker signal processing system based on multi-core integration according to claim 7, characterized in that, The hardware status proxy module is also used for: When the cumulative score of abnormal events of a multi-core execution node drops below the warning threshold and remains stable for a period of time exceeding the set recovery window duration, the recovery availability event is proactively reported.

9. The software-defined seeker signal processing system based on multi-core integration according to claim 1, characterized in that, If, during the front-end input data stream release process, the hardware status proxy module updates the status of the target multi-core execution node to a restricted available state or a confirmed failure state, the transition state buffer management module is used for: The dynamic release rate is recalculated, the injection of new tasks into the target multi-core execution node is paused, and the unreleased processing tasks are returned to the task queue of the business hierarchy module to select a new execution target.

10. A software-defined seeker signal processing system based on multi-core integration according to claim 1, characterized in that, The system is deployed in a heterogeneous computing architecture that includes a main control processing unit, a field-programmable gate array (FPGA), and a digital signal processor (DSP). The task feature extraction module, the service classification module, and the transition buffer management module are deployed on the main control computing side. The resource orchestration control module and the hardware state proxy module are located in the interface abstraction layer between the processor chips.

Images