FPGA-based cluster model acceleration method and device

Abstract

The application discloses a cluster model acceleration method and device based on FPGA, and relates to the technical field of model acceleration.The method comprises the following steps: converting a cluster simulation model into a digital circuit structure file, and burning the digital circuit structure file into an FPGA board card; splitting the digital circuit structure file into multiple independent calculation modules according to functions; encapsulating the calculation modules into multiple IP cores based on the requirements of different individuals in the cluster; in response to input data received in the DDR of the FPGA board card, triggering all IP cores to perform corresponding tasks in parallel by a hardware state machine, and controlling the calculation processes of the IP cores based on the main clock of the FPGA board card; and writing the task processing results into the DDR of the FPGA board card by the IP cores, reading the DDR to obtain the simulation results of the cluster simulation model. The technical problem that the real-time performance of the existing model acceleration method is poor and the economic cost is high in a large-scale cluster simulation scene is solved, so that the high real-time performance of simulation can be ensured and the economic cost can be effectively reduced in the large-scale cluster simulation scene.

Description

Technical Field

[0001] This application relates to the field of model acceleration technology, and in particular to a cluster model acceleration method and apparatus based on FPGA. Background Technology

[0002] As a core supporting technology for smart agriculture, emergency rescue, industrial inspection, and environmental monitoring, the reliability and effectiveness of drone swarm technology heavily rely on high-precision simulation for verification. However, with the continuous expansion of drone swarm scale and the increasing complexity of tasks, the contradiction between the synchronization of physical and simulation time, and between algorithm computational efficiency and real-time performance, is gradually intensifying, becoming a key factor restricting the development of drone swarm technology.

[0003] Currently, mainstream model simulation systems generally adopt a computing architecture based on a general-purpose central processing unit (CPU). The CPU is based on the von Neumann architecture, and its core operation mode is to execute instructions sequentially. When processing a single UAV model, its mature instruction pipeline and computing units can meet the computational requirements. However, in UAV swarm simulation scenarios, the computational scale of the swarm model grows exponentially. The CPU's serial execution mechanism causes the computation time of the swarm model to increase linearly with the size of the swarm model, making it difficult to meet the high real-time requirements of dynamic simulation, thus limiting the realism and responsiveness of the simulation system.

[0004] To address the aforementioned issues, existing technologies employ two methods for acceleration: First, using high-performance CPUs with higher clock speeds and more cores to improve computer performance at the hardware level. However, this performance improvement faces physical bottlenecks; the serial execution architecture has extremely low parallel efficiency for strongly correlated model solving tasks requiring strict sequential execution (such as multi-machine collaborative decision chains). Furthermore, the high research and manufacturing costs of high-performance CPUs lead to a sharp increase in overall system costs, resulting in poor economic efficiency. Second, splitting the UAV swarm model into multiple subsets and distributing the simulation across different simulators distributes the computational burden from a simulation architecture perspective. Strong coupling and collaborative relationships exist between subsets within a UAV swarm; distributed simulation requires the synchronization and exchange of large amounts of state data (such as position, velocity, attitude, sensor information, and control commands) between multiple simulation nodes within microseconds. In large-scale (hundreds or more) swarms, the total amount of synchronized data can reach tens to hundreds of KB (bytes), and network latency and communication protocol parsing overhead can easily cause data synchronization delays. Furthermore, even with a real-time system, kernel scheduling, interrupt response, and network stack processing still introduce time jitter on the order of tens of microseconds. This jitter, when combined with network latency, can easily cause simulation timeouts and state inconsistencies, severely impacting the reliability of simulation results and the system's real-time performance, making it difficult to meet the requirements of high-precision and robust real-time simulation. In addition, introducing multiple simulators significantly increases system size, power consumption, and total cost, while also increasing the complexity of deployment and subsequent maintenance. Summary of the Invention

[0005] This application provides an FPGA-based cluster model acceleration method and apparatus, which solves the technical problems of poor real-time performance and high cost of existing model acceleration methods in large-scale cluster simulation scenarios.

[0006] In a first aspect, embodiments of this application provide an FPGA-based method for accelerating cluster models, comprising: converting a cluster simulation model into a digital circuit structure file and burning it into an FPGA board; dividing the digital circuit structure file into multiple independent computing modules according to their functions; encapsulating the computing modules into multiple IP cores within the FPGA board based on the needs of different individuals in the cluster; responding to input data received in the DDR of the FPGA board, a hardware state machine triggers all IP cores to execute corresponding tasks in parallel, and controls the computing process of each IP core based on the master clock of the FPGA board; each IP core writes the task processing result into the DDR of the FPGA board, and obtains the simulation result of the cluster simulation model by reading the DDR.

[0007] In conjunction with the first aspect, in one possible implementation, before converting the cluster simulation model into a digital circuit structure file, the method further includes: converting continuous computation in the cluster simulation model into discrete computation; and / or, constructing a logic algorithm module library to avoid the algorithm from being decoupled from the hardware logic; and / or, converting the data type in the cluster simulation model into a set type and adjusting the data operation type to the set type.

[0008] In conjunction with the first aspect, in one possible implementation, the conversion of the cluster simulation model into a digital circuit structure file includes: converting the algorithm logic in the cluster simulation model into hardware logic; converting the cluster simulation model into hardware identification code for FPGA board recognition; and using a toolchain to synthesize and place and route the hardware identification code to generate a digital circuit structure file.

[0009] In conjunction with the first aspect, in one possible implementation, the step of dividing the digital circuit structure file into multiple independent computing modules according to function includes: analyzing the module hierarchy of the digital circuit structure file using FPGA development tools; determining the logical boundaries of the division based on the module hierarchy and the logic algorithm module library; and, based on the logical boundaries, extracting multiple independent computing modules from the digital circuit structure file and designing standardized interfaces for each computing module.

[0010] In conjunction with the first aspect, in one possible implementation, the encapsulation of computing modules into multiple IP cores based on the needs of different individuals in the cluster includes: iteratively executing the IP core instantiation step until the resource specifications of the FPGA board are met; the IP core instantiation step includes: determining multiple computing modules according to the needs of individuals in the cluster; and connecting the standardized interfaces of each computing module according to the data flow relationship between each computing module to form an IP core.

[0011] In conjunction with the first aspect, in one possible implementation, in response to input data received in the DDR memory of the FPGA board, the hardware state machine triggers all IP cores to execute corresponding tasks in parallel, and controls the computation process of each IP core based on the FPGA board's master clock, including: synchronizing the clock of each IP core based on the FPGA board's master clock; splitting the input data according to the number of IP cores and requirements in the FPGA board, and marking a storage address for each split input data; the DDR memory of the FPGA board receiving the split input data and storing it in the corresponding storage address; the hardware state machine deployed inside the FPGA board triggering the synchronous startup of all IP cores; each IP core reading input data from the corresponding storage address and feeding back to the hardware state machine; the hardware state machine controlling all IP cores to execute computation tasks in parallel according to a preset scheduling strategy; and when the maximum clock cycle is reached, the hardware state machine controlling all IP cores to terminate the current computation task.

[0012] In conjunction with the first aspect, one possible implementation also includes: when the cluster size exceeds the capacity of a single FPGA board, multiple FPGA boards are connected via a high-speed bus to form a star topology, and the multiple FPGA boards are installed in the same industrial computer and run on the same real-time operating system; one of the FPGA boards is designated as the master card, and the master clock of the master card is used as a reference to calibrate the clocks of the remaining FPGA boards; the master card manages computing resources and allocates computing tasks to all FPGA boards.

[0013] Secondly, embodiments of this application provide an FPGA-based cluster model acceleration device, comprising: a hardware module for converting a cluster simulation model into a digital circuit structure file and burning it into an FPGA board; a splitting module for splitting the digital circuit structure file into multiple independent computing modules according to function; an encapsulation module for encapsulating the computing modules into multiple IP cores within the FPGA board based on the needs of different individuals in the cluster; a task module for triggering all IP cores to execute corresponding tasks in parallel via a hardware state machine in response to input data received in the DDR of the FPGA board, and controlling the computing process of each IP core based on the master clock of the FPGA board; and a result module for each IP core to write the task processing result into the DDR of the FPGA board, and obtaining the simulation result of the cluster simulation model by reading the DDR.

[0014] Thirdly, embodiments of this application provide an apparatus comprising: a processor; a memory for storing processor-executable instructions; wherein, when the processor executes the executable instructions, it implements the method as described in the first aspect or any possible implementation of the first aspect.

[0015] Fourthly, embodiments of this application provide a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium including storage for storing a computer program or instructions that, when executed, cause the method described in the first aspect or any possible implementation of the first aspect to be implemented.

[0016] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0017] This application's embodiments, by employing FPGA as acceleration hardware, significantly reduce costs. By converting the cluster simulation model into a digital circuit structure file and burning it onto the FPGA board, the parallel computing capabilities of the FPGA board can be utilized to improve the solution efficiency of the cluster simulation model, meeting the high real-time requirements of dynamic simulation. By functionally splitting the digital circuit structure file into multiple independent computing modules, flexible allocation and efficient utilization of computing resources can be achieved, while also facilitating anomaly localization. By encapsulating IP cores, synchronous triggering and process control of all IP cores can be achieved. Combined with the precise timing management of the FPGA board's master clock, it ensures that each computing module completes data interaction and task execution within microseconds, effectively solving the state inconsistency problem caused by network latency and time jitter in distributed simulation. This effectively solves the technical problems of poor real-time performance and high economic costs of existing model acceleration methods in large-scale cluster simulation scenarios, thereby achieving higher solution efficiency, lower resource consumption, and more precise timing control. This ensures both high real-time performance and effective cost reduction in large-scale cluster simulation scenarios, providing reliable technical support for the efficient and stable operation of large-scale cluster simulation. Attached Figure Description

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

[0019] Figure 1 A flowchart illustrating the FPGA-based cluster model acceleration method provided in this application embodiment;

[0020] Figure 2 A schematic diagram of the core scheduling framework provided in the embodiments of this application;

[0021] Figure 3 This is a schematic diagram of the structure of the FPGA-based cluster model acceleration device provided in the embodiments of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0023] The following description of some technologies involved in the embodiments of this application is provided to aid understanding and should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, some descriptions of well-known functions and structures are omitted in the following description.

[0024] Figure 1 This is a flowchart of the FPGA-based cluster model acceleration method provided in this application embodiment, including steps 101 to 105. Figure 1 This is merely one execution order shown in the embodiments of this application and does not represent the only execution order of the FPGA-based cluster model acceleration method. Where the final result can be achieved, Figure 1 The steps shown can be performed in parallel or in reverse order.

[0025] Step 101: Convert the cluster simulation model into a digital circuit structure file and burn it into the FPGA board. In this embodiment, the cluster is exemplarily taken as a drone cluster, which is not intended to limit the scope of protection of this application. Those skilled in the art can also use other clusters (such as robot clusters) to apply the method of this application to accelerate the simulation verification model.

[0026] In this embodiment of the application, the cluster simulation model can be simplified before conversion, removing redundant calculations and debugging code, optimizing high-consumption modules (e.g., splitting nested loops into parallel loops), reducing the waste of FPGA resources, and ensuring that more drone models (IP cores) can be run in parallel when using FPGA board acceleration in the future.

[0027] Specifically, delete debugging code and merge redundant calculations (e.g., keep only one copy of coordinate transformation logic shared by multiple modules). Optimize the logic of high-consumption modules; for example, split nested loops into parallel loops (utilizing multiple computing units on the FPGA board for simultaneous processing), and replace sequential logic with combinational logic for simple operations. Unify the input / output clock domains of each module (avoiding the consumption of extra resources for cross-clock domain synchronization), and use pipelined interfaces instead of parallel interfaces to reduce the number of signal lines.

[0028] To ensure the correctness of subsequent steps and the integrity of the core code, the cluster simulation model can be verified through simulation. Using the serial simulation logic on the CPU side as a benchmark, the cluster simulation model is simulated using floating-point data (such as 32 / 64-bit floating-point numbers). The simulation covers core logic such as UAV flight control, environmental interaction, and neighbor communication, outputting simulation results. The simulation results include key parameters such as the UAV's attitude angle, speed, and position, forming a floating-point benchmark dataset. Based on the floating-point benchmark dataset, the stability of the simulation results is assessed (whether there are logical flaws, data value divergence, etc.), ensuring that when converting the cluster simulation model into a digital circuit structure file, optimizations are only made to the data type and operation method, without changing the core algorithm logic of the cluster simulation model.

[0029] In this embodiment of the application, before performing step 101, the following may also be done: convert continuous computation in the cluster simulation model into discrete computation; and / or construct a logic algorithm module library to avoid the algorithm becoming disconnected from the hardware logic; and / or convert the data type in the cluster simulation model to a specified type and adjust the data operation type to the specified type.

[0030] Specifically, FPGA boards are good at handling parallel computing with discrete time steps, while traditional CPU-based cluster simulation models are mostly in the continuous time domain (such as dynamic models based on differential equations). Therefore, continuous computing needs to be discretized to adapt to FPGA boards.

[0031] Furthermore, numerical discretization methods (such as the Euler method and the Runge-Kutta method) are used to convert continuous computations (such as integration and differentiation) into discrete computations. For example, the attitude dynamics equations of a UAV... The discrete equations are: ,in, The attitude variable represents the state change over continuous time, and f represents the dynamic function over continuous time. Represents attitude state variables. This represents the k-th time step. Let F represent the control input, and T represent the discrete-time dynamic function. s The simulation step size is determined by the FPGA board's clock cycle and simulation accuracy. Furthermore, a balance must be struck between accuracy and hardware resource consumption during the conversion process. For example, a first-order Euler method (low resource consumption) is used for low-speed flight scenarios, while a fourth-order Runge-Kutta method (high accuracy, but requires additional hardware resources) is used for high-speed maneuvering scenarios.

[0032] After converting continuous computation into discrete computation, the remaining algorithms that cannot be converted to discrete can be protected from being disconnected from hardware logic by building a logic algorithm module library.

[0033] Specifically, the cluster simulation model contains a large number of repetitive or common algorithms, such as coordinate transformation, filtering, and PID (proportional-integral-derivative) control. Building a logic algorithm module library here can avoid redundant development, improve code generation efficiency, and increase hardware logic reuse rate.

[0034] Furthermore, the computational modules are divided according to the functions of different components of each individual (drone) in the cluster. Each computational module encapsulates independent input, output, and computational logic. For example, the attitude calculation module takes gyroscope and accelerometer data as input and outputs the drone's roll, pitch, and yaw angles. The path planning module takes target coordinates and obstacle information as input and outputs a sequence of flight path points. The environment interaction module takes wind speed and air pressure data as input and outputs the amount of interference to the flight attitude.

[0035] Those skilled in the art should realize that the logic algorithm module library constructed here should meet the hardware characteristics of the FPGA board, that is, the operation logic of each computing module has no circular dependencies (to avoid hardware deadlock), and the input / output interface adopts standardized timing (such as synchronous clock triggering).

[0036] For example, the data type is set to fixed-point. Specifically, traditional CPU-based cluster simulation models often use floating-point data (such as float32, double64). However, FPGA boards require significant resources (such as floating-point multipliers) to process floating-point operations. Therefore, the floating-point data in the cluster simulation model can be converted to a fixed-point data type compatible with the FPGA board (such as 16 / 32-bit fixed-point numbers, including integer and decimal places), and floating-point operations (such as floating-point multiplication / division) can be converted to fixed-point operations. By converting floating-point data to a fixed-point data type supported by the FPGA board, the problems of high resource consumption and large latency in floating-point operations on the FPGA board are solved. At the same time, precision control ensures that the converted model logic is consistent with the floating-point reference.

[0037] Furthermore, based on the accuracy requirements of the cluster simulation model, floating-point data is converted into fixed-point data supported by the FPGA board through hardware identification code (such as header file configuration of high-level synthesis tools and bit-width definition files in hardware description languages). For example, attitude angles, ranging from [- The result of converting this to 16-bit fixed-point data is: 1 sign bit + 3 integer bits + 12 decimal bits.

[0038] Furthermore, after adjusting both the data type and the data operation type to fixed-point types, the cluster simulation model (denoted as the fixed-point model) after type conversion can be simulated and verified. Specifically, the input data is kept consistent with the input of the cluster simulation model, the fixed-point model is run, and the simulation results of the fixed-point model are obtained. These results are then compared with the simulation results in the floating-point reference dataset. If the deviation exceeds a threshold (e.g., attitude angle error exceeds 0.1°, velocity convergence time exceeds 1 second), the bit width configuration of the fixed-point type is readjusted (e.g., increasing the number of decimal places), and then the fixed-point model is updated. The simulation verification is then repeated until the deviation between the simulation results of the fixed-point model and the floating-point reference dataset is less than or equal to the threshold. Through simulation verification of the fixed-point model, it is possible to determine whether the logic of fixed-point operations completely retains the core functionality of the original floating-point operations, preventing the type conversion error at this point from being propagated to subsequent stages and thus affecting the reliability of other processes.

[0039] In this embodiment, the algorithm logic in the cluster simulation model is converted into hardware logic. The cluster simulation model is then converted into hardware identification code for FPGA board recognition. A toolchain is used to synthesize and place and route the hardware identification code, generating a digital circuit structure file.

[0040] In this embodiment, the algorithm logic in the cluster simulation model is converted into hardware logic, including: converting serial loops and conditional statements into parallel circuit logic; converting mathematical operations into lookup tables or combinational circuits; and converting state update operations into clock-driven register updates.

[0041] Specifically, loops (such as iterating the status of multiple drones and processing multiple sets of environmental data) and conditional statements (such as obstacle avoidance judgment and mode switching) that are executed serially in the CPU need to be converted into hardware logic that can be executed in parallel on the FPGA board in order to eliminate instruction serial waiting.

[0042] For example, a serial, iterative task (such as calculating the state of a single UAV or filtering a single set of sensors) can be broken down into multiple independent hardware computing modules. This is achieved by instantiating multiple hardware computing modules using a module instantiation statement. Each hardware computing module represents one iteration, forming a parallel computing array. Each hardware computing module occupies independent FPGA resources (LUT, i.e., field-programmable lookup table or register), eliminating resource sharing conflicts. Furthermore, each hardware computing module must have standardized input (e.g., UAV ID, raw data) and output (e.g., updated state, filtering results) interfaces, which can be reused with computing modules in the logic algorithm module library. Then, the FPGA board's master clock generates a synchronization enable signal to simultaneously trigger multiple parallel hardware computing modules to start computing. All hardware computing modules complete their calculations within the same clock cycle, with the total time equal to the time taken by a single hardware computing module. This replaces the sequential execution of the CPU, shortening the computation cycle.

[0043] For example, for conditional statements, the branch judgments executed serially in the CPU (the corresponding branch must wait for the condition judgment result before execution) are transformed into multiplexer (MUX) combinational logic in the FPGA board. The core is to calculate all branch results simultaneously and select the output through the condition signal.

[0044] Furthermore, for each branch of the conditional statement (if, else if, else), an independent hardware processing module is designed to simultaneously calculate the output results of all branches, avoiding the serial delay caused by waiting for conditional judgments. Each hardware processing module simultaneously receives input data (battery level, current position) and outputs its own calculation results (path, instruction) in parallel. Then, the CPU's branch jump (conditional judgment, such as battery level comparison) is converted into a selection control signal, which selects the final output from all branch results through a multiplexer (MUX), completing the selection output in just one clock cycle. Moreover, the hardware logic after the conditional statement conversion must be pure combinational logic (no register feedback) to avoid timing loops (branch result feedback affecting conditional judgments). For example, the branch calculation for flight mode switching only depends on input data such as current battery level and position, and does not depend on the historical output of the hardware processing module itself, ensuring that the logic can be executed in parallel.

[0045] For example, mathematical operations (such as addition, subtraction, multiplication, division, trigonometric functions, and square roots) need to be converted into combinational circuits (simple operations) or lookup tables (LUTs) (complex operations) according to the complexity of the operation and the characteristics of FPGA resources, in order to reduce the operation clock cycle and reduce the hardware resource consumption.

[0046] Furthermore, simple operations can be built directly from basic arithmetic units (such as adders and multipliers) in the configurable logic blocks (CLBs) of the FPGA board, directly constructing combinational logic circuits without clock driving (output results are available as soon as input data is ready). Addition / subtraction operations utilize carry chain resources in the configurable logic blocks to construct parallel adders. For example, 16-bit fixed-point addition (UAV attitude angle increment calculation) is implemented using a carry-lookahead adder, completing the operation in one clock cycle. For low-precision multiplication (such as 8-bit control input × 8-bit gain coefficient), combinational logic multipliers (AND gate array + adder) are used. For high-precision multiplication (such as 16-bit fixed-point multiplication), the FPGA board's built-in DSP48 unit (hard-core multiplier) is reused, balancing speed and resources (one DSP48 unit can implement one 18×18-bit multiplication, completed in one clock cycle).

[0047] For complex calculations, a lookup table is used to pre-store the calculation results in a RAM (Random Access Memory) array. This mapping relationship between input parameters → address and output results → stored data allows for outputting the result within one clock cycle, replacing the CPU's real-time iterative calculation. Specifically, the range and precision of the calculation parameters are first determined. Then, using tools such as MATLAB or Python (programming languages), the values ​​of the output parameters corresponding to all input parameters are pre-calculated (quantized to the same 16 / 32-bit fixed-point numbers as the input parameters) according to fixed-point data quantization intervals (i.e., decimal precision), generating a mapping table between the binary values ​​of the input parameters and the binary values ​​of the output parameters. This pre-calculated mapping table is then burned into the FPGA board's Block RAM (i.e., large-capacity LUT) or the built-in LUT (i.e., small-capacity LUT) in the CLB (Configurable Logic Module). During hardware calls, the input parameters are used as address lines, and the pre-stored output parameter values ​​are output, completing the calculation within one clock cycle. When multiple modules call in parallel, the LUT is configured as a dual-port RAM, supporting simultaneous table lookups by multiple IP cores and avoiding resource conflicts.

[0048] For example, for state update operations, state updates are time-dependent; the current state depends only on the state at the previous time step and the current input. Updates must strictly follow the simulation step size order; otherwise, state chaos will occur. This application transforms CPU memory variable updates into synchronous updates of FPGA board registers to ensure the time-deterministic nature of state updates and maintain the causal relationships in cluster simulation.

[0049] Specifically, a sequential logic circuit is constructed based on the clock-enabled registers (D flip-flops) in the FPGA board to achieve synchronous state updates. In the hardware identification code, the UAV's state variables (such as position and speed) are defined as enabled registers, with the register width consistent with the fixed-point data width (e.g., 16 / 32 bits). The state update formula is transformed into a combinational logic circuit, which takes the current register state and the current step size input (such as control commands and environmental data) as inputs and outputs the next state data. Furthermore, this combinational logic circuit is only responsible for calculating the next state data and does not directly update the registers, thus avoiding state confusion.

[0050] At the clock trigger edge (such as the rising edge of the master clock), the enable signal controls the register update. When the enable signal is valid, the next state data output by the combinational logic circuit is written into the register, completing the state update. The enable signal is synchronized with the global simulation step size of the FPGA board (i.e., all IP cores share one enable signal and master clock). Within each simulation step size, a high-level enable signal for one clock cycle is generated only at the end of the step size to trigger the synchronous update of the state registers of all UAVs (IP cores), ensuring that all UAVs complete the state update at the same time and only perform the state update once, thereby maintaining the causal relationship of neighboring machine state dependencies in the cluster simulation.

[0051] In this embodiment, hardware identification code refers to code that can be identified and processed by the FPGA board. Hardware description terms, high-level synthesis tools, etc. can be used to ensure that the hardware identification code can cover all the key functions and behaviors of the cluster simulation model.

[0052] Furthermore, if the logic of the cluster simulation model is directly written using a hardware description language, then clearly defined input interfaces (such as control commands and environmental parameter inputs), output interfaces (such as UAV attitude and position outputs), and internal calculation modules (such as PID controllers and coordinate transformation modules) are required. Hardware recognition code can also be generated by calling calculation modules from the logic algorithm module library, eliminating the need to repeatedly write basic algorithms and improving the reusability of the hardware logic.

[0053] If a high-level synthesis tool is used, the algorithm logic of the cluster simulation model (such as flight trajectory calculation function and obstacle avoidance logic) is first described in a high-level language such as C / C++. Then, the high-level language is automatically converted into hardware-synthesizable hardware recognition code by the high-level synthesis tool to reduce the hardware development threshold.

[0054] In addition, the syntax correctness of the hardware identification code can be checked here, and functional simulation and timing simulation can be performed based on the hardware identification code to verify the logical correctness and timing feasibility of the hardware identification code, thereby ensuring the stable operation of the hardware identification code on the FPGA board.

[0055] Functional simulation includes: building a simulation environment using FPGA development software and inputting test cases (such as control commands and environmental disturbance data) into the hardware identification code. It is important to note that the test cases input here should be the same as those input during fixed-point model simulation verification. The output of the hardware identification code is compared with the output of the fixed-point model (the output should be less than or equal to the deviation between the simulation result of the fixed-point model and the floating-point reference dataset) to check whether the hardware identification code can completely reproduce the functionality of the cluster simulation model (such as attitude control accuracy and obstacle avoidance response). In other words, it checks whether the simulation output of the hardware identification code matches the output of the cluster simulation model when the same control commands are input. If there are accuracy or logic issues with type conversion, rewriting the hardware identification code will solidify these problems, leading to subsequent hardware implementation failures.

[0056] Timing simulation includes: combining the FPGA board's hardware parameters (such as clock frequency, pin delay, and resource distribution) with real FPGA timing constraints (e.g., a 5ns clock cycle corresponding to a 200MHz clock frequency) in the simulation environment to verify the operation of the hardware identification code under the set timing. This involves determining whether the FPGA board has timing violations, such as critical path delays exceeding the clock cycle, leading to data transmission errors. It also involves verifying whether a single simulation iteration (step size) for a single drone model can be compressed to within 1000 FPGA clock cycles to ensure low latency. If timing violations are detected, the hardware identification code needs to be optimized by splitting long-path operations, increasing pipeline stages, etc., and then re-simulating until no timing violations are found.

[0057] If the hardware identification code has functional or timing issues, the synthesized digital circuit structure file will appear to function normally in simulation but fail in actual operation (such as distorted UAV attitude data or excessive step delay), and it will be difficult to debug at the hardware level.

[0058] In this embodiment, after converting the cluster simulation model into hardware identification code, the hardware constraints for code generation are configured according to the selected FPGA board model to ensure that the generated circuit can run stably on the corresponding FPGA board. The project path, target device model, and synthesis tool version are set in the FPGA development software. Then, the hardware constraints of the FPGA board are set, including the master clock frequency (exemplarily set to 200MHz) and clock jitter tolerance (±50ps). The input / output pins of the FPGA board are defined, and the maximum number of LUTs, registers, and Block RAMs that can be occupied is set.

[0059] Then, FPGA synthesis tools are used to synthesize the hardware identification code and generate a gate-level netlist. The compatibility of algorithms of a given type can also be checked to ensure that the algorithm logic does not conflict with the hardware characteristics. The resource usage of the digital circuit structure file on the FPGA is verified to ensure that it does not exceed the FPGA board's capacity.

[0060] Finally, the toolchain maps the computing modules to specific physical locations based on the hardware resource distribution of the FPGA board (such as Block RAM and DSP unit locations), plans signal transmission paths, converts the synthesized gate-level netlist into a digital circuit structure file, burns it into the FPGA board, and activates the FPGA board by burning the configuration file, so that the computing logic of the cluster simulation model is solidified into the hardware circuit of the FPGA board.

[0061] Step 102: Divide the digital circuit structure file into multiple independent computing modules according to their functions. In this embodiment, the module hierarchy of the digital circuit structure file is analyzed using FPGA development tools. The logical boundaries of the division are determined based on the module hierarchy and the logic algorithm module library. Based on the logical boundaries, multiple independent computing modules are extracted from the digital circuit structure file, and standardized interfaces are designed for each computing module.

[0062] Specifically, the decomposition of the digital circuit structure file must follow the modular design principles of hardware design while adapting to the real-time and parallel requirements of cluster simulation. Using FPGA development tools, the digital circuit structure file is loaded, and the module hierarchy is viewed using a logic analyzer. Based on the logic algorithm module library, the corresponding UAV simulation function for each computation module is marked, clearly defining the logical boundaries to be decomposed. Cross-functional redundant logic is identified (e.g., a submodule simultaneously includes attitude calculation and dynamics calculation), and redundant logic is removed through logic trimming to ensure that each module to be decomposed corresponds to only one core function. For example, the digital circuit structure file is decomposed into six core independent computation modules (sensor data preprocessing module, attitude calculation module, environment interaction module, dynamics calculation module, control command generation module, and data interaction and synchronization module). Standardized interfaces are designed for each computing module to standardize their input and output interfaces. All input / output data uses a "fixed-point data + fixed bit width" format to avoid interface conflicts caused by bit width mismatches. Data transmission adopts the AXI-Stream protocol (a commonly used high-speed data stream protocol in FPGAs). Interface signal formats are defined, and control signals for all computing modules are unified. The hardware state machine can manage all computing modules through these unified control signals. Each computing module forms a unidirectional data stream through the standardized interface, with no cross-dependencies. Each computing module only receives output signals from the preceding module and does not directly access the internal registers of the preceding module. Computing modules handshake through data readiness and enable signals to avoid data transmission conflicts.

[0063] In FPGA development tools, functional extraction is performed by separating the marked functional logic from the digital circuit structure file, generating six independent module netlist files. Each independent module netlist file undergoes logic optimization, removing redundant logic within the computation module that is unrelated to its function, and verifying the clock cycle of the computation module. Then, the six module netlist files are connected according to data flow relationships through their respective standardized interfaces, forming a top-level netlist containing only interface signals between computation modules, without internal logic intersections.

[0064] Furthermore, the resource analysis function of the FPGA development tool is used to statistically analyze the resource usage (LUT, registers, Block RAM, DSP48) of each module netlist file in the top-level internet table, generating a resource usage report. If the resource usage of a module netlist file is too high (e.g., the LUT of the dynamics calculation module's netlist file occupies 40K, far exceeding the balanced range of 20K-30K), it is further split. If the resource usage of a module netlist file is too low (e.g., the LUT of the data interaction module's netlist file occupies only 8K), functions can be merged, such as merging the data interaction module with the synchronization signal processing logic, to avoid resource waste, but it must be ensured that the merged result still conforms to the principle of functional cohesion. Secondary splitting or function merging ensures resource balance among the various module netlist files.

[0065] Furthermore, the functionality of each module's netlist file in the top-level internet table can be simulated and verified to ensure normal operation and independence from other module netlist files. The standardized interfaces of each module's netlist file can also be verified to ensure proper interaction. Timing verification can also be performed to ensure that the total time for parallel operation of all module netlist files meets the simulation requirements, i.e., a total time ≤ 1000 clock cycles.

[0066] By splitting the digital circuit structure file into multiple independent computing modules according to function, the reusability of each computing module can be improved, the workload of subsequent development can be reduced, and each computing module can run in parallel on the FPGA board, reducing simulation time and facilitating fault location.

[0067] Step 103: Inside the FPGA board, the computing modules are encapsulated into multiple IP cores based on the needs of different individuals in the cluster. In this embodiment, the IP core instantiation step is executed iteratively until the resource specifications of the FPGA board are met. The IP core instantiation step includes: determining multiple computing modules according to the needs of individuals in the cluster; and connecting the standardized interfaces of each computing module according to the data flow relationship between them to form IP cores.

[0068] Specifically, based on the resource specifications of a single FPGA board, multiple IP cores are instantiated within the FPGA board. For example, taking the Kintex-7 XC7K325T FPGA board as an example, its LUT is 532K. If a single IP core occupies 30K LUT, then 15 IP cores can be instantiated (with 30% resource redundancy reserved), which means it can support the parallel simulation of 15 drones.

[0069] Furthermore, using FPGA development tools, the computing modules required by each individual drone in the cluster are connected through their respective standardized interfaces to form IP cores. Then, the input interfaces of the IP cores are defined, such as control commands (e.g., throttle, control surface commands), environmental data (e.g., wind speed, air pressure), and neighboring drone status (e.g., position, speed); the output interfaces are defined, such as drone status (e.g., attitude, position, speed), and simulation result flags (e.g., calculation completion signal); and configuration parameters are defined, such as the IP core number (used to distinguish different drone models) and the simulation step size (e.g., 5μs). Finally, independent hardware resources (e.g., LUTs, registers, local block RAM) are allocated to each IP core to avoid conflicts caused by multiple IP cores sharing resources (e.g., data read / write contention).

[0070] Step 104: In response to the input data received in the DDR of the FPGA board, the hardware state machine triggers all IP cores to execute the corresponding tasks in parallel, and controls the computing process of each IP core based on the FPGA board's master clock. In this embodiment, the clock of each IP core is synchronized based on the FPGA board's master clock. The input data is split according to the number of IP cores and requirements in the FPGA board, and a storage address is marked for each split input data. The DDR of the FPGA board receives the split input data and stores it in the corresponding storage address. The hardware state machine deployed inside the FPGA board triggers the synchronous start of all IP cores. Each IP core reads the input data from the corresponding storage address and feeds back to the hardware state machine. The hardware state machine controls all IP cores to execute computing tasks in parallel according to a preset scheduling strategy. When the maximum clock cycle is reached, the hardware state machine controls all IP cores to terminate the current computing task.

[0071] In this embodiment, the FPGA board's main clock is used as the sole time reference to synchronize the clocks of all IP cores, thereby controlling their task execution rhythm and ensuring that the start and end times of each time step calculation are strictly controllable, thus eliminating the random delays and jitter of traditional software scheduling.

[0072] Specifically, the FPGA board's main clock is evenly distributed to all IP cores through an internal clock tree to ensure clock signal synchronization among all IP cores, thus avoiding time asynchrony caused by clock delays. A timing controller (i.e., a hardware state machine) is designed inside the FPGA board to define the step start time, module execution timing, and step end time. The start point of each simulation step is triggered by the rising edge of the main clock. Each parallel module completes its calculation within a fixed clock cycle after startup (e.g., the fixed clock cycle for the attitude calculation module is 200 clock cycles, and the fixed clock cycle for the path planning module is 300 clock cycles). After all parallel modules have completed their calculations, the hardware state machine marks the end of the step on the (n+1000)th clock rising edge, ensuring that the entire step time is strictly 1000 clock cycles (i.e., 5μs). The execution progress of each parallel module can also be monitored through hardware logic. If a parallel module fails to complete its calculation beyond the fixed clock cycle (e.g., due to interference causing computational anomalies), a reset signal is triggered, and the calculation for that step is re-executed to ensure the determinism of the step time.

[0073] Furthermore, within a single FPGA board, a hardware state machine dynamically allocates tasks and resources to ensure that all UAV models (i.e., IP cores) within the FPGA board complete calculations within a fixed time step, while maintaining the causal and timing relationships between calculation modules. The hardware state machine maintains a FIFO (First-In-First-Out) task queue within the FPGA board. Each task includes a UAV model ID, input data address (location in DDR memory), calculation priority, and result output address. Tasks are sent from the host layer to the FPGA board via the PCIe bus. The FPGA board writes the tasks into the queue, and the hardware state machine extracts tasks and allocates them to IP cores according to a preset scheduling strategy.

[0074] The preset scheduling strategies include high-priority preemptive and time-slice round-robin. High-priority preemptive is for urgent tasks (such as a drone about to collide with an obstacle). The hardware state machine suspends low-priority tasks (such as routine path planning) and allocates FPGA resources to the high-priority task. The low-priority task resumes after completion (preemption latency < 10 clock cycles). Time-slice round-robin is for ordinary tasks. The hardware state machine divides a 5μs time step into multiple time slices; for example, 15 IP cores each occupy a 1 / 15 step time slice. Each IP core performs calculations within its corresponding time slice, avoiding resource monopolization.

[0075] Furthermore, if there is a dependency between the results of two tasks, the hardware state machine ensures that the dependent task is executed first, and then the dependent task is started after the dependent task is completed, through task dependency marking. This application implements the decision-making through a hardware state machine (without software intervention), and its decision latency is less than 5 clock cycles, which can ensure that task allocation does not occupy additional time steps.

[0076] In this embodiment, when the cluster size exceeds the capacity of a single FPGA board, multiple FPGA boards are connected via a high-speed bus to form a star topology. These FPGA boards are installed in the same industrial computer and run on the same real-time operating system. One FPGA board is designated as the master card, and its main clock is used as a reference to calibrate the clocks of the remaining FPGA boards. The master card manages computing resources and allocates computing tasks to all FPGA boards.

[0077] Specifically, this application also allows for the parallel connection of multiple FPGA boards via a high-speed bus interface (PCIe bus) when the cluster size exceeds the capacity of a single FPGA board. Utilizing the advantage of multiple PCIe slots in the industrial control computer, multiple FPGA boards can be inserted, all installed within the same industrial control computer and running on the same real-time operating system. A PCIe switch (such as the Broadcom BCM957414) interconnects the PCIe interfaces of all FPGA boards, forming a star topology, ensuring direct communication between any two FPGA boards.

[0078] Using the master clock of one FPGA board as a reference (denoted as the master card), the clocks of other FPGA boards (denoted as slave cards) are calibrated via PCIe clock signals, achieving a synchronization accuracy of ±10ns, ensuring strict consistency in time step sequence across all FPGA boards (5μs). Then, large-scale cluster simulation tasks (such as 100 drones) are broken down into multiple sub-tasks and assigned to different FPGA boards. The assignment is based on the resource utilization of each FPGA board and the dependencies between tasks.

[0079] Data access between multiple FPGA boards adopts a shared memory plus direct memory access (DMA) approach. Data across FPGA boards does not need to be relayed through the host CPU and is directly transferred between DDR memory via PCIe switch. That is, the DMA (direct memory access) controllers of different FPGA boards can directly read data in the DDR memory of other FPGA boards. The data interaction latency is <1μs, which is far lower than the network latency of traditional multi-machine distributed systems (usually >100μs).

[0080] Furthermore, all IP cores within the FPGA boards are integrated to form a unified computing resource pool. The main card manages all IPs and monitors the idle rate of each IP core in real time. The Block RAM within the FPGA boards (e.g., 200 Block RAMs per FPGA board, each with a capacity of 36Kbit) serves as an active data cache, storing the UAV's status data being calculated at the current time step to reduce latency access (<1ns). The DDR (Double Data Rate Synchronous Dynamic Random Access Memory) memory (8GB capacity per block) of all FPGA boards is interconnected via a PCIe switch to form a shared storage pool, storing inactive data (such as historical simulation results) and cross-board interaction data (such as neighboring machine status). Tasks are dynamically allocated to FPGA boards with idle resources based on the resource utilization of each FPGA board. Local storage resources are allocated to tasks based on the resource pool status within the FPGA board; resources are released after task completion for reuse by other tasks. IP cores, Block RAM, and DDR memory within the same FPGA board communicate via an AXI4-Stream interface (bandwidth up to 10GB / s, latency <10ns) to ensure fast data read and write. Different FPGA boards can directly access the DDR memory pool through a PCIe switch, avoiding latency caused by host relay.

[0081] In this embodiment, after completing the hardware deployment and scheduling strategy, the input data required by all UAV models (IP cores) within the current simulation step is efficiently distributed to the designated storage area of ​​each FPGA board, preparing for subsequent parallel computing. The input data is split according to the number of FPGA boards, the number of IP cores within each FPGA board, and the requirements of the IP cores (based on their functions), and the corresponding IP core and storage address are marked. After receiving the input data, the DDR memory controller of the FPGA board writes it to the designated address segment and sends a data-ready signal to the hardware state machine of the FPGA board. Each FPGA board performs CRC (Cyclic Redundancy Check) on the received input data. If a data error is found (such as packet loss), a retransmission is requested from the master card via the PCIe bus to ensure that the input data of each IP core is error-free.

[0082] Once the input data is ready, the FPGA board's hardware state machine triggers all IP cores to synchronously start computation tasks, ensuring that each IP core executes in parallel and maximizing the utilization of the FPGA board's hardware resources. Each IP core executes its corresponding computation task in a hardware pipeline manner, completing the calculation within a fixed clock cycle to ensure that the time step meets the target.

[0083] In the embodiments of this application, such as Figure 2As shown, the core scheduling framework of this application consists of three layers: the host layer, the FPGA acceleration layer, and the FPGA logic layer. The FPGA boards and real-time simulation management software constitute the host layer, used to achieve global management of all FPGA boards through a combination of software and hardware. The DDR of the FPGA boards constitutes the FPGA acceleration layer, used to quickly send input data from the host layer to the FPGA logic layer and efficiently send processing results from the FPGA logic layer back to the host layer, avoiding data transmission becoming a bottleneck for simulation step size. The hardware state machine, shared resource pool, and IP cores within the FPGA boards constitute the FPGA logic layer, used to implement parallel computing, scheduling, and resource management based on the internal hardware logic of the FPGA boards, achieving low-latency, high-deterministic computation of the UAV model.

[0084] Step 105: Each IP core writes the task processing results into the DDR of the FPGA board, and obtains the simulation results of the cluster simulation model by reading the DDR. In this embodiment, after all IP cores in the FPGA board complete the calculation task, they write the processing results into a designated storage area (DDR) in the FPGA board, realizing in-card result caching and cross-card result sharing, which can support subsequent data reading and simulation of the next time step.

[0085] Specifically, when all IP cores have completed their pipelined calculations (i.e., the third-stage pipeline outputs a completion signal), the hardware state machine sends a result-writing signal, triggering all IP cores to synchronously write the processing results. Core processing results (such as UAV attitude and speed) are written to the active data buffer of the Block RAM inside the FPGA board for rapid reading in the next time step simulation. Furthermore, each processing result data block includes the UAV model ID, time step number, and timestamp (based on the master clock of the main FPGA board) to facilitate data identification by other FPGA boards.

[0086] Finally, by summarizing the processing results of all IP cores in the specified memory area (DDR) within the FPGA board, the simulation results of the cluster simulation model can be obtained.

[0087] While this application provides the method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in this embodiment is merely one possible execution order among many and does not represent the only execution order. In actual device or client product execution, the methods shown in this embodiment or the accompanying drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0088] like Figure 3As shown in the figure, this application embodiment also provides an FPGA-based cluster model acceleration device 300. The device includes: a hardware module 301, a splitting module 302, an encapsulation module 303, a task module 304, and a result module 305, as detailed below.

[0089] The hardware module 301 is used to convert the cluster simulation model into a digital circuit structure file and burn it into the FPGA board.

[0090] The splitting module 302 is used to split the digital circuit structure file into multiple independent calculation modules according to their functions.

[0091] The packaging module 303 is used to encapsulate the computing module into multiple IP cores within the FPGA board based on the needs of different individuals in the cluster.

[0092] Task module 304 is used to respond to input data received in the DDR of the FPGA board. The hardware state machine triggers all IP cores to execute the corresponding tasks in parallel and controls the calculation process of each IP core based on the main clock of the FPGA board.

[0093] The results module 305 is used by each IP core to write the task processing results into the DDR of the FPGA board, and obtain the simulation results of the cluster simulation model by reading the DDR.

[0094] Some modules in the apparatus described in this application can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0095] The apparatus or module described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. For ease of description, the above apparatus is described by dividing it into various modules according to their functions. When implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware. Of course, a module that implements a certain function can also be implemented by combining multiple sub-modules or sub-units.

[0096] The methods, apparatus, or modules described in this application can be implemented in a computer-readable program code manner. The controller can be implemented in any suitable manner, such as a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of a memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code manner, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included within it for implementing various functions can also be considered as structures within the hardware component. Alternatively, the device used to implement various functions can be viewed as either a software module that implements the method or a structure within a hardware component.

[0097] This application also provides an apparatus, the apparatus comprising: a processor; a memory for storing processor-executable instructions; wherein, when the processor executes the executable instructions, it implements the method described in this application.

[0098] This application also provides a non-volatile computer-readable storage medium storing a computer program or instructions thereon, which, when executed, enables the method described in this application embodiment to be implemented.

[0099] Furthermore, in the various embodiments of the present invention, each functional module can be integrated into a processing module, or each module can exist independently, or two or more modules can be integrated into a single module.

[0100] The aforementioned storage media include, but are not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Cache, Hard Disk Drive (HDD), or Memory Card. The memory can be used to store computer program instructions.

[0101] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, or it can be embodied in the process of data migration. The computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0102] The various embodiments described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. All or part of this application can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, mobile communication terminals, multiprocessor systems, microprocessor-based systems, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

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

Claims

1. An FPGA-based cluster model acceleration method, characterized in that, The method comprises the following steps: Converting the cluster simulation model into a digital circuit structure file and burning the digital circuit structure file into an FPGA board; wherein, the conversion of the cluster simulation model into the digital circuit structure file comprises: converting the algorithm logic in the cluster simulation model into hardware logic; converting the cluster simulation model into a hardware identification code recognized by the FPGA board; using a tool chain to synthesize and layout the hardware identification code, and generating a digital circuit structure file; Splitting the digital circuit structure file into multiple independent computing modules according to functions; Encapsulating the computing modules into multiple IP cores based on the requirements of different individuals in the cluster within the FPGA board; In response to the input data received in the DDR of the FPGA board, the hardware state machine triggers all IP cores to perform corresponding tasks in parallel, and controls the computing process of each IP core based on the main clock of the FPGA board; Each IP core writes the task processing result into the DDR of the FPGA board, and obtains the simulation result of the cluster simulation model by reading the DDR.

2. The method of claim 1, wherein, Before the conversion of the cluster simulation model into the digital circuit structure file, the method further comprises the following steps: Converting the continuous calculation in the cluster simulation model into discrete calculation; and / or, Building a logic algorithm module library to avoid disconnection between algorithms and hardware logic; and / or, Converting the data type in the cluster simulation model into a set type, and adjusting the data operation type to the set type.

3. The method of claim 1, wherein, The splitting of the digital circuit structure file into multiple independent computing modules according to functions comprises the following steps: Analyzing the module level of the digital circuit structure file by using an FPGA development tool; Determining the logical boundary of splitting according to the module level and the logic algorithm module library; Based on the logical boundary, stripping multiple independent computing modules from the digital circuit structure file, and designing standardized interfaces for each computing module.

4. The method of claim 1, wherein, The encapsulation of the computing modules into multiple IP cores based on the requirements of different individuals in the cluster comprises the following steps: Iteratively performing the IP core instantiation step until the resource specification of the FPGA board is reached; The IP core instantiation step comprises the following steps: Determining multiple computing modules according to the requirements of individuals in the cluster; Connecting the standardized interfaces of each computing module according to the data flow relationship among the computing modules, and forming an IP core.

5. The method of claim 1, wherein, The response of the hardware state machine to the input data received in the DDR of the FPGA board, the triggering of all IP cores to perform corresponding tasks in parallel, and the control of the computing process of each IP core based on the main clock of the FPGA board comprises the following steps: Synchronizing the clock of each IP core based on the main clock of the FPGA board; Splitting the input data according to the number and requirements of IP cores in the FPGA board, and marking the storage address for each split input data; The DDR of the FPGA board receives the split input data and stores it in the corresponding storage address; Triggering all IP cores to start synchronously by the hardware state machine deployed in the FPGA board; Each IP core feeds back to the hardware state machine after reading the input data from the corresponding storage address; The hardware state machine controls all IP cores to perform computing tasks in parallel according to a preset scheduling strategy. When the maximum clock cycle is reached, the hardware state machine controls all IP cores to terminate the current computing task.

6. The method of claim 1, wherein, Also included are: When the cluster size exceeds the capacity of a single FPGA board, multiple FPGA boards are connected by high-speed buses to form a star topology, and the multiple FPGA boards are installed in the same industrial computer and run on the same real-time operating system. One of the FPGA boards is used as the master card, and the master clock of the master card is used as the reference to calibrate the clocks of the other FPGA boards. The master card manages the computing resources and allocates computing tasks to all FPGA boards.

7. A FPGA-based cluster model acceleration device for implementing the method of any one of claims 1-6, characterized in that, It includes: A hardware module is used to convert the cluster simulation model into a digital circuit structure file and burn it into the FPGA board. The conversion of the cluster simulation model into a digital circuit structure file includes: converting the algorithm logic in the cluster simulation model into hardware logic; converting the cluster simulation model into hardware identification code recognized by the FPGA board; using a tool chain to synthesize and layout the hardware identification code to generate a digital circuit structure file; A splitting module is used to split the digital circuit structure file into multiple independent computing modules according to function; An encapsulation module is used to encapsulate the computing modules into multiple IP cores based on the needs of different individuals in the cluster within the FPGA board; A task module is used to respond to the input data received in the DDR of the FPGA board, and the hardware state machine triggers all IP cores to execute corresponding tasks in parallel, and controls the computing process of each IP core based on the master clock of the FPGA board; A result module is used to write the task processing results of each IP core into the DDR of the FPGA board, and obtain the simulation results of the cluster simulation model by reading the DDR.

8. An apparatus for performing a FPGA-based cluster model acceleration method, comprising: It includes: A processor; A memory for storing processor executable instructions; The processor executes the executable instructions to implement the method of any one of claims 1 to 6.

9. A non-transitory computer readable storage medium, comprising: It includes a computer program or instructions for storing a computer program or instructions, which when executed, cause the method of any one of claims 1 to 6 to be implemented.

Images