An adaptive data distribution method and system based on an FPGA heterogeneous computing platform

Abstract

The application provides a kind of adaptive data distribution method and system based on FPGA heterogeneous computing platform, it is related to heterogeneous computing and data scheduling technical field, the method includes: the characteristic data of real-time acquisition computing task and the load data of each computing unit in platform, is analyzed and predicted by the preset heterogeneous computing feature analysis model jointly, output task classification result and its initial performance estimate on each computing unit;The computing unit at least includes FPGA, CPU and GPU;Based on task classification and initial performance estimate, data distribution scheme for determining the target computing unit and transmission path of data is generated by dynamic weight calculation;Execute data distribution scheme, generate task execution state information by scheduling data and triggering calculation.The application can realize the dynamic allocation of data and strategy adaptive optimization of complex computing task, improve platform computing efficiency, reduce delay.

Description

Technical Field

[0001] This invention relates to the field of heterogeneous computing and data scheduling technology, and in particular to an adaptive data allocation method and system based on an FPGA heterogeneous computing platform. Background Technology

[0002] With the large-scale application of technologies such as big data processing, artificial intelligence inference, and high-performance real-time computing, a single computing architecture can no longer simultaneously address computing power, power consumption, and scenario adaptability. Heterogeneous computing platforms integrating FPGAs, CPUs, and GPUs have become the mainstream hardware solution for handling complex computing tasks due to the synergistic advantages of multiple architectures. Data allocation, as the core link connecting various heterogeneous computing units and scheduling task execution, participates in determining the platform's resource utilization, computing latency, and system energy efficiency, and is a key means to ensure the efficient and stable operation of heterogeneous platforms.

[0003] Current traditional heterogeneous computing data allocation schemes mostly suffer from the following technical defects: data allocation strategies rely solely on static preset rules and offline performance prediction models, lacking a closed-loop feedback mechanism based on actual computational execution results. They cannot dynamically and adaptively correct performance prediction models and allocation rules based on performance deviations generated during real-time operation. This results in static rules and offline models failing to adapt to the characteristics of computational tasks and the dynamic changes in the real-time load of each computing unit. Initial performance predictions and actual execution results exhibit continuous discrepancies, easily leading to load imbalances among FPGAs, CPUs, and GPUs, and causing long-term deviations in task execution latency and platform energy efficiency ratios from expectations. Furthermore, performance prediction deviations cannot be corrected through real-time data iteration; the deviations accumulate as tasks run, causing data allocation strategies to continuously deviate from the platform's optimal state, making it difficult to continuously improve the collaborative computing efficiency of heterogeneous resources. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide an adaptive data allocation method and system based on an FPGA heterogeneous computing platform. Through real-time performance monitoring, deviation analysis and dynamic strategy adjustment, the data allocation is optimized in a closed loop, which solves the problems of load imbalance and performance deviation accumulation caused by static allocation.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: In a first aspect, an adaptive data allocation method based on an FPGA heterogeneous computing platform is provided, the method comprising: The system collects feature data of computing tasks and load data of each computing unit in the platform in real time, performs joint analysis and prediction through a pre-set heterogeneous computing feature analysis model, and outputs task classification results and their initial performance estimates on each computing unit; the computing unit includes at least FPGA, CPU and GPU. Based on task classification and initial performance estimates, a data allocation scheme is generated through dynamic weight calculation to determine the target computing units and transmission paths of the data. The execution data allocation scheme is implemented by scheduling data and triggering calculations to generate task execution status information; Monitor the calculation process, collect actual performance data and compare it with the initial performance estimate to generate a multi-dimensional performance deviation vector; Based on the multidimensional performance deviation vector, for each computing unit and its corresponding task classification, a set of core performance measured values ​​in the current execution cycle are dynamically extracted to form a series of heterogeneous performance feature anchors. A series of heterogeneous performance characteristic anchor points are mapped to a strategy analysis plane with computational delay and energy efficiency ratio as coordinate axes, and a dynamic strategy feature domain is constructed based on the distribution density. Calculate the centroid of the dynamic policy feature domain and solve for the policy drift vector of the centroid relative to the preset platform equilibrium reference axis; calculate and generate the policy correction factor based on the direction and magnitude of the policy drift vector using a predefined policy response function. Based on the strategy correction factor, the preset parameters of the heterogeneous computing feature parsing model and the rules for dynamic weight calculation are adaptively adjusted to update the data allocation strategy.

[0006] Secondly, an adaptive data allocation system based on an FPGA heterogeneous computing platform includes: The feature acquisition and prediction module is used to acquire feature data of computing tasks and load data of each computing unit in the platform in real time, perform joint analysis and prediction through a pre-set heterogeneous computing feature parsing model, and output task classification results and their initial performance estimates on each computing unit; the computing unit includes at least FPGA, CPU and GPU; The allocation scheme generation module is used to generate a data allocation scheme for determining the target computing units and transmission paths of data based on task classification and initial performance estimates through dynamic weight calculation. The scheme execution and status acquisition module is used to execute the data allocation scheme, and generate task execution status information by scheduling data and triggering calculations. The deviation analysis module is used to monitor the calculation process, collect actual performance data and compare it with the initial performance estimate, and generate a multi-dimensional performance deviation vector. Based on the multi-dimensional performance deviation vector, for each calculation unit and its corresponding task classification, a set of core performance measured values ​​in the current execution cycle is dynamically extracted to form a series of heterogeneous performance feature anchor points. The strategy feature domain construction module is used to map a series of heterogeneous performance feature anchors to a strategy analysis plane with computational delay and energy efficiency ratio as coordinate axes, and construct a dynamic strategy feature domain based on the distribution density. The correction factor generation module is used to calculate the centroid of the dynamic policy feature domain and solve the policy drift vector of the centroid relative to the preset platform equilibrium reference axis; based on the direction and magnitude of the policy drift vector, the policy correction factor is generated by calculating the predefined policy response function. The strategy update module is used to adaptively adjust the preset heterogeneous computing feature parsing model parameters and the dynamic weight calculation rules according to the strategy correction factor, so as to update the data allocation strategy.

[0007] The above-described solution of the present invention has at least the following beneficial effects: By employing real-time acquisition of relevant data from computing tasks and various computing units of FPGA, CPU, and GPU, and jointly analyzing and predicting through a heterogeneous computing feature analysis model, combined with dynamic weighting to generate a data allocation scheme, and then constructing feature anchors and dynamic policy feature domains through performance monitoring and deviation analysis, calculating policy drift vectors to generate correction factors, and adaptively adjusting model parameters and weight rules through a closed-loop technology, this approach overcomes the technical problems of traditional data allocation relying on static rules and offline models without closed-loop feedback correction, resulting in load imbalance, accumulated performance deviations, and low efficiency of heterogeneous resource collaboration. This achieves closed-loop optimization of data allocation, improves platform resource utilization, reduces computing latency, optimizes energy efficiency, and ensures the efficient and stable operation of the FPGA heterogeneous computing platform. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating an adaptive data allocation method based on an FPGA heterogeneous computing platform, provided by an embodiment of the present invention.

[0009] Figure 2 This is a schematic diagram of an adaptive data allocation system based on an FPGA heterogeneous computing platform provided by an embodiment of the present invention. Detailed Implementation

[0010] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0011] like Figure 1 As shown, an embodiment of the present invention proposes an adaptive data allocation method based on an FPGA heterogeneous computing platform, the method comprising the following steps: Step 1: Collect feature data of computing tasks and load data of each computing unit in the platform in real time, perform joint analysis and prediction through a pre-set heterogeneous computing feature analysis model, and output task classification results and their initial performance estimates on each computing unit; the computing unit includes at least FPGA, CPU and GPU. Step 2: Based on task classification and initial performance estimates, a data allocation scheme is generated through dynamic weight calculation to determine the target computing units and transmission paths for the data. Step 3: Execute the data allocation scheme, generate task execution status information by scheduling data and triggering calculations; Step 4: Monitor the calculation process, collect actual performance data and compare it with the initial performance estimate to generate a multi-dimensional performance deviation vector; Step 5: Based on the multidimensional performance deviation vector, for each computing unit and its corresponding task classification, dynamically extract a set of core performance measured values ​​in the current execution cycle to form a series of heterogeneous performance feature anchor points. Step 6: Map a series of heterogeneous performance characteristic anchor points to a strategy analysis plane with computational delay and energy efficiency ratio as coordinate axes, and construct a dynamic strategy feature domain based on the distribution density. Step 7: Calculate the centroid of the dynamic policy feature domain and solve for the policy drift vector of the centroid relative to the preset platform equilibrium reference axis; calculate and generate the policy correction factor based on the direction and magnitude of the policy drift vector using the predefined policy response function. Step 8: Based on the strategy correction factor, adaptively adjust the preset heterogeneous computing feature parsing model parameters and the dynamic weight calculation rules to update the data allocation strategy.

[0012] In this embodiment of the invention, the method can adapt to the dynamic operating status of heterogeneous computing platforms such as FPGA, CPU, and GPU in real time. The method can accurately predict task performance, reasonably determine target computing units and data transmission paths, and improve data scheduling and task execution efficiency. Through real-time performance monitoring and deviation analysis, it can effectively capture performance differences, generate corresponding strategy correction factors, adaptively iteratively optimize feature parsing model parameters and dynamic weight rules, avoid the continuous accumulation of performance deviations, balance the load of each computing unit, improve the utilization rate of heterogeneous resources, reduce computing latency, optimize the system energy efficiency ratio, and ensure the long-term efficient and stable operation of the heterogeneous computing platform.

[0013] In a preferred embodiment of the present invention, step 1 above may include: Step 1.1: Real-time acquisition of the original description information of the computing task to be processed and the original status data reported by each computing unit in the platform, generating the original task dataset and the original platform dataset. The computing units include at least FPGA, CPU, and GPU. Specifically, the heterogeneous computing platform adopted in this invention is a collaborative computing architecture integrating multiple types of computing units such as FPGA, CPU, and GPU. Its core purpose is to leverage the complementary advantages of different computing units to balance the real-time performance, computing power requirements, and energy efficiency of computing tasks, adapting to the diverse needs of complex scenarios such as AI inference, real-time big data computing, and high-frequency signal processing. Each computing unit has a clear division of labor and works collaboratively. Specifically, the CPU, as the general computing and overall coordination core of the platform, is mainly responsible for overall task scheduling, collaborative management and control of each computing unit, and general data processing. It has the advantages of strong compatibility and flexible scheduling. The GPU is good at large-scale parallel computing and is mainly adapted to computationally intensive tasks with high data parallelism. It can quickly process batch repetitive computing operations. The FPGA, as a programmable logic device, has the characteristics of low latency, high energy efficiency, and customizable hardware. It is specifically adapted to tasks with high real-time requirements and relatively fixed computing processes. It is the core support unit for realizing low-latency data acquisition and fast feature parsing.

[0014] The heterogeneous computing platform utilizes its built-in multi-channel data acquisition interface to acquire raw description information of computing tasks in real time through parallel acquisition. Simultaneously, it receives raw status data proactively pushed by the FPGA, CPU, and GPU computing units within the platform via status reporting protocols. All acquired data is synchronized and aligned using millisecond-level time stamps. The raw description information of the computing tasks includes task type (e.g., AI inference, big data computing, high-frequency signal processing), computational load (measured in floating-point operations), data transmission requirements (e.g., data transmission bandwidth, transmission direction), and task priority (divided into 0 to 5 levels). The raw status data reported by each computing unit includes current load rate as a percentage of computing power, idle resource quantity as the number of available computing cores / storage capacity, power consumption in watts, and response latency in milliseconds. The collected, scattered raw information is first categorized by task attribute dimension and computing unit status dimension. Invalid and missing data are removed, and then aggregated into a dedicated data buffer using a unified data format. This results in a complete and time-consistent raw task dataset and a raw platform dataset, providing accurate and reliable basic data support for subsequent data processing.

[0015] Step 1.2 involves normalizing and vectorizing the original task dataset and the original platform dataset to generate standardized task feature vectors and platform state vectors. Specifically, this includes: firstly, mapping the numerical data such as computational load, data transmission requirements, and response latency in the original task dataset to [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, 18, 19 ..., [1] interval, eliminating the difference in units between different indicators and unifying the numerical range; for non-numerical data such as task type and priority, one-hot encoding is used to complete the category conversion, such as encoding AI inference tasks as [1] interval. , 0 , 0], 5-level priority is encoded as [0] , 0 , 0 , 0 , 0 , [1]; Subsequently, all preprocessed task-related data are integrated according to a preset dimension (e.g., fixed at 64 dimensions) and transformed into fixed-dimensional task feature vectors. The vector dimensions strictly match the dimension requirements of the input layer of the heterogeneous computing feature parsing model. At the same time, the same min-max normalization method is used to process the numerical data such as load rate and power consumption of each computing unit in the original platform dataset. The computing unit types FPGA, CPU, and GPU are also converted by one-hot encoding and then transformed into a fixed-dimensional 64-dimensional platform state vector with the same format as the task feature vector. After preprocessing, the dimensions, numerical ranges, and formats of the two types of vectors are verified to ensure that they are fully compatible with the input requirements of the subsequent heterogeneous computing feature parsing model.

[0016] Step 1.3: Input the task feature vector and platform state vector into the feature extraction layer of the pre-set heterogeneous computing feature parsing model; extract the parallelism and computational density features of the task and the heterogeneous resource availability features of the platform through the feature extraction layer to generate a fused feature vector. Specifically, this includes: inputting the task feature vector and platform state vector into the feature extraction layer of the pre-set heterogeneous computing feature parsing model; the pre-set heterogeneous computing feature parsing model is based on an improved CNN-Transformer hybrid architecture, and its architecture selection is mainly based on the following considerations: complementarity of feature extraction. CNN is good at extracting local structured features of task and platform state, such as parallelism, computational density, and resource availability, while Transformer can effectively capture global dependencies between features through self-attention mechanism, such as the correlation between task type and computing unit performance. The combination of the two can improve the comprehensiveness and accuracy of feature expression; adaptability to FPGA platform. FPGA has high parallel computing capabilities and reconfigurable hardware structure, which is especially suitable for deploying convolutional computing modules in CNN; at the same time, matrix operations and attention mechanisms in Transformer can achieve low-latency inference through hardware pipeline and parallel optimization. This hybrid architecture is designed with lightweight features, such as reducing the number of attention heads and simplifying the feedforward network, and further matching the storage and computing resource constraints of the FPGA, ensuring that the model can still achieve real-time feature parsing and performance prediction on heterogeneous platforms.

[0017] Based on the above considerations, the specific construction process of the heterogeneous computing feature parsing model is as follows: First, an input layer is built to receive the standardized task feature vector and platform state vector. The two types of vectors are fused into a unified input tensor by orderly concatenating them according to the feature dimensions, ensuring that the features on the task side and the platform side are not confused and that core information is not lost. Then, a feature extraction layer is built. The bottom layer adopts a 3-layer lightweight CNN network, with each layer having a clear division of labor. The first layer extracts the basic features of the task and the platform, the second layer refines and filters key local features, and the third layer compresses the feature dimensions and removes redundant information through pooling operations. It is mainly used to extract task parallelism, computational density, and resources of each computing unit. The model incorporates local features related to source availability. The upper layer employs a simplified Transformer encoder with a single layer, reducing the number of attention heads and simplifying the FeedForward layer structure. It accurately captures global correlations between different local features through an attention mechanism, particularly strengthening the correlation between task parallelism and FPGA resource availability, computational density and GPU computing power matching, further reducing interference from irrelevant features. Finally, a classification and prediction layer is built, employing a dual-output structure corresponding to task classification and performance prediction, respectively. The overall model structure is lightweighted and pruned to avoid redundant computation modules, adapting to the real-time processing requirements and hardware resource constraints of heterogeneous FPGA platforms.

[0018] The specific training process of the model is as follows: Historical data from heterogeneous platforms such as FPGA, CPU, and GPU under different application scenarios are collected, including original task descriptions, state data of each computing unit, corresponding task classification labels, and actual execution performance data for typical scenarios such as AI inference, real-time big data computing, and high-frequency signal processing. This ensures that the samples cover different task types and platform load states, constructing comprehensive and representative model training and validation datasets, with the training and validation sets divided according to a preset ratio. The training dataset is then normalized and vectorized according to the same rules as in step 1.2 before being input into the initially constructed model. With the dual training objectives of improving classification accuracy and minimizing performance prediction error, the Adam optimizer is used for iterative training, with reasonable initial learning rate and iteration number thresholds set. After each training round, the model performance is verified using a validation dataset, and the classification accuracy and prediction bias are calculated. If the performance does not reach the preset convergence threshold, the convolution kernel size of the CNN network, the number of attention heads of the Transformer encoder, and the model learning rate are adjusted accordingly, while the network weight allocation is optimized. The process is repeated until the model converges and the generalization performance meets the target. The converged model is then pre-installed on a heterogeneous computing platform as the final usable pre-installed heterogeneous computing feature parsing model.

[0019] The input vectors of the two types are analyzed layer by layer through the feature extraction layer. First, the local key features of task parallelism, computational density, and platform heterogeneous resource availability are extracted through the bottom CNN network. Then, the global correlation of various features is captured by the upper Transformer encoder. Among them, the task parallelism feature represents the degree to which the task can be divided and executed in parallel, which is directly related to the parallel processing capability matching of subsequent computing units. The computational density feature represents the intensity of the task's demand for computing resources, which is used to determine whether the task is more suitable for FPGA, CPU or GPU. The platform heterogeneous resource availability feature represents the effective computing power and response capability that each computing unit can currently provide, reflecting the real-time carrying potential of the computing unit. Then, these three key features are integrated, spliced ​​and normalized to form a fusion feature vector that can comprehensively and accurately reflect the task characteristics and platform status, providing reliable support for the subsequent classification and prediction layer calculations.

[0020] Step 1.4: Input the fused feature vector into the classification and prediction layer of the pre-set heterogeneous computing feature parsing model. The classification and prediction layer outputs the task classification result and the initial performance prediction value according to the pre-set mapping relationship. Specifically, this includes: inputting the fused feature vector into the classification and prediction layer of the pre-set heterogeneous computing feature parsing model. This layer adopts a dual-output structure of classification branch + regression branch. The mapping rules built into the classification branch are learned based on a large amount of sample data during model training. Specifically, it is a precise correspondence between the fused feature vector and various task categories, such as computationally intensive, parallel processing, and I / O intensive. Combined with the feature association threshold solidified after training, and with the Softmax classifier, it can quickly match the corresponding task category and output the classification confidence based on the core features of the input fused feature vector. The performance prediction mapping relationship built into the regression branch is based on the model training... The weight matrix and bias term, obtained through iterative calibration during training, are used to quantify the impact of each dimension of the fused feature vector (such as task parallelism, computational density, and platform resource availability) on performance indicators. The bias term is used to correct computational biases. Together, they are used to substitute the fused feature vector into a preset linear computation logic to calculate the expected latency (accurate to 0.1 milliseconds) and energy efficiency ratio (in units of computing power per watt) of the task when executed on FPGA, CPU, and GPU computing units, and to output the estimated error range of each indicator. The classification and prediction layers complete two types of calculations simultaneously during a forward propagation, integrating the task classification results and the initial performance estimates of each computing unit into output data in a unified format. After verifying the completeness and rationality of the data, it provides accurate and directly applicable decision-making basis for the generation of data allocation schemes in subsequent steps.

[0021] In this embodiment of the invention, it should be noted that the heterogeneous computing platform and the pre-set heterogeneous computing feature analysis model are complementary and complementary hardware carriers and software algorithm models running on the hardware. They belong to the standard combination of hardware platform + intelligent decision model in the technical solution of this invention, and are highly unified and mutually supportive in terms of concept, hierarchy and function.

[0022] In a preferred embodiment of the present invention, step 2 above may include: Step 2.1: Based on the task classification results, load a set of weight factors matching the task type from the pre-set strategy library. The weight factors include at least a latency factor, an energy efficiency factor, and a resource balance factor. Specifically, based on the output task classification results, classification confidence, and core task attributes, such as task real-time requirements and computational load levels, load a set of weight factors that perfectly match the current task type from the pre-set strategy library of the heterogeneous computing platform. In this embodiment, the set of weight factors consists of three core factors: latency factor, energy efficiency factor, and resource balance factor. The three factors together form a weight system for task adaptability assessment, and the total weight of each factor is fixed at 100%.

[0023] The pre-built strategy library adopts a partitioned storage structure, divided into multiple independent partitions according to task type, including AI inference, big data computing, high-frequency signal processing, and general computing. Each partition not only stores a set of weight factors but also includes adaptation identifiers, applicable scenario descriptions, weight adjustment records, and verification rules to ensure that different task types can quickly match the corresponding weight configurations. Each weight factor has a precise definition and value range. The latency factor is used to quantify the task's sensitivity to transmission and computation latency, with a value range of 0.2 to 0.7. The energy efficiency factor is used to measure the task's requirement for computing power output per unit of power consumption, with a value range of 0.1 to 0.5. The resource balancing factor is used to balance heterogeneous computing platforms. Load balancing across computing units ranges from 0.1 to 0.4. Different task types have different weighting emphases. For example, high-frequency signal processing tasks (such as real-time radar signal analysis) have extremely high latency requirements, so the latency factor weight is set at 0.65, the energy efficiency factor at 0.2, and the resource balance factor at 0.15. AI inference tasks (such as image recognition inference) balance energy efficiency and latency, with a latency factor weight of 0.35, an energy efficiency factor weight of 0.4, and a resource balance factor weight of 0.25. Big data computing tasks (such as streaming data statistical analysis) emphasize energy efficiency and load balancing, with an energy efficiency factor weight of 0.45, a resource balance factor weight of 0.35, and a latency factor weight of 0.2.

[0024] The weight factor loading process consists of three steps. First, based on the task category tags, the corresponding partition in the strategy library is queried to extract a set of candidate weight factors. Second, the task category confidence level is compared with a preset threshold (not lower than 90%). If the confidence level meets the threshold, the matching degree between the task's core attributes and the applicable scenarios of the weight set is further verified. If the confidence level does not meet the threshold, a backup mechanism is triggered, loading a general weight factor set and recording an anomaly log. Third, the loaded weight factor set is normalized to ensure that the total weight percentage of each factor is 100%. If a deviation occurs, a preset calibration rule is automatically invoked for correction. Simultaneously, weight loading details are recorded, including the task ID, loading time, weight set parameters, and verification results, providing accurate, reasonable, and traceable weight support for subsequent comprehensive performance score calculations.

[0025] Step 2.2: Based on the initial performance estimates, calculate the comprehensive performance score of each computing unit as a candidate computing unit for the current task. The comprehensive performance score is obtained by weighted fusion of the initial performance estimates corresponding to each candidate computing unit and their corresponding weighting factors. Specifically, this includes: calculating the comprehensive performance score of each computing unit as a candidate computing unit based on the output initial performance estimates of each computing unit (FPGA, CPU, GPU) for the current task; the initial performance estimates specifically include: the performance of each candidate computing unit during execution... The current task has three core indicators: expected delay, energy efficiency ratio, and resource utilization rate. Each indicator has been normalized and quantified, with a unified quantification range of 0 to 100 points. The smaller the expected delay quantification value, the lower the delay and the stronger the adaptability. The larger the energy efficiency ratio quantification value, the higher the energy efficiency and the stronger the adaptability. The smaller the resource utilization rate quantification value, the less the resource consumption and the stronger the adaptability. The three indicators correspond one-to-one with the delay factor W1, energy efficiency factor W2, and resource balance factor W3 loaded in step 2.1, and satisfy W1+W2+W3=100%.

[0026] The weighted fusion calculation formula is: Comprehensive performance score S = (A×W1) + (B×W2) + (C×W3), where A is the expected latency quantification value of the candidate computing unit, B is the energy efficiency ratio quantification value of the candidate computing unit, and C is the resource utilization rate quantification value of the candidate computing unit. The specific process of weighted fusion calculation is as follows: First, the quantification values ​​of the three indicators for each candidate computing unit are matched and associated with their corresponding weight factors. Then, according to the above calculation formula, the product results of the three indicators and their corresponding weight factors are integrated and summed to obtain the comprehensive performance score of each candidate computing unit. The score range is synchronized. Normalized to a score of 0 to 100, a higher score indicates a stronger overall ability of the computing unit to adapt to the current task. After all candidate computing units complete their score calculations simultaneously, a complete score list is generated, including the computing unit identifier, the quantitative values ​​of each indicator, the product of each indicator and the weight factor, and the overall score. At the same time, the rationality of the scores is verified, with a focus on verifying whether the scores are within the range of 0 to 100 and whether the calculation process is consistent with the formula. Abnormal score data is removed, and if a calculation deviation occurs, it is automatically recalculated to ensure the accuracy of subsequent ranking and provide accurate and traceable scoring basis for the ranking of candidate computing units.

[0027] Step 2.3: Sort all candidate computing units according to their comprehensive performance scores, select the highest-ranked computing unit as the target computing unit, and determine the transmission path that maximizes the comprehensive performance score of the target computing unit from a pre-set path table based on the physical topology location of the target computing unit in the platform. This forms the target unit decision and path decision, specifically including: sorting all candidate computing units in descending order according to their comprehensive performance scores. If two or more computing units have the same comprehensive performance score during the sorting process, a secondary selection will be performed based on the current task type. For example, FPGA is preferred for real-time tasks, GPU is preferred for computationally intensive tasks, and CPU is preferred for general-purpose tasks. After sorting, the highest-ranked computing unit is selected as the data processing target computing unit for the current task, and a target computing unit confirmation identifier is generated and associated. The current task ID ensures a unique correspondence between the task and the target unit. Subsequently, the specific physical topology location of the target computing unit within the platform's hardware architecture is obtained, including its node number, data transmission interface type, connection link to the source storage device, and distribution of adjacent nodes. From a pre-set path table within the platform, all transmission paths reaching the target computing unit are queried. This pre-set path table stores the optional transmission path ID, node sequence, transmission bandwidth range, transmission latency, and stability parameters corresponding to each computing unit. Combining these parameters, the optimal transmission path is selected based on low transmission latency, sufficient bandwidth, high stability, and the ability to maximize the overall performance score of the target computing unit. This results in a clear target unit decision and path decision. The target unit decision includes the target computing unit identifier, the reason for its suitability, and its overall score; the path decision includes the transmission path ID, node sequence, transmission parameters, and execution requirements.

[0028] Step 2.4 encapsulates the target unit decision and path decision to generate a data allocation scheme with a definite executable format. Specifically, this includes: integrating and organizing all core information of the target unit decision and path decision, including task ID, target computing unit identifier and parameters, transmission path node information, transmission timing requirements, data scheduling trigger conditions, and exception handling contingency plans; and following a standard instruction format that can be directly parsed and executed by the heterogeneous computing platform (this standard instruction format adopts a structured design with fixed field lengths, including an instruction header, core decision fields, execution parameter fields, and format verification bits; the instruction header is used by the platform to quickly identify the instruction as a data allocation instruction; the core decision fields encapsulate key information about the target unit and path; and the execution parameter fields specify the data allocation method). The process involves several steps: first, determining the timing and triggering conditions of data scheduling; second, verifying the integrity of instructions using format check bits to ensure the platform's execution module can parse the information quickly and without deviation; and third, encapsulating the information, removing redundant information and adding format check codes to ensure the encapsulated instructions are clear and formatted correctly. After encapsulation, the generated data allocation scheme undergoes dual verification: first, verifying the rationality of the decision logic to ensure the target unit and transmission path are compatible with the current task; and second, verifying format compatibility to ensure the scheme can be accurately parsed by the platform's execution module. Finally, a data allocation scheme with a precise executable format is generated and temporarily stored in the platform's scheme buffer for direct invocation during subsequent data scheduling and computation triggering, ensuring efficient data allocation.

[0029] In a preferred embodiment of the present invention, step 3 above may include: Step 3.1 involves parsing a data allocation scheme with a precise executable format, extracting the encapsulated target unit decisions and path decisions, and obtaining the target computing unit identifier and the precise transmission path description. Specifically, this includes: first, parsing the generated data allocation scheme stored in the scheme buffer; first, verifying the format check bits and instruction header of the scheme to confirm that the scheme is undamaged, has no format deviation, and is an executable allocation instruction; then, disassembling the structured fields of the scheme layer by layer to extract the core information of the encapsulated target unit decisions and path decisions, ultimately obtaining a unique target computing unit identifier, such as F001 for FPGA and C002 for CPU, as well as a precise transmission path description, including key parameters such as transmission path ID, node sequence, interface type, and transmission bandwidth, ensuring that the extracted information is complete and accurate, providing a basis for subsequent data scheduling and computation triggering.

[0030] Step 3.2: Based on the precise transmission path description, the input data to be processed is scheduled from the source storage location to the input buffer corresponding to the target computing unit, and a data ready signal is returned. Specifically, this includes: first, confirming the connectivity and bandwidth stability of each node on the transmission path according to the parsed precise transmission path description, ensuring the path can transmit normally and meet the data scheduling requirements of the current task; then, reading the input data to be processed from the designated location of the source storage device according to a preset data block size (a single transmission data unit preset based on the total task data volume, transmission bandwidth, and computing unit processing capacity); verifying the data checksum block by block during the reading process to prevent data loss, corruption, or damage; subsequently, strictly following the node sequence of the transmission path, controlling the data... Based on the transmission rate and timing, the read input data is batched and steadily scheduled to the dedicated input buffer corresponding to the target computing unit (each computing unit has its own dedicated temporary data storage area, isolated from the storage areas of other units). During the scheduling process, the transmission status is monitored in real time to avoid abnormal issues such as transmission lag and interruption. After all data has been scheduled, the data in the input buffer is fully verified to confirm that the total amount of data is consistent with the requirements of the task to be processed and that the data format is without deviation. Then, a data ready signal is synchronously returned to the data scheduling execution link and the target computing unit. The signal confirms that it includes key information such as task ID, total amount of data, buffer occupancy rate and data verification results, providing a clear basis for triggering subsequent calculations.

[0031] Step 3.3: Respond to the data ready signal by synchronously sending a computation trigger command to the target computing unit to initiate computation processing of the data scheduled to the input buffer. Specifically, upon receiving the data ready signal, the unit first verifies the validity and integrity of the signal, confirming that key information such as the task ID and data status are correct and accurately match the current task to be processed. Then, it immediately initiates the response process, synchronously generating and sending a computation trigger command to the target computing unit. The computation trigger command includes detailed parameters such as the task ID, specific computation processing requirements, data read address of the input buffer, output address of the computation result, and exception handling threshold. After receiving the trigger command, the target computing unit first verifies the adaptability of the command, confirms that its own operating status is normal, the data read address is accurate, and its own resources can meet the current computation requirements. Then, it initializes the computation-related configuration and data read interface, reasonably allocates its own computing resources to adapt to the task requirements, and then formally starts the computation processing process. It reads data from the input buffer sequentially and strictly executes related operations according to the set computation logic to ensure the timeliness and accuracy of computation startup and ensure efficient task progress.

[0032] Step 3.4: After the computation process starts, continuously collect the computation progress, data buffer status, and resource usage indicators of the target computing unit, and integrate them to generate task execution status information. Specifically, after the target computing unit starts the computation process, continuously collect various operating parameters and task execution data of the target computing unit at fixed millisecond intervals, set according to the task's real-time requirements, such as 10 milliseconds. The computation progress is quantified by the ratio of the number of processed data blocks to the total number of data blocks in real time, and the matching degree between the processed data blocks and the task's set processing logic is compared simultaneously. The processing time and the remaining estimated time are recorded. The data buffer status is obtained by real-time detection of parameters such as the remaining storage space of the buffer, data read rate, and data residue. Simultaneously, the risk prediction of buffer data overflow is carried out to ensure that there is no buffer overflow or data backlog. The resource usage indicators are collected by real-time statistics of the target computing unit's core utilization, power consumption, response latency, and memory usage, and the indicators are normalized and organized in real time to accurately grasp its resource consumption and real-time load status.

[0033] During the data collection process, abnormal data judgment criteria are set, and parameters that exceed the reasonable range are marked and removed. Then, all valid collected parameters are categorized and organized according to task ID, collection timestamp, and parameter type, and integrated to generate structured task execution status information. This structured task execution status information includes task execution progress, real-time buffer status, resource usage details, anomaly markers, and risk prediction results. Subsequently, it is updated and stored in a designated area in real time according to the collection time sequence, providing accurate and traceable data support for subsequent task execution monitoring, anomaly adjustment, and process optimization.

[0034] In a preferred embodiment of the present invention, step 4 above may include: Step 4.1: Receive and parse the task execution status information, extracting the set of actual performance indicators generated by the target computing unit when processing the current task. Specifically, this includes: retrieving and receiving the generated task execution status information from the designated storage area by task ID, synchronously verifying the integrity of the information, the validity of the timestamp, and the rationality of the data to avoid receiving corrupt or outdated status data; then, disassembling the structured information layer by layer to extract the set of actual performance indicators generated by the target computing unit when processing the current task; the set of actual performance indicators completely corresponds to the initial performance estimate indicators output in Step 1.4, specifically including: actual latency, i.e., the average real time taken by the target computing unit to process the received data from the start of computation to the current moment, accurate to 0.1 milliseconds; actual energy efficiency ratio, i.e., the computing power output per unit power consumption of the target computing unit in processing the current task, measured in floating-point operations per watt; actual resource utilization rate, i.e., the peak and average percentage of core utilization during the processing of the target computing unit, both expressed as percentages; after extraction, verify the completeness of each actual indicator to ensure no missing or abnormal data, providing accurate and corresponding basic data for subsequent difference calculations.

[0035] Step 4.2: Obtain the initial performance estimate corresponding to the current task and target computing unit. Calculate the difference between each indicator in the actual performance indicator set and its corresponding item in the initial performance estimate. This includes: using a combination query of the current task ID and the unique identifier of the target computing unit (e.g., F001, C002), first retrieve the initial performance estimate that perfectly corresponds to the current task and target computing unit. During the retrieval process, strictly verify the identifier matching degree to prevent retrieval errors or confusion of estimates for different tasks or computing units. After retrieval, confirm the correspondence of the difference calculation, accurately matching each indicator in the actual performance indicator set with its corresponding item in the initial performance estimate, i.e., the actual latency and the initial performance estimate. The system first establishes a correspondence between expected delay, actual energy efficiency ratio (EER) and initial EER, and actual resource utilization rate and initial resource utilization rate. Then, it calculates the differences for each: Delay difference = Actual delay - Initial expected delay; Energy efficiency ratio difference = Actual energy efficiency ratio - Initial energy efficiency ratio; Resource utilization rate difference = Actual resource utilization rate - Initial resource utilization rate. The meaning of each difference is defined: a positive delay difference indicates that the actual time taken is higher than the initial estimate, and a negative one indicates that the actual time taken is lower than the initial estimate; a positive energy efficiency ratio difference indicates that the actual energy efficiency is better than the initial estimate, and a negative one indicates that the actual energy efficiency is lower than the initial estimate; a positive resource utilization rate difference indicates that the actual resource consumption is higher than the initial estimate, and a negative one indicates that the actual resource consumption is lower than the initial estimate. After calculation, a complete set of performance differences is formed. Each set of differences is recalculated and verified to ensure there are no calculation errors and the correspondences are correct. Finally, these differences are organized into an ordered list to prepare for subsequent standardization processing.

[0036] Step 4.3: The calculated set of performance differences is normalized and vectorized according to a preset dimensional order to generate the multidimensional performance deviation vector. Specifically, this includes: first, normalizing the calculated set of performance differences and mapping them uniformly to [-1] according to a set numerical range standard. , [1] In the interval, considering the positive and negative meanings of each difference, a linear scaling correction is applied to each difference. The correction logic is to divide the difference by the maximum value of the corresponding indicator within its normal reasonable range to ensure that all differences are in the same dimension and are directly comparable. At the same time, abnormal differences that exceed the reasonable range are removed again, and differences with slight deviations are fine-tuned and calibrated. Then, the normalized performance differences are arranged in an orderly manner according to a preset fixed dimension order (the preset fixed dimension order is strictly consistent with the order of indicators and the corresponding order of weight factors in the initial performance estimate, i.e., delay difference, energy efficiency ratio difference, and resource utilization rate difference). This avoids disordered order.

[0037] Next, the arranged differences are filled one by one into a fixed-dimensional 3D vector structure. Each dimension of the vector is labeled with the corresponding indicator name, the meaning of the difference, and the normalized value, completing the vectorization assembly and finally generating the multidimensional performance deviation vector. After assembly, a final verification is performed: first, the vector dimension integrity is verified to confirm that the vector dimension is 3, consistent with the number of differences; second, the data accuracy is verified to confirm that the data in the vector corresponds completely with the normalized performance differences; third, the order is verified to confirm that the order of each dimension is consistent with the preset order of dimensions, ensuring that the multidimensional performance deviation vector can comprehensively and accurately reflect the deviation between the actual performance and the initial estimated performance when the target computing unit processes the current task.

[0038] In a preferred embodiment of the present invention, step 5 above may include: Step 5.1: Receive the multi-dimensional performance deviation vector and, according to preset rules, select components representing latency deviation, power consumption deviation, and resource utilization deviation from the multi-dimensional performance deviation vector as the core performance measured values. Specifically, this includes: receiving the generated multi-dimensional performance deviation vector; firstly, performing a comprehensive dual verification of the vector's completeness and validity to confirm that the vector dimension is strictly 3-dimensional, that the data of each dimension component is complete and without abnormal fluctuations, and that the indicator names and difference meanings labeled in each dimension of the vector completely match the preset performance deviation vector format. Simultaneously, verify that the vector's timestamp is consistent with the current task execution cycle to avoid receiving outdated or incorrect vector data; then, performing a precise filtering operation according to preset filtering rules. These preset filtering rules are stored in the form of a mapping table between dimension indices and deviation types, precisely defining that the first dimension index corresponds to latency deviation, the second dimension index corresponds to power consumption deviation, and the third dimension index corresponds to latency deviation. The corresponding resource utilization deviation is introduced, where the power consumption deviation is derived from the energy efficiency ratio deviation in the multi-dimensional performance deviation vector. The specific derivation process is as follows: combining the correlation between the actual power consumption data of the current task and the energy efficiency ratio deviation, the energy efficiency ratio deviation is transformed into a power consumption deviation that intuitively reflects the power consumption difference, ensuring that the power consumption deviation can accurately match the actual operating conditions. In the screening process, the indexes of the three target dimensions are first located through the mapping table, and then the component data of the corresponding indexes are extracted one by one. The component data of these three dimensions are used together as the core performance measured value that can reflect the performance deviation of the target computing unit. After extraction, the correlation and rationality of the three core components are further verified. The deviation range of the same type of task and the same type of computing unit in history is compared, and the components that exceed the reasonable range are marked and the reasons for the anomalies are briefly recorded to ensure that the component data can accurately and comprehensively represent the corresponding deviation situation, providing high-quality core measured data support for subsequent data binding operations.

[0039] Step 5.2: Bind the measured core performance values ​​with the identifier of the current computing unit and the task type identifier of the current task category to generate a preliminary performance data tuple. Specifically, this includes: First, confirming the source and specifications of various identifier information required for the binding operation. The identifier of the current computing unit is a unique digital identifier of the target computing unit, such as F001 for FPGA, C002 for CPU, and G003 for GPU. This identifier is pre-set in the basic attribute record of the computing unit and can be retrieved by associating with the running status of the current computing unit. The identifier is unique throughout its life and is used to accurately distinguish different computing units. The task type identifier of the current task category is the exclusive code corresponding to the task category label output in Step 1.4, such as A001 for AI inference, H001 for high-frequency signal processing, and D001 for big data computing. This identifier is stored in the task configuration information and is associated with the task ID to distinguish different types of tasks.

[0040] The data binding process then begins. Extracted and verified core performance measurements, including latency deviation, power consumption deviation, and resource utilization deviation, are bound one-to-one with the unique identifier of the current computing unit and the type identifier of the current task. The binding process uses key-value pairs, with the identifier as the key and the core performance measurement value as the corresponding value, ensuring no mismatch or confusion in the correspondence between each identifier and measurement value. After binding, a preliminary performance data tuple is generated. This preliminary performance data tuple uses a structured field format and includes five key fields: task type identifier, computing unit identifier, latency deviation measurement value, power consumption deviation measurement value, and resource utilization deviation measurement value. Each field is clearly labeled with its name and data type. A current timestamp and task ID are also added to the tuple for subsequent traceability and association. After binding and tuple generation, an association verification is performed to confirm that the computing unit identifier, task type identifier, and current task and computing unit are completely matched, and that there are no mismatches between the core performance measurement values ​​and the identifier information, ensuring the tuple data is complete, the correspondence is clear, and it is traceable.

[0041] Step 5.3: Based on predefined formatting rules, the measured values ​​in the initial performance data tuple are processed for unit unification and precision alignment to generate a heterogeneous performance feature anchor with a unified format. This specifically includes: retrieving predefined formatting rules, which are stored in the preset configuration file of the heterogeneous computing platform. These rules can be fine-tuned according to the task type and computing unit type, but the core standards remain unified. The rules specify the unit unification standard, precision alignment requirements, and data correction rules for the core performance measured values. Specifically, the unit unification standard is as follows: latency deviation is uniformly expressed in milliseconds (ms). If the original measured value is microseconds (μs), it is converted according to the conversion relationship of 1 millisecond = 1000 microseconds. Power consumption deviation is uniformly expressed in watts (W). If the original measured value is milliwatts (mW), it is converted according to the conversion relationship of 1 watt = 1000 milliwatts. Resource utilization deviation is uniformly expressed in percentage (%). If the original measured value is in decimal form (e.g., 0.65), it is converted to percentage form by a factor of 100.

[0042] The specific precision alignment requirements are as follows: latency deviation precision alignment to 0.1 milliseconds, using rounding to handle the decimal part; power consumption deviation precision alignment to 0.01 watts, using rounding to handle the decimal part; resource utilization deviation precision alignment to one decimal place. Then, following these formatting rules, the three core performance measured values ​​in the initial performance data tuples are processed one by one. First, unit conversion is completed, the conversion process and conversion coefficients are recorded, and then precision alignment is performed to correct minor deviations generated during conversion and alignment, ensuring that the processed data is without deviation or anomalies. During processing, the identification information, timestamp, and task ID in the tuple are strictly preserved without changing their content or format; only the core performance measured values ​​are standardized. After processing, a heterogeneous performance feature anchor point with a unified format, standardized data, and direct reusability is generated. Simultaneously, the anchor point's format is validated to confirm that the units and precision of the measured values ​​fully comply with the predefined rules, and the correspondence between the identification information and the measured values ​​remains unchanged, ensuring that the anchor point data can be directly used for subsequent aggregation and optimization processes.

[0043] Step 5.4: Collect heterogeneous performance feature anchors with a unified format generated for all processing units participating in the computation within the current execution cycle, forming the series of heterogeneous performance feature anchors. Specifically, this includes: first, confirming the time range of the current execution cycle. This time range is precisely defined by the task start timestamp and the timestamp of the last processing unit participating in the computation completing the computation. That is, the complete time period from the current task start data allocation to the completion of the current task computation and the generation of the final task execution status information by all processing units participating in the computation. At the same time, the duration of the execution cycle is recorded for subsequent performance analysis. Then, determine the range of all processing units participating in the computation within the current execution cycle. By querying the execution log and data allocation record of the current task, extract the identifiers of all computing units scheduled to participate in data processing and computation during the execution of this task. The range may be a single or multiple FPGAs, CPUs, and GPUs, and each computing unit corresponds to a unique identifier. Idle computing units that did not participate in the current task computation are excluded.

[0044] Then, the anchor point aggregation process is initiated. This involves retrieving, one by one, the heterogeneous performance characteristic anchor points with a uniform format generated for each processing unit participating in the computation within the current execution cycle. These anchor points are then aggregated in ascending order of computation unit identifiers. During aggregation, each anchor point undergoes a second comprehensive verification. Verification includes checking the anchor point format for uniformity, data precision for compliance with requirements, completeness and validity of identifier information, and whether the timestamp is within the current execution cycle. Simultaneously, duplicate, invalid, and abnormal anchor point data are removed, such as those with incorrect formats, missing identifiers, or data exceeding reasonable ranges. The reasons for and number of removals are recorded. After aggregation, all valid anchor points are categorized and organized. The data is grouped according to computing unit type (FPGA, CPU, GPU), and further categorized by task type. The number of anchor points in each group and the average measured core performance value of each anchor point are then calculated to form a simple statistical summary. After processing, all valid anchor points are integrated with the statistical summary to form a series of heterogeneous performance characteristic anchor points. This series of anchor points fully covers all processing units involved in the computation within the current execution cycle. The data is in a unified format, standardized in content, and traceable, providing comprehensive, accurate, and standardized performance characteristic data support for subsequent optimization of heterogeneous computing characteristic analysis models, adjustment of data allocation strategies, and optimization of computing unit scheduling.

[0045] In a preferred embodiment of the present invention, step 6 above may include: Step 6.1: Receive the series of heterogeneous performance feature anchor points and parse the normalized computational delay deviation and energy efficiency ratio deviation values ​​from each anchor point. Specifically, this includes: receiving the generated series of heterogeneous performance feature anchor points; first, performing an overall verification of this series of anchor points to confirm that the number of anchor points matches the number of processing units participating in the computation within the current execution cycle, that all anchor points have a unified format, that all timestamps are within the current execution cycle, and that there is no duplicate, invalid, or abnormal anchor point data; then, parsing each heterogeneous performance feature anchor point one by one, relying on pre-set anchor point field mapping rules, which are pre-stored in the heterogeneous computing platform. This is a set of specifications that determines the correspondence between the structured fields of the anchor point and the performance parameters. It clearly defines the name, position, data type and meaning of each field. Specifically, it specifies that the measured delay deviation field corresponds to the calculated delay deviation value. The field position is the fourth position of the anchor point, the data type is numeric, the unit is preset to milliseconds and the precision is aligned to 0.1 milliseconds. The measured power consumption deviation field corresponds to the basic data required for subsequent conversion. The field position is the fifth position of the anchor point, the data type is numeric, the unit is preset to watts and the precision is aligned to 0.01 watts. Through this rule, the fields to be extracted can be accurately located, and field confusion can be avoided.

[0046] Based on preset anchor point field mapping rules, the normalized calculation delay deviation value and measured power consumption deviation value of each anchor point are accurately extracted. The calculation delay deviation value directly corresponds to the value of the measured delay deviation field in the anchor point, requiring no additional conversion. The energy efficiency ratio deviation value is obtained by reverse conversion from the measured power consumption deviation value in the anchor point; the two are negatively correlated. The conversion process strictly follows the preset specifications in step 5.1: first, the power consumption-energy efficiency correlation coefficient corresponding to the current computing unit type is retrieved. This coefficient is a preset fixed value determined by the computing unit hardware parameters. Then, the measured power consumption deviation value is divided by this correlation coefficient to obtain the value of the power consumption deviation. The energy efficiency baseline deviation value corresponding to the power consumption deviation is then taken as its negative value, which is the final energy efficiency ratio deviation value. A strict precision of 0.01 is maintained during the conversion process to ensure that the conversion result accurately corresponds to the actual energy efficiency performance. Simultaneously, the rationality of the conversion logic is verified to avoid conversion errors. After extraction and conversion, an associated record is established for each anchor point, including anchor point identification, calculated delay deviation value, and energy efficiency ratio deviation value. The rationality of the two deviation values ​​is verified, and the deviation range of historical anchor points of the same type is compared. Values ​​exceeding the reasonable range are marked and associated with the corresponding anchor point identification, ensuring that the extracted two deviation values ​​are complete, accurate, and comparable.

[0047] Step 6.2: Map the calculated delay deviation value and energy efficiency ratio deviation value resolved from each anchor point as a set of coordinate pairs to the strategy analysis plane to generate corresponding plane mapping points. Specifically, this includes: first, completing the initialization operation of the preset strategy analysis plane, which is a two-dimensional rectangular coordinate system; confirming that the horizontal axis is set as the calculated delay deviation value, i.e., the actual meaning of the calculated delay coordinate axis in claim 7, representing the deviation amount of the calculated delay, with a value range that fits the deviation range in actual applications, such as -5.0 milliseconds to 5.0 milliseconds, and the scale interval is consistent with the data precision at 0.1 milliseconds; the vertical axis is the energy efficiency ratio deviation value, i.e., the energy efficiency ratio coordinate axis in claim 7. The actual meaning of the axis is to represent the deviation of the energy efficiency ratio. The value range corresponds to the actual energy efficiency deviation range, such as -0.5 to 0.5, with the scale interval set to 0.05. The origin of the coordinate system corresponds to the ideal performance state where the calculation delay deviation is 0 and the energy efficiency ratio deviation is 0. The scale, unit, and positive and negative meaning of the deviation of the coordinate axis are clearly marked. The positive horizontal axis means that the actual calculation delay is higher than the initial estimate, which will affect the real-time performance of the task. The negative horizontal axis means that the actual calculation delay is lower than the initial estimate, and the performance is better. The positive vertical axis means that the actual energy efficiency ratio is higher than the initial estimate and the computing power output per unit of power consumption is higher. The negative vertical axis means that the actual energy efficiency ratio is lower than the initial estimate and the power consumption utilization efficiency is lower.

[0048] After initialization, the planar mapping operation begins: First, for a single anchor point, its resolved computational delay deviation value is used as the horizontal axis coordinate of a two-dimensional coordinate pair, and the energy efficiency ratio deviation value is used as the vertical axis coordinate. Since each anchor point corresponds to a unique combination of computational unit and current task, each coordinate pair is unique, accurately distinguishing the performance deviation state of different anchor points. Then, the scale and units of the horizontal and vertical axes are analyzed according to the strategy. First, based on the horizontal axis coordinate value, the scale position on the horizontal axis that perfectly matches the computational delay deviation value is found. If the delay deviation is 1.2 milliseconds, locate the scale line corresponding to 1.2 milliseconds on the horizontal axis; then, based on the vertical axis coordinate value, find the scale position on the vertical axis that perfectly matches the energy efficiency ratio deviation value. For example, if the energy efficiency ratio deviation is 0.25, locate the scale line corresponding to 0.25 on the vertical axis; then, draw a perpendicular line from the horizontal axis positioning point to the vertical axis, and draw a perpendicular line from the vertical axis positioning point to the horizontal axis. The intersection of the two perpendicular lines is the plane mapping point corresponding to the anchor point. During the mapping process, strictly align the data accuracy with the coordinate axis scale interval to ensure that the mapping point position is accurate and without offset.

[0049] After mapping is completed, the plane mapping point is labeled with complete association information, including the corresponding anchor point identifier, computing unit identifier, task type identifier, and task ID. This facilitates traceability and performance correlation analysis after subsequent clustering analysis. At the same time, the location rationality of each mapping point is verified. If the mapping point exceeds the preset value range of the coordinate system, it is determined to be an abnormal mapping point, and its information and the reason for the abnormality are recorded separately. It is not included in the subsequent clustering process. This ensures that all valid mapping points can accurately correspond to the actual performance deviation state of their anchor points. After all valid mapping points are generated, they are integrated to form a complete set of plane mapping points.

[0050] Step 6.3: Based on the spatial distribution of all planar mapping points on the strategy analysis plane, a preset density clustering algorithm is used to identify the core point set, and the boundary is determined based on the identified core point set. Specifically, this includes: based on the actual spatial distribution of all valid planar mapping points on the strategy analysis plane, a preset density clustering algorithm is started to perform clustering analysis. This density clustering algorithm is pre-stored in the platform configuration. The core logic is: to filter core points based on the neighborhood density of the mapping points and to aggregate the core points to form a core point set. The neighborhood radius and the minimum core point number threshold are preset based on the performance deviation data of historical similar tasks, and can be fine-tuned according to the current task type. The neighborhood radius is set to a fixed value that fits the actual deviation range, such as a comprehensive neighborhood range of 0.2 milliseconds on the horizontal axis and 0.05 on the vertical axis, which is used to accurately define the neighborhood boundary of a single mapping point. The minimum core point number threshold is set according to the total number of the current planar mapping point set. For example, the threshold is set to 3 when the total number of mapping points is ≥10, and the threshold is set to 2 when the total number of mapping points is <10, which is used to determine whether the neighborhood of a single mapping point meets the core point standard.

[0051] During cluster analysis, each valid planar mapping point is traversed one by one. Using Euclidean distance, the number of other valid mapping points within a preset neighborhood radius of each mapping point is counted. If the count is not less than the minimum core point threshold, the mapping point is marked as a core point, and its coordinates and associated information are recorded. This process is repeated until all valid mapping points have been identified as core points. Then, adjacent core points (core points that are within each other's neighborhood) are aggregated to form multiple independent core point sets. Simultaneously, isolated non-core points (mapping points whose number of neighboring mapping points is less than the threshold and are not adjacent to any core point) are removed. These points correspond to abnormal performance deviations and have no strategic reference value. After removing points, record the number and reason for removal. After clustering, verify the rationality of each core point set to confirm that the clustering degree of each core point set meets the requirements, with no excessive dispersion or excessive clustering, and the deviation range between core points is within a reasonable range. Then, based on the spatial distribution range of each core point set, select the critical points on the periphery of the core point set: that is, the core points in the core point set that are closest to the edge of the set and show obvious abrupt changes in density. Integrate all critical points as the boundary points of the core point set, complete the determination of the boundary of each core point set, and ensure that the boundary can completely wrap the corresponding core point set, accurately reflect the distribution range of the current mainstream performance deviation of the platform, and lay the foundation for the subsequent construction of closed geometric regions.

[0052] Step 6.4: Connect the points on the determined boundaries to construct a closed geometric region in the strategy analysis plane, serving as the dynamic strategy feature domain characterizing the current platform performance distribution. Specifically, this includes: sorting all boundary points on the determined boundaries in an ordered manner, using a clockwise spatial distribution order. First, find the boundary point with the smallest horizontal axis coordinate as the starting point. If multiple boundary points have the smallest horizontal axis coordinate, select the point with the smallest vertical axis coordinate as the starting point. Then, connect adjacent boundary points sequentially in a clockwise direction. During the sorting process, verify the continuity of the boundary point arrangement in real time. If any issues arise... If the boundary points are intersecting and arranged haphazardly, the sorting order should be adjusted in a timely manner, and abnormal boundary points that deviate from the overall distribution trend of the core point set should be removed to ensure that all boundary points are arranged coherently and conform to the spatial distribution pattern of the core point set. After sorting, the points on the sorted boundaries should be connected one by one according to the preset connection rules. Adjacent boundary points should be connected by straight lines. If the boundary points are densely distributed, smooth curves can be used to avoid abrupt turns in the connection lines, ensuring that the connection lines conform to the distribution trend of the boundary points, do not pass through the interior of the core point set or other irrelevant areas, and do not have any intersections, breaks, or overlaps.

[0053] Upon connecting to the last boundary point, it is precisely connected to the sorting start point, constructing a complete closed geometric region in the policy analysis plane. This region is typically polygonal, with its specific shape determined by the distribution density and trend of the boundary points. It completely encloses all core point sets within the current execution cycle, accurately covering the mainstream performance deviation distribution range of all participating computing units on the current heterogeneous computing platform, serving as a dynamic policy feature domain characterizing the current platform performance distribution status. After construction, the closed geometric region undergoes multi-dimensional verification to confirm its complete closure (precise coincidence of the start and end points) and continuity (no breaks or intersecting lines). The region contains all core point sets without any omissions. The rationality of the region is verified to ensure that its range accurately reflects actual performance deviations without excessive expansion or contraction. Subsequently, complete identification information is added to this dynamic strategy feature domain, including the current execution cycle identifier, task type summary, number of core point sets, core performance deviation range, and construction timestamp. This completes the construction of the dynamic strategy feature domain, which will serve as a core reference for subsequent data allocation strategy adjustments, heterogeneous computing feature parsing model parameter optimization, and computing unit scheduling optimization, ensuring that subsequent strategies accurately adapt to the actual performance distribution of the current platform.

[0054] In a preferred embodiment of the present invention, step 7 above may include: Step 7.1: Receive the boundary information of the dynamic strategy feature domain. By calculating the average coordinates of all points within its geometry, determine the centroid coordinates of this dynamic strategy feature domain in the strategy analysis plane. Specifically, this includes: receiving the boundary information of the dynamic strategy feature domain, which specifically includes a complete list of boundary point coordinates, the contour parameters of the closed geometric region, and the associated execution cycle identifier. First, perform a comprehensive completeness and accuracy check on the boundary information to confirm that the number of boundary points is sufficient and their arrangement is coherent, without missing, duplicate, or coordinate anomalies; the contour of the closed geometric region is unbroken and without intersections; and simultaneously verify that the coordinate range corresponding to the boundary information is consistent with the value range of the strategy analysis plane, and that the arrangement order of the boundary points conforms to clockwise. The standardization process ensures regional closure and avoids misalignment, damage, or abnormal formatting of boundary information. Subsequently, all valid points within the geometry of the dynamic strategy's feature domain are determined, specifically including all boundary points on the boundary and all core point sets within the region. The method for defining the core point set within the region is as follows: It is determined whether the coordinates of the core point are within the closed region enclosed by the boundary points. If the x-axis coordinate of the core point lies between the maximum and minimum values ​​of the x-axis coordinates of the boundary points, and the y-axis coordinate lies between the maximum and minimum values ​​of the y-axis coordinates of the boundary points, and it is located inside the boundary contour, then it is determined to be a valid point within the region. The two-dimensional coordinates of each valid point are recorded one by one, with the x-axis representing the calculated delay deviation value and the y-axis representing the energy efficiency ratio deviation value, ensuring that no valid points are missed.

[0055] Next, the average values ​​of the horizontal and vertical coordinates of all valid points are calculated separately. During the calculation, strict data precision is maintained (0.1 milliseconds for the horizontal axis and 0.01 milliseconds for the vertical axis). An extreme point removal criterion is set; points exceeding ±3 times the standard deviation of the corresponding coordinate average are identified as extreme points and removed to avoid them affecting the accuracy of the average. After calculation, the average horizontal and vertical coordinates are combined to obtain the centroid coordinates of this dynamic strategy feature domain in the strategy analysis plane, denoted as (…). x c ,y c ),in x c The average coordinate of the horizontal axis. y c The average coordinates on the vertical axis and the centroid coordinates accurately reflect the core offset direction of the current platform performance distribution. Finally, the rationality of the centroid coordinates is verified by judging whether the centroid coordinates are within the closed area enclosed by the boundary points (consistent with the method for determining the core points within the area). It is confirmed that the centroid coordinates are not abnormal, providing accurate and reliable core reference coordinates for the subsequent calculation of the strategy drift vector.

[0056] Step 7.2 involves comparing the centroid coordinates with a preset platform equilibrium reference axis to calculate the vertical distance and direction angle from the centroid to the reference axis, synthesizing the strategy drift vector. Specifically, this includes: first, retrieving the preset platform equilibrium reference axis, which is a predefined reference axis within the strategy analysis plane representing the platform's performance equilibrium state. Its setting is based on the core principle of optimally coordinating the calculation of delay deviation and energy efficiency ratio deviation, aligning with the overall performance requirements of the heterogeneous computing platform. Specifically, it is defined as a straight line with the preset equation as follows: y=m·x ,in m The slope of the reference axis, with a preset value of -1, represents the direction of the ideal trade-off between reducing computational latency and improving energy efficiency ratio. That is, a one-unit reduction in latency deviation corresponds to a one-unit increase in energy efficiency ratio deviation. This direction serves as a reference benchmark for balancing platform performance. At the same time, the positive direction of the reference axis is defined, that is, the direction from the origin to the negative direction of latency deviation and the positive direction of energy efficiency ratio deviation. The core parameters such as the slope, linear equation, and reference direction of the reference axis are marked to ensure that the definition of the reference axis is clear and traceable.

[0057] The determined centroid coordinates ( x c ,y c The position of the centroid is precisely compared with the platform's equilibrium reference axis. The comparison process is carried out in two steps: first, the distance calculation logic from a point to a line is used to calculate the distance from the centroid to the reference axis. y=m·xThe vertical distance, denoted as d, directly reflects the degree of deviation between the current platform performance distribution and the equilibrium state. The larger the distance d, the more serious the performance distribution deviates from the equilibrium reference axis, and vice versa. The data precision is strictly maintained during the calculation process (0.01 is retained). Next, the direction angle of the centroid relative to the reference axis is calculated, denoted as θ. The angle range is set from 0° to 360°, with the positive direction of the reference axis as 0° and the clockwise direction as the direction of angle increase. By accurately determining the direction angle θ through the relative position of the centroid coordinates and the reference axis, the specific direction of performance deviation is characterized. For example, if θ is between 90° and 180°, it means that the performance deviation direction is high latency and low energy efficiency.

[0058] Finally, the calculated vertical distance d is used as the vector magnitude, and the direction angle θ is used as the vector direction to synthesize the vector, determining the direction (determined by the direction angle θ) and magnitude (determined by the vertical distance d), thus generating the policy drift vector, denoted as . This vector fully and accurately reflects the drift of the current platform performance strategy relative to the equilibrium state. After synthesis, the rationality of the vector is verified to confirm that the direction and distance of the vector correspond to the actual performance deviation of the current platform and there is no logical contradiction.

[0059] Step 7.3 extracts the direction eigenvalues ​​and magnitude values ​​of the policy drift vector, and passes them as input parameters to the predefined policy response function. Specifically, this includes: parsing the policy drift vector and extracting its direction eigenvalues ​​and magnitude values, where the direction eigenvalues ​​are denoted as... This is a value obtained by normalizing the direction and angle of a vector. The normalization range is set to 0 to 1, and the value corresponds one-to-one with the direction and angle, which can accurately represent the specific direction of drift, such as... Corresponding to the direction of low latency and high energy efficiency, Corresponding to the direction of high latency and low energy efficiency; the modulus value is denoted as This is the value obtained after standardizing the perpendicular distance of the vector. The standardized value also ranges from 0 to 1. The larger the magnitude value, the more serious the deviation of the current platform performance strategy from the equilibrium baseline axis, and vice versa. Data precision is strictly preserved during the extraction process. Reserve 0.01. (Keep 0.01) to ensure that the two values ​​accurately reflect the core features of the vector, and at the same time verify the rationality of the two values ​​to confirm that they are both within the preset range of 0 to 1 and there are no abnormal values.

[0060] The specific mathematical expression for the predefined policy response function is then determined; this function is used to receive directional eigenvalues. With modulus value The corresponding intermediate parameters are output for further processing in step 7.4, and the expression is: ; in It is the intermediate output value of the policy response function, and is a core parameter for nonlinear mapping and normalization. Its value range varies. , The changes are not within a fixed range and will be normalized to the range of 0 to 1 later. The directional feature value of the strategy drift vector has been normalized and its value range is strictly [0,1]. It accurately represents the specific location of the performance drift and corresponds one-to-one with the drift direction angle. This is the magnitude of the strategy drift vector, which has been standardized and strictly ranges from [0,1]. It characterizes the degree to which the performance strategy deviates from the platform equilibrium baseline. β The larger the value, the more severe the deviation. k It is a preset fixed weight coefficient with a value range of [0,1]. It is preset by the performance requirements of the heterogeneous computing platform and the default value is 0.6. e It is a natural constant, with a value of approximately 2.71828. It is the core constant of the exponential term, used to construct nonlinear mapping relationships and accurately quantify the modulus value. β The strength of the impact on the output results; As an exponential term, its core function is to measure the modulus value. Perform nonlinear attenuation processing to avoid When the value is too large, the output value will be affected. Abnormal fluctuations.

[0061] The core logic of this expression is to use the exponential term ( Nonlinear strengthening modulus value The corresponding degree of deviation has an impact, combined with the weighting coefficient. k Taking into account directional eigenvalues The guiding role of the expression enables precise quantification of drift vector features, and the order of operations and symbols in the expression are correct and conform to mathematical operation standards. After the expression is confirmed to be correct, the extracted directional feature values ​​are... With modulus value As a set of input parameters, the parameter format and precision are adjusted according to the parameter requirements of the policy response function. Then, the two parameters are precisely passed to the predefined policy response function. Detailed parameter passing information is recorded during the process, including... , Specific values, weighting coefficients k The current value must be strictly controlled to avoid situations such as parameter loss, incorrect transmission, incorrect format, or numerical deviation.

[0062] Step 7.4 involves performing nonlinear mapping and normalization on the direction eigenvalues ​​and magnitude values ​​using a predefined policy response function, and outputting a policy correction factor. Specifically, this includes receiving the direction eigenvalues. With modulus value Then, the intermediate output values ​​are calculated first. Then, based on this intermediate output value, the policy correction factor is finally output through nonlinear mapping and normalization. The specific implementation process is as follows: First, confirm that the input parameter is the intermediate output value of the policy response function. The validity of the intermediate value was verified to confirm that it had no abnormal fluctuations and that its numerical range met the expected function operation. If a negative value is found, its absolute value is taken to avoid abnormal correction direction and ensure the rationality of the input intermediate value; then nonlinear mapping processing is performed, the core purpose of which is to determine the intermediate value. The size of the correction is used to differentiate the targeted strengthening and correction efforts. The specific formula is as follows: ,in G ( F ) represents the output value after nonlinear mapping. F Intermediate output value of the policy response function The core function of this formula is to convert intermediate values. F Nonlinear mapping to [-1 , The interval [1] preserves the drift characteristic intensity corresponding to F while avoiding correction deviations caused by extreme values.

[0063] After mapping is complete, for G ( F Sign correction is performed to align the correction factor with the performance drift direction. That is, when drift leads to performance degradation, the correction factor is positive, corresponding to positive correction; when drift improves performance, the correction factor is negative, corresponding to fine-tuning correction. Normalization is then performed to adjust the sign-corrected factor. G ( F Mapped to [0 , The preset range of 1] is given by the formula: ,in C The policy correction factor is the final output. G ( F () represents the nonlinear mapping value after sign correction. Nonlinear mapping value G ( F The preset minimum value is -1. Nonlinear mapping value G ( F The preset maximum value is 1, which strictly preserves data precision during the normalization process and ensures that the output correction factor is standardized and uniform.

[0064] Finally, the policy correction factor for the output.C Perform a reasonableness check to confirm that its value range is strictly within [0, 1, 2, 3]. , Within [1], the performance drift of the current platform is considered, and the magnitude of the correction factor is verified to ensure its reasonableness. For example, the greater the drift, the closer the correction factor should be to 1; the smaller the drift, the closer the correction factor should be to 0. If any anomalies are found, the mapping and normalization processes are re-performed to finally output a standardized and accurate strategy correction factor. C This factor will be directly used for parameter optimization and dynamic adjustment of data allocation strategies in subsequent heterogeneous computing feature analysis models, enabling precise correction of platform performance strategies and ensuring that platform performance always aligns with the optimal equilibrium state.

[0065] In a preferred embodiment of the present invention, step 8 above may include: Step 8.1: Using the set parsing rules, the strategy correction factor is decomposed into a model parameter adjustment component and a weight rule adjustment component. Specifically, this includes: first, retrieving the set strategy correction factor parsing rules. These rules are standardized decomposition specifications pre-stored in the heterogeneous computing platform configuration, defining the parsing logic, component allocation ratios, and verification standards. The core principle is to accurately decompose the strategy correction factor into a model parameter adjustment component and a weight rule adjustment component based on the numerical value of the strategy correction factor and the current platform's performance drift characteristics. The decomposition ratio can be dynamically adapted according to the task type. By default, the model parameter adjustment component accounts for 60%, and the weight rule adjustment component accounts for 40%, and the values ​​of the two components (denoted as...) are... C m and C w ) by strategy correction factor C (Value range [0 , 1) Determined proportionally, i.e. C m +C w =C Therefore, the range of values ​​for each component is also [0, 1, 2, 3]. , [1] During the decomposition process, the basic allocation ratio of the two components is first determined based on the analytical rules. Then, combined with the core reasons for the current performance drift (if the drift is mainly due to model prediction bias, the proportion of the model parameter adjustment component is appropriately increased; if it is due to unreasonable weight allocation, the proportion of the weight rule adjustment component is increased), the basic ratio is fine-tuned. Subsequently, the specific values ​​of the two components are calculated. After the decomposition is completed, a double verification is performed. First, it is confirmed that the sum of the two components is equal to the original policy correction factor, and there is no numerical deviation. Second, it is verified that the numerical range of each component is between 0 and 1 to ensure that the component values ​​are reasonable and to avoid decomposition errors. Finally, two accurate and effective adjustment components are obtained.

[0066] Step 8.2 involves iteratively updating the internal parameters responsible for feature extraction and performance prediction in the heterogeneous computing feature parsing model based on the model parameter adjustment components. Specifically, this includes determining the range of internal parameters responsible for feature extraction and performance prediction in the heterogeneous computing feature parsing model. This includes the feature mapping coefficients and feature selection thresholds of the feature extraction module, as well as the deviation correction coefficients and prediction regression coefficients of the performance prediction module. These parameters directly affect the model's accuracy in extracting heterogeneous performance features and the accuracy of the initial performance prediction, and are directly related to the prediction logic of the model in Step 1.4. Subsequently, using the obtained model parameter adjustment components as the core input, and combining them with the performance deviation characteristics of the current platform—that is, the core issue reflected by the multi-dimensional performance deviation vector—this process is then applied to… The internal parameters are updated iteratively in a targeted manner. The update process adopts a step-by-step iterative approach, and the step size of each iteration is determined by the value of the model parameter adjustment component. The larger the component value, the larger the iteration step size and the stronger the update force, and vice versa, to avoid parameter mutations that could lead to model instability. After each iteration, the prediction accuracy and feature extraction effect of the model are verified. The deviation between the performance prediction value output by the updated model and the actual performance index is compared. If the deviation does not reach the preset standard, the iteration continues until the model parameters are adjusted to the optimal state. After the iteration is completed, the updated internal parameters are fixed, and the stability and accuracy of the model are verified again to ensure that the updated model can accurately adapt to the performance distribution of the current platform and improve the accuracy of feature extraction and performance prediction.

[0067] Step 8.3: Adjust the components according to the weighting rules. Modify the weighting calculation formulas or mapping relationships associated with the delay factor, energy efficiency factor, and resource balance factor in the dynamic weighting calculation rules. Specifically, this includes: first, retrieving the dynamic weighting calculation rules and confirming the weighting calculation formulas or mapping relationships associated with the delay factor, energy efficiency factor, and resource balance factor. These rules directly determine the priority of consideration for computational delay, energy efficiency utilization, and resource balance during data allocation, maintaining consistency with the weighting factor application logic in Step 2.1; then, based on the obtained weighting rule adjustment components, and considering the current platform's performance drift (if the delay deviation is too large, focus on correcting the weight configuration related to the delay factor; if the energy efficiency deviation is too large, focus on correcting the energy efficiency factor), the adjustment is further refined. (Sub-related configurations) are used to make targeted corrections to the corresponding weight calculation formulas or mapping relationships. During the correction process, the specific formulas or mapping relationships that need to be corrected are first located, and then the values ​​of the components are adjusted according to the weight rules. The weight coefficients or thresholds of the mapping relationships in the formulas are adjusted. For example, if the latency is too high, the coefficient of the latency factor in the weight calculation formula can be increased to enhance the weight of latency consideration in data allocation. If resource utilization is unbalanced, the mapping threshold of the resource balance factor can be corrected to optimize the resource allocation logic. After the correction is completed, the corrected weight calculation formulas or mapping relationships are verified to confirm that they can effectively balance latency, energy efficiency and resource utilization, and that the calculation results are reasonable. This avoids the situation of weight imbalance after correction and ensures that the corrected dynamic weight calculation rules are adapted to the current platform performance status.

[0068] Step 8.4 integrates the heterogeneous computing feature parsing model after parameter updates with the dynamic weight calculation rules after rule correction, thereby forming a closed-loop optimization circuit and generating an updated data allocation strategy. Specifically, this includes: performing compatibility verification on the heterogeneous computing feature parsing model after parameter updates and the dynamic weight calculation rules after rule correction, focusing on confirming that the updated model output (initial performance estimate, feature extraction results) can accurately adapt to the corrected weight calculation rules, and that there are no conflicts in data format, parameter range, or logical association, ensuring that they can work collaboratively after integration; after successful verification, the integration process is initiated, deeply integrating the updated model and the corrected rules, clarifying the linkage logic between the model output and the weight rules, i.e., the performance estimate and feature data output by the model serve as the input to the weight rules, and the weight rules are based on... Based on this data, the weight scores of each computing unit and each transmission path are calculated to provide a basis for data allocation decisions. This forms a closed-loop optimization loop of data allocation, performance acquisition, deviation calculation, strategy correction, model and rule updates, and new data allocation, enabling dynamic self-optimization of platform performance. After integration, an updated data allocation strategy is generated based on the updated model and corrected weight rules. The new strategy focuses on optimizing the computing unit selection logic, data transmission path planning, and data scheduling priority, while retaining the reasonable parts of the original strategy. After generation, the feasibility and effectiveness of the new strategy are verified to confirm that it can solve the current platform's performance drift problem, improve data allocation efficiency, reduce computing latency, and optimize energy efficiency. Finally, an executable updated data allocation strategy is output for subsequent task execution, completing the entire closed-loop optimization process.

[0069] like Figure 2 As shown, embodiments of the present invention also provide an adaptive data allocation system based on an FPGA heterogeneous computing platform, comprising: The feature acquisition and prediction module is used to acquire feature data of computing tasks and load data of each computing unit in the platform in real time, perform joint analysis and prediction through a pre-set heterogeneous computing feature parsing model, and output task classification results and their initial performance estimates on each computing unit; the computing unit includes at least FPGA, CPU and GPU; The allocation scheme generation module is used to generate a data allocation scheme for determining the target computing units and transmission paths of data based on task classification and initial performance estimates through dynamic weight calculation. The scheme execution and status acquisition module is used to execute the data allocation scheme, and generate task execution status information by scheduling data and triggering calculations. The deviation analysis module is used to monitor the calculation process, collect actual performance data and compare it with the initial performance estimate, and generate a multi-dimensional performance deviation vector. Based on the multi-dimensional performance deviation vector, for each calculation unit and its corresponding task classification, a set of core performance measured values ​​in the current execution cycle is dynamically extracted to form a series of heterogeneous performance feature anchor points. The strategy feature domain construction module is used to map a series of heterogeneous performance feature anchors to a strategy analysis plane with computational delay and energy efficiency ratio as coordinate axes, and construct a dynamic strategy feature domain based on the distribution density. The correction factor generation module is used to calculate the centroid of the dynamic policy feature domain and solve the policy drift vector of the centroid relative to the preset platform equilibrium reference axis; based on the direction and magnitude of the policy drift vector, the policy correction factor is generated by calculating the predefined policy response function. The strategy update module is used to adaptively adjust the preset heterogeneous computing feature parsing model parameters and the dynamic weight calculation rules according to the strategy correction factor, so as to update the data allocation strategy.

[0070] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An adaptive data allocation method based on an FPGA heterogeneous computing platform, characterized in that, The method includes: The system collects feature data of computing tasks and load data of each computing unit in the platform in real time, performs joint analysis and prediction through a pre-set heterogeneous computing feature analysis model, and outputs task classification results and their initial performance estimates on each computing unit; the computing unit includes at least FPGA, CPU and GPU. Based on the task classification results and initial performance estimates, a data allocation scheme is generated through dynamic weight calculation to determine the target computing units and transmission paths of the data. The execution data allocation scheme is implemented by scheduling data and triggering calculations to generate task execution status information; Monitor the calculation process, collect actual performance data and compare it with the initial performance estimate to generate a multi-dimensional performance deviation vector; Based on the multidimensional performance deviation vector, for each computing unit and its corresponding task classification, a set of core performance measured values ​​in the current execution cycle are dynamically extracted to form a series of heterogeneous performance feature anchors. A series of heterogeneous performance characteristic anchor points are mapped to a strategy analysis plane with computational delay and energy efficiency ratio as coordinate axes, and a dynamic strategy feature domain is constructed based on the distribution density. Calculate the centroid of the dynamic policy feature domain and solve for the policy drift vector of the centroid relative to the preset platform equilibrium reference axis; calculate and generate the policy correction factor based on the direction and magnitude of the policy drift vector using a predefined policy response function. Based on the strategy correction factor, the preset parameters of the heterogeneous computing feature parsing model and the rules for dynamic weight calculation are adaptively adjusted to update the data allocation strategy.

2. The adaptive data allocation method based on an FPGA heterogeneous computing platform according to claim 1, characterized in that, The system collects feature data of computing tasks and load data of each computing unit in the platform in real time, performs joint analysis and prediction through a pre-built heterogeneous computing feature analysis model, and outputs task classification results and their initial performance estimates on each computing unit. The computing unit includes at least an FPGA, a CPU, and a GPU, including: The system acquires the original description information of the computing tasks to be processed and the original status data reported by each computing unit in the platform in real time, and generates the original task dataset and the original platform dataset. The original task dataset and the original platform dataset are normalized and vectorized preprocessed to generate standardized task feature vectors and platform state vectors. The task feature vector and platform state vector are input into the feature extraction layer of a pre-set heterogeneous computing feature parsing model; the parallelism and computational intensity features of the task are extracted through the feature extraction layer, and the heterogeneous resource availability features of the platform are extracted to generate a fused feature vector. The fused feature vector is input into the classification and prediction layer of a pre-set heterogeneous computing feature parsing model. The classification and prediction layer outputs the task classification result according to the pre-set mapping relationship, and simultaneously outputs the initial performance estimate.

3. The adaptive data allocation method based on an FPGA heterogeneous computing platform according to claim 2, characterized in that, Based on the task classification results and initial performance estimates, a data allocation scheme is generated through dynamic weight calculation to determine the target computing units and transmission paths for the data, including: Based on the task classification results, a set of weight factors matching the task type is loaded from the pre-set strategy library, wherein the weight factors include at least the delay factor, energy efficiency factor and resource balance factor. Based on the initial performance estimate, the comprehensive performance score of each computing unit as a candidate computing unit for the current task is calculated; wherein, the comprehensive performance score is obtained by weighted fusion calculation of the initial performance estimate corresponding to each candidate computing unit and its corresponding weight factor; All candidate computing units are sorted according to their overall performance scores. The computing unit with the highest ranking is selected as the target computing unit. Based on the physical topology location of the target computing unit in the platform, the transmission path that maximizes the overall performance score of the target computing unit is determined from the preset path table, thus forming the target unit decision and path decision. The target unit decision and path decision are encapsulated to generate a data allocation scheme with a precise executable format.

4. The adaptive data allocation method based on an FPGA heterogeneous computing platform according to claim 3, characterized in that, The execution data allocation scheme involves scheduling data and triggering computations to generate task execution status information, including: The data allocation scheme with a definite executable format is parsed, and the target unit decision and path decision encapsulated therein are extracted to obtain the target computing unit identifier and the exact transmission path description. Based on the exact transmission path description, the input data to be processed is scheduled from the source storage location to the input buffer corresponding to the target computing unit, and a data ready signal is returned; In response to the data ready signal, a calculation trigger command is synchronously sent to the target computing unit to start the target computing unit to perform calculation processing on the data that has been scheduled to the input buffer; After the computation process starts, the computation progress, data buffer status and resource usage indicators of the target computing unit are continuously collected and integrated to generate task execution status information.

5. The adaptive data allocation method based on an FPGA heterogeneous computing platform according to claim 4, characterized in that, The calculation process is monitored, actual performance data is collected and compared with the initial performance estimates, and a multi-dimensional performance deviation vector is generated, including: Receive and parse task execution status information, and extract the set of actual performance indicators generated by the target computing unit when processing the current task. Obtain the initial performance estimate corresponding to the current task and target computing unit, and calculate the difference between each indicator in the actual performance indicator set and the corresponding item of the initial performance estimate; The calculated set of performance differences is normalized and vectorized according to a preset dimensional order to generate the multidimensional performance deviation vector.

6. The adaptive data allocation method based on an FPGA heterogeneous computing platform according to claim 5, characterized in that, Based on the multidimensional performance deviation vector, for each computing unit and its corresponding task classification, a set of core performance measurement values ​​within the current execution cycle is dynamically extracted, forming a series of heterogeneous performance feature anchors, including: Receive a multi-dimensional performance deviation vector, and select the components representing the dimensions of delay deviation, power consumption deviation and resource utilization deviation from the multi-dimensional performance deviation vector according to preset rules, and use them as the measured values ​​of the core performance. The core performance measured values ​​are bound to the identifier of the current computing unit and the task type identifier of the current task category to generate a preliminary performance data tuple. Based on predefined formatting rules, the measured values ​​in the initial performance data tuple are processed to unify units and align precision, generating a heterogeneous performance feature anchor point with a unified format. The heterogeneous performance feature anchors with a uniform format generated for all processing units participating in the computation during the current execution cycle are aggregated to form the series of heterogeneous performance feature anchors.

7. The adaptive data allocation method based on an FPGA heterogeneous computing platform according to claim 6, characterized in that, A series of heterogeneous performance characteristic anchors are mapped to a policy analysis plane with computational delay and energy efficiency ratio as coordinate axes, and a dynamic policy feature domain is constructed based on the distribution density, including: Receive the series of heterogeneous performance characteristic anchor points, and parse the normalized calculation delay deviation value and energy efficiency ratio deviation value from each anchor point; The calculated delay deviation value and energy efficiency ratio deviation value resolved from each anchor point are mapped to the strategy analysis plane as a set of coordinate pairs to generate the corresponding plane mapping points; Based on the spatial distribution of all planar mapping points on the strategy analysis plane, a preset density clustering algorithm is used to identify the core point set, and the boundary is determined based on the identified core point set. Connecting the points on the defined boundary, a closed geometric region is constructed in the strategy analysis plane, serving as a dynamic strategy feature domain characterizing the current platform performance distribution.

8. The adaptive data allocation method based on an FPGA heterogeneous computing platform according to claim 7, characterized in that, Calculate the centroid of the dynamic policy feature domain and solve for the policy drift vector of the centroid relative to the preset platform equilibrium reference axis. Based on the direction and magnitude of the policy drift vector, a policy correction factor is calculated using a predefined policy response function, including: Receive the boundary information of the dynamic strategy feature domain, and determine the centroid coordinates of the dynamic strategy feature domain in the strategy analysis plane by calculating the average coordinates of all points within its geometry. The position of the centroid coordinates is compared with the preset platform equilibrium reference axis to calculate the vertical distance and direction angle from the centroid to the reference axis, and the strategy drift vector is synthesized. Extract the directional eigenvalues ​​and magnitude values ​​of the policy drift vector, and pass them as input parameters to the predefined policy response function; The directional eigenvalues ​​and magnitude values ​​are nonlinearly mapped and normalized using a predefined policy response function, and a policy correction factor is output.

9. The adaptive data allocation method based on an FPGA heterogeneous computing platform according to claim 8, characterized in that, Based on the strategy correction factor, the preset parameters of the heterogeneous computing feature parsing model and the rules for dynamic weight calculation are adaptively adjusted to update the data allocation strategy, including: By using the defined analytical rules, the strategy correction factor is decomposed into a model parameter adjustment component and a weight rule adjustment component. Based on the model parameters, the internal parameters responsible for feature extraction and performance prediction in the heterogeneous computing feature parsing model are updated iteratively in a targeted manner. The components are adjusted according to the weighting rules, and the weighting calculation formulas or mapping relationships associated with the delay factor, energy efficiency factor and resource balance factor in the dynamic weighting calculation rules are modified. The heterogeneous computing feature analysis model after parameter updates is integrated with the dynamic weight calculation rule after rule correction to form a closed-loop optimization circuit and generate an updated data allocation strategy.

10. An adaptive data allocation system based on an FPGA heterogeneous computing platform, the system implementing the method as described in any one of claims 1 to 9, characterized in that, include: The feature acquisition and prediction module is used to collect feature data of computing tasks and load data of each computing unit in the platform in real time. It performs joint analysis and prediction through a pre-built heterogeneous computing feature parsing model and outputs task classification results and initial performance estimates on each computing unit. The allocation scheme generation module is used to generate a data allocation scheme for determining the target computing units and transmission paths of data based on task classification and initial performance estimates through dynamic weight calculation. The scheme execution and status acquisition module is used to execute the data allocation scheme, and generate task execution status information by scheduling data and triggering calculations. The deviation analysis module is used to monitor the calculation process, collect actual performance data and compare it with the initial performance estimate, and generate a multi-dimensional performance deviation vector. Based on the multidimensional performance deviation vector, for each computing unit and its corresponding task classification, a set of core performance measured values ​​in the current execution cycle are dynamically extracted to form a series of heterogeneous performance feature anchors. The strategy feature domain construction module is used to map a series of heterogeneous performance feature anchors to a strategy analysis plane with computational delay and energy efficiency ratio as coordinate axes, and construct a dynamic strategy feature domain based on the distribution density. The correction factor generation module is used to calculate the centroid of the dynamic policy feature domain and solve the policy drift vector of the centroid relative to the preset platform equilibrium reference axis; based on the direction and magnitude of the policy drift vector, the policy correction factor is generated by calculating the predefined policy response function. The strategy update module is used to adaptively adjust the preset heterogeneous computing feature parsing model parameters and the dynamic weight calculation rules according to the strategy correction factor, so as to update the data allocation strategy.

Images