Semi-physical simulation method and system based on FPGA neural network control method

Abstract

The invention discloses a semi-physical simulation method and system based on an FPGA neural network control method, and the method comprises the steps: operating an aircraft dynamics model at a simulation end, and transmitting state variables, such as an attitude angle, a speed and an angular rate, to an FPGA end in real time through Socket communication; a fixed-point neural network controller is deployed at the FPGA end, a control instruction is reasoned in a parallel pipeline mode and is transmitted back to the simulation end through a TCP / IP protocol, the system adopts a PS-PL cooperative bus to realize zero-copy data transmission, hardware-level reasoning acceleration is realized in combination with a Viis HLS and PYNQ framework, and the communication delay is less than 400 s. Through closed-loop verification, the error between the FPGA reasoning result and the floating point simulation is smaller than 4.5 * 10 <-5 >, and microsecond-level real-time response and high consistency of the flight control algorithm are achieved.

Description

Technical Field

[0001] This invention relates to the fields of flight control and heterogeneous computing acceleration technology, specifically to a hardware-in-the-loop simulation method and system based on FPGA neural network control. Background Technology

[0002] Traditional aircraft control algorithm verification heavily relies on pure software simulation or physical test benches. The former suffers from insufficient timing accuracy due to CPU serial computation, while the latter is costly, time-consuming, and difficult to infuse faults. In recent years, data-driven algorithms such as zero-order model predictive control (ZO-MPC) have shown strong robustness in attitude adjustment and trajectory tracking, but their online inference computation is enormous, and general-purpose processors struggle to meet real-time requirements.

[0003] While existing GPU- or CPU-based hardware-in-the-loop (HIL) platforms can accelerate neural network inference, they are limited by power consumption, size, and deterministic latency, making them difficult to directly embed into small UAVs or missile-borne computers. FPGAs, with their reconfigurable parallel architecture, nanosecond-level latency, and μW-MW-level power flexibility, have become an ideal platform for accelerating airborne neural networks; however, the lack of a unified, loosely coupled protocol stack in the data path between FPGAs and simulation terminals leads to fragmented deployment processes and low verification efficiency.

[0004] In view of this, the present invention proposes a hardware-in-the-loop simulation method and system based on FPGA neural network control. Summary of the Invention

[0005] The purpose of this invention is to provide a hardware-in-the-loop simulation method and system based on FPGA neural network control, which aims to solve the problems of computational bottlenecks, high communication coupling and long deployment cycles in the simulation verification of existing flight control algorithms, and realize real-time hardware acceleration and closed-loop verification of zero-order model predictive control (ZO-MPC) neural networks.

[0006] In a first aspect, the present invention provides a hardware-in-the-loop simulation method based on FPGA neural network control, comprising the following steps:

[0007] S101 deploys a Socket client on the simulation end and a Socket server on the FPGA end to transmit the timing state variables corresponding to the aircraft to the FPGA end via TCP / IP protocol at a fixed frequency.

[0008] S102, The timing state variable is received at the FPGA and input to the lightweight neural network controller. The neural network controller runs in parallel pipeline mode in the FPGA programmable logic in fixed-point format to obtain the corresponding control instructions.

[0009] S103 enables data transmission through the cooperative bus between the processing system and the programmable logic. On the processing system side, it loads the hardware configuration file and calls the controller module to achieve real-time input of simulation terminal status data and synchronous output of control commands.

[0010] The simulation end receives and parses the control commands returned by the FPGA, and feeds the control commands back to the aircraft dynamics model to form a closed-loop hardware-in-the-loop simulation control process. The consistency of the output results of the simulation end and the FPGA end is verified to evaluate the performance difference of the neural network control algorithm between hardware inference and floating-point simulation.

[0011] As a preferred embodiment of the first aspect of the present invention, the simulation end is configured as a Socket client, the FPGA end is configured as a Socket server, and the simulation end and the FPGA end adopt a bidirectional byte stream transmission method based on the TCP / IP protocol stack.

[0012] It is used to continuously receive timing status data of the aircraft from the simulation end and control commands returned from the FPGA end. The timing status data includes attitude angle, velocity and angular rate.

[0013] As a preferred technical solution of the first aspect of the present invention, the lightweight neural network controller is a multilayer sensing network constructed based on the principle of model predictive control, including an input layer, at least two hidden layers and an output layer;

[0014] The offline-trained neural network model is synthesized into a synthesizable C++ function using the Vitis HLS tool, and then run in a fully pipelining parallel architecture in the FPGA programmable logic to generate control instructions.

[0015] As a preferred embodiment of the first aspect of the present invention, the weights, biases and activation values ​​of the neural network controller are all represented in the fixed-point format ap_fixed<32,8>, where 8 bits are integer bits and the remaining 24 bits are decimal bits.

[0016] As a preferred embodiment of the first aspect of the present invention, the FPGA internally constructs a three-level cache, in-situ ReLU, and fully pipelining inference architecture, including:

[0017] The first-level buffer, input_buffer, is used to receive 64-dimensional input vectors;

[0018] The second-level cache tmp_1 / 2 / 3 is used to store 128-dimensional hidden layer features;

[0019] The third-level buffer, output_buffer, is used to output the 153-dimensional control vector.

[0020] Each layer of multiplication and accumulation loops is implemented with full pipelined computation using #pragma HLS PIPELINE II=1.

[0021] As a preferred technical solution of the first aspect of the present invention, a hardware platform including clock, AXI bus and peripheral constraints is constructed using Vivado and an XSA hardware description file is generated.

[0022] Within the PYNQ framework, the bitstream file is loaded by the ARM processing system to drive the FPGA programmable logic to perform inference.

[0023] The processing system and the programmable logic terminal achieve zero-copy data transmission through a hybrid bus of AXI-Lite register interface and AXI-Stream data interface.

[0024] As a preferred technical solution of the first aspect of the present invention, pynq.allocate() is called in Linux user space to request contiguous physical memory, so that the NumPy array and the FPGA programmable logic share the same DDR storage space, thereby realizing high-speed data transmission of state and control variables and reducing CPU usage.

[0025] As a preferred technical solution of the first aspect of the present invention, the block design, clock constraints, address mapping and IP configuration of the Vivado project are encapsulated into a .tcl script and distributed together with the mlp.bit, mlp.hwh and mlp.tcl files. Users can reproduce the same hardware platform in any host environment by executing the make overlay command.

[0026] As a preferred embodiment of the first aspect of the present invention, the method further includes a step of verifying the consistency between the FPGA inference results and the floating-point model output.

[0027] The input features are quantified by a Python script and a C++ verification program is called to compare them in a loop. The maximum absolute error and mean square error between the FPGA output and the PyTorch floating-point truth value meet the preset requirements, and the verification results meet the accuracy requirements for industrial-grade deployment.

[0028] Secondly, the present invention provides a hardware-in-the-loop simulation system based on an FPGA neural network control method, comprising:

[0029] The simulation terminal is used to run the aircraft dynamics model and send timing state data.

[0030] The FPGA side is used to receive the status data and execute the first aspect;

[0031] A socket client is deployed on both the simulation and FPGA sides. The timing status data of the aircraft is transmitted to the FPGA side via the socket method, and the result of the FPGA recursion is transmitted to the simulation side via the socket.

[0032] The timing state data is received at the FPGA and a zero-order model predictive control neural network is deployed to derive control quantities. The FPGA IP is used to accelerate the recursion and derive control quantities.

[0033] The communication link is used for data exchange between the simulation end and the FPGA end via the standard Ethernet TCP / IP protocol.

[0034] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0035] This invention models the model weight switching process of the interactive multi-model filtering algorithm as a Markov decision process and introduces a reinforcement learning mechanism to dynamically optimize and adjust the weights of each model. This enables the filtering system to adaptively allocate model weights based on the real-time observation residuals and the degree of model matching, thereby overcoming the model switching lag and error accumulation problems caused by the fixed transition probability matrix in traditional interactive multi-model algorithms. This achieves rapid and stable switching between multiple models and high-precision state estimation. Therefore, this invention significantly reduces instantaneous tracking errors during the sudden maneuvering phase of highly maneuverable targets, improves the real-time performance, stability, and environmental adaptability of the filtering system, and ensures continuous and reliable target tracking performance even under complex interference conditions. Attached Figure Description

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

[0037] Figure 1 This is a schematic diagram of the FPGA implementation in this application;

[0038] Figure 2 This is a wiring diagram provided for an embodiment of this application; Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be described in more detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0040] Throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions. The described embodiments are only a part of the embodiments of this application, not all of them. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0041] Example 1

[0042] like Figure 1 As shown, this embodiment provides a hardware-in-the-loop simulation system based on an FPGA neural network control method, including:

[0043] Simulation end: Runs the aircraft dynamics model and sends timing status data such as attitude angle, velocity, and angular rate to the FPGA end in real time through the Socket client;

[0044] FPGA side (hardware acceleration side): Deploy lightweight neural network control algorithm IP cores, infer control quantities in real time and transmit them back via Socket; such as Figure 2 As shown, the FPGA hardware platform constructed in this embodiment uses the Zynq-7000 SoC as the core processing architecture. The processing system (PS) and programmable logic (PL) are separated into instruction control and data channels through a hybrid interconnect structure composed of AXI-Lite and AXI-HP ports, including:

[0045] The M_AXI_GP0 on the PS side is connected to the control register interface on the PL side, and is used for parameter configuration and startup control of the neural network IP.

[0046] S_AXI_HP0 serves as a high-speed data access path connected to the DDR controller, enabling zero-copy migration of simulation state data and FPGA inference results;

[0047] The Processor System Reset module distributes reset signals to each AXI bus and custom IP to ensure timing consistency in the inference process.

[0048] AXI Interconnect is used to perform arbitration and address mapping between multi-source data streams, ensuring stable transmission of simulation input vectors, network internal buffers, and output vectors between modules.

[0049] Communication link: A socket connection based on the standard Ethernet TCP / IP protocol enables low-latency data exchange of aircraft status and control quantities.

[0050] A socket client is deployed on both the simulation and FPGA ends. Timing state data of the aircraft is transmitted to the FPGA via sockets, and the results of FPGA recursion are also transmitted back to the simulation end via sockets. The FPGA receives the timing state data and deploys a zero-order model predictive control (ZO-MPC) neural network to derive control quantities. The FPGA's IP is used for recursive acceleration, and the control quantities are derived. By constructing a closed-loop structure integrating the algorithm, hardware, and communication equipment, hardware-level acceleration and semi-physical real-time verification of the aircraft control algorithm are achieved.

[0051] Example 2

[0052] Based on Example 1, this example also provides a hardware-in-the-loop simulation method based on FPGA neural network control, including the following steps:

[0053] S101 is designed as the core of a neural network IP, which transforms the offline trained controller neural network into a synthesizable hardware structure for FPGA.

[0054] Specifically, the neural network is the aircraft control network. After quantizing the neural network parameters, they are loaded into the quantization process to form IP synthesis, and the neural network is called at the HLD layer. Using Vivado's interface and resource requirements based on this IP core, a complete hardware platform including clock, AXI bus, and peripheral constraints is built, generating the corresponding XSA hardware description file.

[0055] The neural network parameters are quantized using ap_fixed<32,8> fixed-point quantization, i.e., 32-bit representation, where 8 bits are integer bits and 24 bits are fractional bits. The quantized network is synthesized into a reconfigurable C++ function using the Vitis HLS tool. A hardware platform is built in the Vivado environment according to interface requirements, configuring the clock, AXI bus, and peripheral constraints. An XSA hardware description file (HardwareSpecificationArchive) is generated for subsequent bitstream generation. The parameter matrix for each layer is as follows: Figure 1 As shown (e.g., weights_1 is 128×64, biases_1 is 128, etc.). Ensure the neural network control algorithm can be executed in a fully pipelining, parallel manner on the FPGA, achieving nanosecond-level inference.

[0056] To further explain, in this embodiment, the zero-order model predictive control (ZO-MPC) neural network trained offline is first subjected to fixed-point modeling and hardware synthesis, including:

[0057] Using an offline-trained floating-point network as the source, Vitis HLS is used for weight quantization, structural reconstruction, and interface abstraction to generate synthesizable C++ functions. The ap_fixed<32,8> fixed-point format is used to uniformly represent weights, biases, and activation values, with 8 bits of the 32-bit array used for integers and the remaining 24 bits for decimals, completely avoiding floating-point DSP units while sacrificing negligible precision. A "three-level cache, in-situ ReLU, and fully pipelining" architecture is constructed within the FPGA programmable logic: the first-level cache, input_buffer, receives a 64-dimensional float32 input vector with zero copy via an AXI-HP port; the second-level caches, tmp_1 / 2 / 3, respectively cache 128-dimensional hidden layer features; and the third-level cache, output_buffer, stores a 153-dimensional output vector. Each layer's multiply-accumulate loop is forced into full pipelining with #pragma HLS PIPELINE II=1, and weights are fixed in static const ROM. The overall latency is ≤4 µs, throughput is ≥250 kFPS, and resource usage is ≤5 DSPs, 3349 FFs, and 4682 FFs. LUTs with power consumption ≤100 mW provide a new computing paradigm of "microsecond-level determinism + milliwatt-level power consumption" for embedded control.

[0058] It should be noted that the controller neural network in step S101 is not limited here.

[0059] S102 utilizes Pynq for FPGA neural network IP recursion, enabling rapid loading and execution of neural network IP cores on the FPGA.

[0060] This can be understood as importing the aforementioned hardware description file into the PYNQ framework, dynamically loading the bitstream on the ARM processing system side via the Python API, and driving the IP core to complete efficient deployment and real-time inference in the FPGA programmable logic.

[0061] The XSA file generated in step S101 is imported into the PYNQ (Python on Zynq) framework; the bitstream is dynamically loaded by executing the Python API through the ARM Cortex-A9 processing system (PS end); the neural network IP core is driven to complete real-time inference in the programmable logic (PL end); zero-copy data transmission between PS and PL is achieved through the AXI bus; the inference latency is ≤4 µs and the power consumption is ≤100mW, realizing the real-time response of the aircraft control algorithm on the hardware and ensuring that the control signal output has microsecond-level determinism.

[0062] To further explain, in order to achieve efficient access and data transfer of the neural network inference IP core, this embodiment employs a PS-PL collaborative acceleration mechanism on the Zynq-7000 SoC platform, including:

[0063] In the Zynq-7000 SoC architecture, the ARM Cortex-A9 acts as the PS (Power Switch) running PYNQ-Linux, while the FPGA programmable logic serves as the PL (Power Placement) accelerator. A hybrid topology of AXI-Lite register interface and AXI-Stream data interface is constructed using Vivado Block Design. The PL-side accelerator base address is fixed at 0x43C0_0000, with an address range of 64 KiB, avoiding conflicts between PS peripherals and DDR mapping. PYNQ Overlay dynamically parses mlp.hwh metadata to automatically generate Python register mapping objects, allowing users to load the bitstream with a single Python statement. In Linux user space, pynq.allocate() is called to allocate contiguous physical memory. The NumPy array shares the same DDR segment with the PL-side AXI-HP port, achieving "zero-copy" data exchange with a communication latency of ≤400 µs and a 30% reduction in CPU usage.

[0064] It should be noted that the specific allocation of the top-level register in step S102 is not limited here.

[0065] The S103 is designed using a socket communication module to achieve real-time data interaction between the simulation end and the FPGA end.

[0066] Specifically, based on the standard TCP / IP protocol stack, the FPGA is configured as a Socket server, continuously listening to the data stream from the simulation end; the simulation end, acting as a Socket client, periodically sends aircraft state variables; each transmission sends a 64-dimensional float32 input vector and an output of a 153-dimensional control vector; data is received using a blocking mechanism and parsed with np.frombuffer zero-copy, avoiding packet fragmentation and intermediate copying; communication latency is controlled within 400 µs, achieving millisecond-level closed-loop control. Based on the TCP / IP Socket protocol stack, bidirectional data communication between the FPGA and the simulation end is achieved via a standard Ethernet physical link. This constructs a low-latency, low-power, and highly scalable hardware-in-the-loop simulation acceleration system integrating "algorithm-hardware-communication," significantly shortening the cycle from offline training to field deployment of aircraft control algorithms, and providing a mature overall solution for highly dynamic, resource-constrained embedded control tasks.

[0067] To further explain, the embodiments of this application establish a cross-platform, loosely coupled communication path between the simulation end and the FPGA end, including:

[0068] Using TCP / IP as the sole transport layer protocol, independent Socket clients and servers are deployed on the simulation and FPGA ends respectively. The server is only responsible for transporting fixed-length byte streams of 256-byte input vectors and 540-byte output vectors. The business logic is abstracted into hot-swappable Python callback functions, supporting seamless switching between FPGA, PyTorch, or random simulators. The client is optimized through SO_REUSEADDR and TCP_NODELAY to ensure sub-millisecond round-trip latency on the local area network. Blocking precise packet reception and np.frombuffer zero-copy parsing are used to avoid incomplete packets, packet merging, and intermediate copying, achieving 24-hour continuous operation without failure.

[0069] To improve the reproducibility and portability of the system, this embodiment further encapsulates the hardware deployment process, including:

[0070] The Vivado Block Design, clock constraints, address mapping, and IP configuration are all encapsulated into .tcl scripts and released together with the mlp.bit, mlp.hwh, and mlp.tcl suites. Users only need to make the overlay to reproduce the same hardware environment on any host. The Overlay class further encapsulates low-level details such as register read / write, DMA configuration, and cache refresh, allowing algorithm engineers to complete the deployment without RTL experience.

[0071] To verify the consistency of system accuracy and performance, this embodiment employs end-to-end accuracy and performance verification, including:

[0072] A Python script was used to quantize random or sampled floating-point features into 8-bit unsigned integers, generating cppvars.dat. A C++ host test script repeatedly called the high_level function. The maximum absolute error between the FPGA fixed-point result and the PyTorch floating-point truth value was <4.5 × 10⁻⁶. -5 MSE≈2.1×10⁻ 9 Relative error <2×10⁻ 5 The error is much smaller than the theoretical truncation error of 8-bit quantization (±3.9×10⁻³), and the functionality is consistent. The comprehensive report shows that the critical path WNS is greater than 0.95 ns, the Hold Slack is greater than 0.02 ns, and there is no DRC / Methodology Warning, which meets the requirements for industrial-grade deployment.

[0073] To ensure long-term stable operation and future scalability of the system, this embodiment separates the functions of the communication layer and the inference layer, including:

[0074] The FPGA-side Socket server and the simulation-side Socket client only handle data transmission and reception and type verification. Internally, they are decoupled from the external environment through a fixed-length protocol with 64-dimensional input and 153-dimensional output. Business logic is completely decentralized to replaceable callback functions, ensuring that the communication layer and the neural network inference layer evolve independently and do not interfere with each other.

[0075] In summary, this embodiment constructs a low-latency, low-power, and highly scalable hardware-in-the-loop simulation acceleration system that integrates "algorithm-hardware-communication," significantly shortening the cycle from offline training to on-site deployment of aircraft control algorithms, and providing a mature overall solution for highly dynamic and resource-constrained embedded control tasks.

[0076] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A hardware-in-the-loop simulation method based on FPGA neural network control, characterized in that, Includes the following steps: S101: Deploy a Socket client on the simulation end and a Socket server on the FPGA end to transmit the timing state variables corresponding to the aircraft to the FPGA end via TCP / IP protocol at a fixed frequency; S102: Receive the timing state variables at the FPGA end and input them to the lightweight neural network controller. The neural network controller runs in parallel pipeline mode in the FPGA programmable logic in fixed-point format to obtain the corresponding control instructions. S103 enables data transmission through the cooperative bus between the processing system and the programmable logic. On the processing system side, it loads the hardware configuration file and calls the controller module to achieve real-time input of simulation terminal status data and synchronous output of control commands. The simulation end receives and parses the control commands returned by the FPGA, and feeds the control commands back to the aircraft dynamics model to form a closed-loop hardware-in-the-loop simulation control process. The consistency of the output results of the simulation end and the FPGA end is verified to evaluate the performance difference of the neural network control algorithm between hardware inference and floating-point simulation.

2. The hardware-in-the-loop simulation method based on FPGA neural network control according to claim 1, characterized in that, The simulation end is configured as a Socket client, and the FPGA end is configured as a Socket server. The simulation end and the FPGA end use a bidirectional byte stream transmission method based on the TCP / IP protocol stack. It is used to continuously receive timing status data of the aircraft from the simulation end and control commands returned from the FPGA end. The timing status data includes attitude angle, velocity and angular rate.

3. The hardware-in-the-loop simulation method based on FPGA neural network control according to claim 2, characterized in that, The lightweight neural network controller is a multilayer sensing network built based on the principle of model predictive control, including an input layer, at least two hidden layers, and an output layer. The offline-trained neural network model is synthesized into a synthesizable C++ function using the Vitis HLS tool, and then run in a fully pipelining parallel architecture in the FPGA programmable logic to generate control instructions.

4. The hardware-in-the-loop simulation method based on FPGA neural network control according to claim 3, characterized in that, The weights, biases, and activation values ​​of the neural network controller are all represented in fixed-point format ap_fixed<32,8>, where 8 bits are integer bits and the remaining 24 bits are decimal bits.

5. The hardware-in-the-loop simulation method based on FPGA neural network control according to claim 4, characterized in that, The FPGA internally constructs a three-level cache, in-situ ReLU, and fully pipelining inference architecture, including: The first-level buffer, input_buffer, is used to receive 64-dimensional input vectors; The second-level cache tmp_1 / 2 / 3 is used to store 128-dimensional hidden layer features; The third-level buffer, output_buffer, is used to output the 153-dimensional control vector. Each layer of multiplication and accumulation loops is implemented with full pipelined computation using #pragma HLS PIPELINE II=1.

6. The hardware-in-the-loop simulation method based on FPGA neural network control according to claim 1, characterized in that, A hardware platform containing clock, AXI bus, and peripheral constraints is built using Vivado, and an XSA hardware description file is generated. Within the PYNQ framework, the bitstream file is loaded by the ARM processing system to drive the FPGA programmable logic to perform inference. The processing system and the programmable logic terminal achieve zero-copy data transmission through a hybrid bus of AXI-Lite register interface and AXI-Stream data interface.

7. The hardware-in-the-loop simulation method based on FPGA neural network control according to claim 6, characterized in that, Calling pynq.allocate() in Linux user space to allocate contiguous physical memory allows NumPy arrays and FPGA programmable logic to share the same DDR storage space, enabling high-speed data transmission of status and control variables and reducing CPU usage.

8. The hardware-in-the-loop simulation method based on FPGA neural network control according to claim 1, characterized in that, The block design, clock constraints, address mapping, and IP configuration of the Vivado project are encapsulated into .tcl scripts and distributed together with the mlp.bit, mlp.hwh, and mlp.tcl files. Users can reproduce the same hardware platform in any host environment by executing the make overlay command.

9. The hardware-in-the-loop simulation method based on FPGA neural network control according to claim 1, characterized in that, It also includes a step to verify the consistency between the FPGA inference results and the floating-point model output. The input features are quantified by a Python script and a C++ verification program is called to compare them in a loop. The maximum absolute error and mean square error between the FPGA output and the PyTorch floating-point truth value meet the preset requirements, and the verification results meet the accuracy requirements for industrial-grade deployment.

10. A hardware-in-the-loop simulation system based on FPGA neural network control method, characterized in that, include: The simulation terminal is used to run the aircraft dynamics model and send timing state data. The FPGA terminal is used to receive the status data and execute the hardware-in-the-loop simulation method based on the FPGA neural network control method as described in any one of claims 1 to 9. A socket client is deployed on both the simulation and FPGA sides. The timing status data of the aircraft is transmitted to the FPGA side via the socket method, and the result of the FPGA recursion is transmitted to the simulation side via the socket. The timing state data is received at the FPGA and a zero-order model predictive control neural network is deployed to derive control quantities. The FPGA IP is used to accelerate the recursion and derive control quantities. The communication link is used for data exchange between the simulation end and the FPGA end via the standard Ethernet TCP / IP protocol.

Images