Design method suitable for communication architecture of field programmable gate array and multi-hardware platform

Abstract

The invention discloses a communication architecture design method suitable for a field programmable gate array and a multi-hardware platform. Firstly, the FPGA is connected with other hardware platforms based on high-speed PCIe communication or an optical fiber (generally based on an SFP interface) so as to construct a hardware platform for joint simulation. Secondly, a synchronous communication framework is designed and built in the FPGA, relative time synchronization between hardware platforms is achieved, and a foundation is laid for later example verification. And finally, an example model of the interconnected alternating current system network is established based on the proposed communication framework, a simulation test result shows that the error is within 5% compared with the same topological parameter reference model, stable power transmission can be realized, and the correctness and stability of the synchronous communication framework are verified. Therefore, the communication architecture disclosed by the invention can support joint simulation of the FPGA and other hardware platforms, and has practical engineering significance.

Description

Technical Field

[0001] The present invention relates to the field of new energy real-time simulation, and in particular to a design method for a communication architecture suitable for a Field Programmable Gate Array (FPGA) and multiple hardware platforms. Background Art

[0002] In recent years, with the proposal of the "dual carbon" goal, renewable energy power generation technology, mainly wind and solar, has achieved rapid development. The commissioning of large-scale wind and photovoltaic power generation projects has gradually made the power system present the "double high" characteristics of a high proportion of new energy and a high proportion of power electronic equipment, which has profoundly changed the basic structure and dynamic behavior of the power grid. The rapid development of new power systems is inseparable from the support of analytical and computational tools. Electromagnetic transient simulation technology can accurately characterize power electronic equipment at the microsecond scale. Therefore, the importance of simulation modeling technology, especially full electromagnetic transient simulation real-time technology, has become increasingly prominent.

[0003] At present, the development of real-time simulation and hardware-in-the-loop technology based on the verification of actual physical controllers has put forward higher requirements on the operation efficiency of simulation models, the amount of simulation resources, hardware equipment, and software interfaces. As a programmable signal processing device, FPGA allows users to customize the functions of FPGA by modifying the configuration information to meet specific design requirements. FPGA has a large number of parallel computing units and logic units, which can provide sub-microsecond low latency and high flexibility and scalability, which enables it to adapt to the simulation requirements of various scenarios in new power systems. At the same time, with the continuous expansion of the simulation scale of new power systems, a single platform alone can no longer provide sufficient computing power, and multi-device parallel simulation technology is urgently needed. Therefore, it is urgent to carry out relevant research on electromagnetic transient simulation and inter-platform communication methods under parallel computing mode, so as to promote the continuous enhancement of computing power of heterogeneous simulation platforms and provide necessary support for the construction of large-scale new power system real-time simulation platforms. Summary of the invention

[0004] The purpose of the present invention is to provide a method for designing a communication architecture suitable for field programmable gate arrays and multiple hardware platforms. The method is simple, effective and easy to design. By designing and building a synchronous communication framework in FPGA, fixed-step operation and relative time synchronization between FPGA and other platforms are realized, and real-time simulation of new energy under heterogeneous platforms can be realized. The data transmission rate and accuracy are high, which meets the stability and reliability required by the electromagnetic transient simulation data transmission of new energy. The purpose of the present invention is achieved through the following technical solutions:

[0005] A method for designing a communication architecture between a field programmable gate array and multiple hardware platforms, the method comprising:

[0006] Step 1: Consider the high-speed communication method between FPGA and other platforms, and conduct a preliminary analysis of the communication method, communication protocol, and interface used between platforms;

[0007] Step 2: Determine the preliminary communication architecture between FPGA and other hardware platforms based on the high-speed communication method outlined in step 1;

[0008] Step 3: Optimize the communication architecture between the FPGA and other hardware platforms established in step 2 to better meet the needs of actual new energy simulation scenario applications;

[0009] Step 4: Verify the communication architecture between FPGA and other hardware platforms proposed in the above steps.

[0010] It can be seen from the technical solution provided by the present invention that the above method is simple, effective and easy to design. By designing and building a synchronous communication framework in FPGA, fixed-step operation and relative time synchronization between FPGA and other platforms are realized, and real-time simulation of new energy under heterogeneous platforms can be realized. The data transmission rate and accuracy are high, which meets the stability and reliability required by the electromagnetic transient simulation data transmission of new energy. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0012] Figure 1 A schematic diagram of a flow chart of a method for designing a communication architecture between a field programmable gate array and multiple hardware platforms provided by an embodiment of the present invention;

[0013] Figure 2 This is a schematic diagram of the Aurora communication protocol;

[0014] Figure 3 Implement the block diagram for the Aurora 8B / 10B core;

[0015] Figure 4 This is the Aurora 8B / 10B core Framing interface diagram;

[0016] Figure 5 The simulated communication diagram captured by the ILA window user on the FPGA side;

[0017] Figure 6 It is the communication framework between FPGA and other hardware platforms;

[0018] Figure 7 Change the framework diagram for FPGA-RTDS;

[0019] Figure 8 This is the FPGA-RTDS joint simulation synchronous communication framework diagram;

[0020] Fig. 9 It is the top level diagram of data processing and computing module and computing IP instance diagram;

[0021] Fig.10 It is the logic block diagram of the state machine control;

[0022] Fig.11 It is the timing diagram of data processing and calculation module;

[0023] Fig.12 The example model topology for the two-terminal AC system;

[0024] Fig.13 This is a comparison chart between the FPGA-RTDS two-terminal AC system joint simulation and the benchmark model. DETAILED DESCRIPTION

[0025] The following is a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments, which does not constitute a limitation of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0026] like Figure 1 The figure is a flow chart of a method for designing a communication architecture between a field programmable gate array and multiple hardware platforms provided by an embodiment of the present invention, the method comprising:

[0027] Step 1: Consider the high-speed communication method between FPGA and other platforms, and conduct a preliminary analysis of the communication method, communication protocol, and interface used between platforms;

[0028] In this step, from the communication aspect, FPGA and other platforms usually communicate using high-speed serial bus standards (peripheral component interconnect express, PCIe) or optical fiber (usually based on SFP interface). With the help of FPGA interface card and Aurora protocol (or FC-AE protocol, etc.), high-speed and low-latency communication with speeds above 5Gbps and latency below 1μs can be achieved. The following mainly describes these two main high-speed communication methods.

[0029] FPGA can communicate with other platforms through the SFP interface based on the Aurora protocol. The Aurora protocol is a scalable, lightweight link layer protocol for moving data between point-to-point serial links. The protocol provides a transparent interface for the physical layer, allowing the upper layer to call high-speed transceivers. It has the characteristics of low resource usage, low cost, high speed, ease of use, and support for full-duplex and simplex communication. The Aurora protocol is based on low-voltage differential signal transmission technology and can transmit data simultaneously on multiple physical channels. It also provides a complete communication protocol and interface standards, including data frame format, clock and reset control, etc., to achieve reliable data transmission between FPGA and other platforms. This communication protocol has the advantages of high speed, low latency and high reliability, and is widely used in communication equipment, data storage, digital signal processing, high-performance computing and image processing. The schematic diagram of the Aurora communication protocol is shown below. Figure 2 shown.

[0030] For actual user implementation, Xilinx provides Aurora-8B / 10B IP to help FPGA communicate with other platforms. Aurora-8B / 10B means encoding 8-bit data into 10 bits for transmission to balance the number of "0" and "1" in the data and achieve DC balance. This encoding method has an overhead of 20% and an efficiency of 80%. Figure 3 The following is the implementation block diagram of the Aurora8B / 10B core. The main components of the Aurora8B / 10B core are as follows:

[0031] Channel logic module: Each GTP, GTX, or GTH transceiver (hereafter referred to as transceiver) is driven by an instance of the channel logic module. This module initializes each transceiver and handles the encoding and decoding of control characters and error detection.

[0032] Global Logic Module: The global logic module performs the binding and verification phases of channel initialization. During operation, this module generates the random idle characters required by the Aurora protocol and monitors all channel logic errors.

[0033] RX User Interface: The AXI4-Stream RX user interface transfers data from the channel to the device and performs flow control functions.

[0034] TX User Interface: The AXI4-Stream TX user interface transfers data from the device to the channel and performs flow control functions. A standard clock compensation module is embedded in the core, which controls the periodic transmission of clock compensation characters.

[0035] The Aurora8B / 10B IP core provided by Xilinx supports the AXI4-Stream protocol, and provides two data transmission interfaces depending on whether the AXI4-Stream protocol is repackaged: Framing interface (frame transmission interface) and Streaming interface (stream transmission interface). The Framing interface adds control signals such as frame header and frame tail on the basis of AXI4-Stream, making the transmission more accurate, but it will reduce the transmission efficiency and use more resources. The Streaming interface is basically a simplified AXI4-Stream interface, which only contains data validity, handshake and data signals. It has high transmission efficiency, but cannot guarantee the accuracy of transmission. In the effective data transmission process of wind and solar new energy real-time simulation hardware equipment in new energy power systems, high data reliability is required. Therefore, in the actual communication between FPGA and other platforms, the Framing interface is used for data transmission. Figure 4 The figure shows the Aurora8B / 10B core Framing interface diagram, and Table 1 and Table 2 are the Aurora8B / 10B core Framing port tables.

[0036] Table 1 Aurora8B / 10B core Framing sending port table

[0037]

[0038] Table 2 Aurora8B / 10B core Framing receiving port table

[0039]

[0040] Based on the Aurora protocol described above, the communication between FPGA and other platforms can be completed. After the other platforms send data based on the Aurora protocol, the simulated communication diagram captured by the user in the ILA window on the FPGA side is as follows: Figure 5 As shown in the figure, it is assumed that the FPGA immediately transmits the received data back to the opposite platform, and the port description is consistent with Table 1 and Table 2.

[0041] To facilitate result analysis, the time when the first 16-digit number of the i-th group of data is received is defined as t rx_begin(i) , (i=1,2,3…), the time when the last 16-digit number of the i-th group of data is received is t rx_end(i) , (i=1,2,3…), the time to transmit a 16-bit number is Δt 16bit Similarly, the time when the first 16-digit number of the first set of data is sent is t tx_begin1 , the time when the last 16-digit number of the first set of data is sent is t rx_end1 The following conclusions are drawn:

[0042] (1) Based on the Aurora protocol, the time Δt for sending / receiving a certain length of data through the optical port tran It is fixed and depends on the clock set by the Aurora module. Assuming that the Aurora8B / 10B IP core of the FPGA is set in the 100M clock domain and transmits a total of 768 bits of data, the transmission time is Δt for every 16 bits of transmission time. 16bit The time required for receiving / sending is 10ns. When data is transmitted in serial mode based on the Aurora protocol, the time required for receiving / sending is Δt tran The delay time is 480ns, which adds extra delay time. In the following example, the data transmitted is 1568 bits in total, so the receiving / sending completion time is close to 1μs, which is not conducive to transmitting large amounts of data with a very high number of bits. If the data transmission time based on the Aurora protocol has affected the simulation step size, it is necessary to consider instantiating multiple optical ports for data transmission at the same time.

[0043] (2) The time interval between two consecutive data packets received by the FPGA from the opposite user is defined as the total round-trip time Δt, as shown in formula (1).

[0044] Δt=t rx_begin(i+1) -t rx_begin(i) (i=1,2,3...) (1)

[0045] Ideally, we believe that the time interval between two consecutive data packets sent from the opposite platform remains constant, but in reality, the time interval will have a certain amount of jitter. If the opposite platform takes RTDS as an example (RTDS connects to FPGA via optical fiber and transmits data based on the Aurora protocol), after testing, when RTDS runs at a step size of 50μs, the time interval jitter between two consecutive data packets received by FPGA from the opposite platform will not exceed 2 FPGA clocks (20ns), which is almost negligible. Therefore, the time interval between two consecutive data packets received by FPGA can be considered to be an accurate 50μs. The extremely small time interval jitter lays the foundation for the subsequent use of the opposite platform as a clock reference and the design of the synchronization framework.

[0046] (3) A floating point number is usually sent as 32 bits, but data transmission based on the Aurora protocol can only be 16 bits. In the subsequent framework operation, FPGA development and design, and data integration, it is necessary to check whether the data transmission is correct to avoid incorrect results due to incorrect reception / sending of data.

[0047] PCIe is a high-speed serial computer expansion bus standard used to connect computer motherboards to various hardware devices, such as graphics cards, network adapters, storage devices (such as SSDs), etc. PCIe provides high-bandwidth and low-latency connectivity through point-to-point full-duplex communication. Compared with traditional parallel buses (such as PCI), PCIe can provide higher data transfer speeds and better scalability. FPGAs are often used to handle tasks that require high-speed data transfer, such as real-time signal processing, image processing, and network packet processing. The PCIe interface provides a high-bandwidth, low-latency communication channel between the FPGA and the host system (usually a CPU or GPU system), allowing large-scale data to be quickly transferred between the FPGA and other system components. In this way, FPGAs and CPUs / GPUs can form a heterogeneous computing architecture, making full use of their respective advantages to improve overall computing performance. The scalability of PCIe also allows multiple FPGAs to be used simultaneously in multiple PCIe slots, thereby achieving higher parallel processing capabilities and throughput. In the following text, the communication between the FPGA and the CPU is achieved through the PCIe connection line.

[0048] Step 2: Based on the high-speed communication method outlined in step 1, determine the preliminary communication architecture between FPGA and other hardware platforms:

[0049] Based on the above PCIe and optical fiber high-speed communication method, the following takes the communication between FPGA and RTDS through optical port and the communication between PCIE and CPU as an example to introduce the communication architecture between FPGA and multiple hardware platforms. The logical communication framework between FPGA, RTDS and CPU is as follows: Figure 6 shown.

[0050] The CPU accesses the following interfaces through the PCIe3.0x8 channel. Among them, the three AXI4-stream interfaces of the XDMA core are connected to the three SFP interfaces respectively to communicate with the external platform through optical fiber (RTDS is taken as an example here); the CPU accesses the register through the AXI4-lite interface of the XDMA, performs address decoding in the ADDR_JUDGE module, and accesses the DO, DI, and AO registers through different address spaces. The CPU can input and output Aurora protocol messages through SFP, and the joint simulation of FPGA and two external platforms can be realized at this time. At the same time, the logical communication framework between FPGA, RTDS, and CPU supports changes. Replacing the Aurora module with the actual new energy real-time simulation operation IP core can realize CPU-FPGA joint simulation. Conversely, replacing the XDMA core part with the new energy real-time simulation operation IP core can realize FPGA-RTDS joint simulation. The DO interface outputs a 10MHz square wave under different reference voltages. The DI interface externally inputs a level signal, and the CPU receives the level value by reading the register and outputs the analog voltage value of -10V-+10V by writing the register value.

[0051] Modify the above general framework to realize the communication framework of FPGA-RTDS joint simulation as follows Figure 7 As shown in the figure, since the actual amount of valid data transmitted is large, and the Aurora protocol only supports the transmission of 16-bit data at a time, the data needs to be converted into bit width. After the input data is isolated through FIFO, it is sent to the AXI4S_PV module at 100MHz (or other required clock frequency) to be converted into parallel data of the required width, and then input to the calculation IP after the data is stable; after the calculation is completed, the parallel data of the required width is obtained and sent to the PV_AXI4S module, converted into 16-bit AXI4-stream format for output.

[0052] The conversion modules AXI4S_PV and PV_AXIS set the parallel bus width as a variable parameter, which can be changed at any time according to actual needs. By modifying the DATA_WIDTH parameter, the parallel data width sent to the calculation IP can be changed.

[0053] Modify the variable bit width code example according to actual needs:

[0054] module axi4s_pv

[0055] #(

[0056] parameter[11:0]DATA_WIDTH=12'd1535 )

[0058] module pv_axi4s

[0059] #(

[0060] parameter[11:0]DATA_WIDTH=12'd1535 )

[0062] Step 3: Optimize the communication architecture between the FPGA and other hardware platforms established in step 2 to better meet the needs of actual new energy simulation scenario applications:

[0063] The communication architecture established based on step 2 can basically complete the data transmission between FPGA and other hardware platforms. However, in the real-time simulation scenario of new energy, FPGA and other hardware platforms need to be simulated in parallel, which requires consideration of additional issues such as communication timing coordination, adaptation of FPGA and other hardware platforms' parallel simulation functions, and communication delays between platforms. Taking the above issues into consideration, it is necessary to optimize the FPGA side. After optimization, this framework can be used to realize the simulation of FPGA and other multiple hardware platforms through optical fiber / PCIE communication. This step takes FPGA-RTDS joint simulation and optical fiber communication as an example. The proposed FPGA and RTDS joint simulation synchronous communication framework for optimizing step 2 is shown in the figure below. Figure 8 As shown. The connection between FPGA and other hardware platforms can be changed at any time according to actual needs. The synchronous communication framework can be divided into three parts: Aurora transceiver module, bit width conversion and serial number storage module, data processing and calculation module. The following parts of the framework are described in detail:

[0064] (1) Aurora transceiver module

[0065] FPGA and RTDS communicate through optical fiber. After receiving the data transmitted by the opposite platform, FPGA applies the Aurora protocol, that is, the Aurora8B / 10B IP core built into Vivado for data interaction. The output data is then connected to the AXI4-StreamDATA FIFO IP core, which provides temporary storage (buffer) for the AXI4-Stream data stream and sends it to the subsequent modules for further calculation at 100MHz (or other required clock frequency), and can isolate the Aurora transceiver module from the subsequent modules in the clock domain.

[0066] (2) Bit width conversion and serial number storage module

[0067] The AXI4-Stream data input from the upper-level module is a 16-bit number. Since the computing module needs to write the input data at one time, the 16-bit number needs to be converted into a 1536-bit number through the bit width and sent to the subsequent module. At the same time, a serial number is attached to each message to improve data accuracy and facilitate user use. After the data received by the FPGA is stored with a serial number, the data processing and computing module sends an enable signal (at this time, the previous step of the data processing and computing module has been completely solved), and the serial number attached to the solved data is immediately sent back to the opposite platform to meet the framework timing requirements.

[0068] (3) Data processing and calculation module

[0069] The top-level instance of the data processing and calculation module is Calculate_module. The data processing and calculation module adopts the code writing mode as a whole. The module port table is shown in Table 3. The top-level and calculation IP instance of the data processing and calculation module are shown in Figure 3. Fig. 9 As shown in the figure, since the Calculate_module module is a file with the sv suffix, a layer of v suffix file needs to be nested in the actual operation process.

[0070] Table 3 Top-level instantiation Calculate_module module port table

[0071]

[0072] In the actual debugging process of FPGA and other platforms, in order to ensure accurate and stable operation between FPGA and other platforms, FPGA must be powered on until the optical port light is on. Only then can the Aurora channel be identified for the next step of debugging. In the data processing and calculation module, state machine control is introduced, such as Fig.10 shown.

[0073] The state machine control is divided into two states, namely, idle state and running state. The state machine logic is as follows: before the opposite platform sends the first set of data, that is, before the Cal_start_En enable signal is valid, the state machine is in the idle state, and the FPGA computing core will not start. When the opposite platform sends the first set of data, that is, when the module port detects that the Cal_start_En enable signal is valid, it delays one clock to make the Cal_SFP2rtdsValid enable signal high, and sends the historical value of the FPGA's previous large step end register to the opposite platform. After receiving the data, the opposite platform is brought into the calculation at the current step. The PV_TOP new energy real-time simulation computing core is started while sending data. The clock of the PV_TOP new energy real-time simulation computing core is fixed to trigger once every 2.5μs. When the computing core calculates 20 times (the total time is less than 50μs at this time), the state machine is switched to the idle state, and this cycle is repeated.

[0074] The timing diagram of some signals in the above process is as follows Fig.11 As shown. It is not difficult to see from the timing diagram that during the simulation process, the opposite platform first sends data to the FPGA, and the FPGA immediately transmits the data back to the opposite platform after receiving the data. The above process is defined as a data interaction. Within a large step, the opposite platform and the FPGA only interact with each other once. In order to ensure the time synchronization framework, the time axis of the FPGA and other platforms is offset, which is roughly half of the hardware communication delay. Based on the above framework, the FPGA and other platforms remain relatively still in time, and the data transmitted in the data interaction corresponds exactly to the value required by the hardware platform, ensuring the synchronization of the joint simulation of the FPGA and other hardware platforms.

[0075] Step 4: Verify the communication architecture between FPGA and other hardware platforms proposed in the above steps.

[0076] In order to verify the correctness of the proposed synchronization framework, a two-terminal AC system example model was built based on the FPGA-RTDS hybrid platform. Fig.12 As shown. Compared with the general AC system load calculation model, this model needs to ensure the time synchronization between FPGA-RTDS to ensure the long-term stability of the system. The RTDS side model mainly includes the AC system at one end, the transformer, the circuit breaker BK1, and the three-phase short-circuit fault branch at the line outlet on one side of the Bergeron type long line. The FPGA model of the new energy real-time simulation hardware device mainly includes the other side of the Bergeron type long line, the circuit breaker BK2, the transformer, and the AC system at the other end.

[0077] Table 4 Parameters of two-terminal AC system example

[0078]

[0079]

[0080] In order to verify the correctness of the above-mentioned synchronous simulation framework and joint simulation, a benchmark model with the same topological parameters was built in the commercial simulation software using its own component library, and the waveforms were compared under the same working conditions.

[0081] The design conditions are as follows: After the model enters the steady state, the three-phase short circuit fault at the line outlet of the RTDS side model is triggered. The fault triggering time is 5s and lasts for 0.1 seconds. The three-phase voltage of the RTDS side line, the three-phase voltage of the FPGA side line and the transformer outlet current on the RTDS side are measured in the model and compared with the benchmark model in the RTDS. Fig.13 As shown in the figure, the error of the benchmark model with the same topology parameters is within 5%, and stable power transmission can be achieved, which verifies the correctness and stability of the synchronous communication architecture between FPGA and other hardware platforms.

[0082] In summary, the purpose of the present invention is to provide a method for designing a communication architecture for field programmable gate arrays and multiple hardware platforms, which is simple, effective and easy to design. By designing and building a synchronous communication framework in FPGA, fixed-step operation and relative time synchronization between FPGA and other platforms are realized, and real-time simulation of new energy under heterogeneous platforms can be realized, and its data transmission rate and accuracy are high, meeting the stability and reliability required by the electromagnetic transient simulation data transmission of new energy.

[0083] The present application proposes a method for designing a communication architecture for field programmable gate arrays and multiple hardware platforms, based on high-speed PCIe communication or optical fiber (usually based on an SFP interface) to connect FPGA with other hardware platforms to build a joint simulation hardware platform. Based on the joint simulation hardware platform, a synchronous communication framework is designed and built in the FPGA by taking the clock of another hardware platform as a reference and following the sending interval, thereby realizing fixed-step operation and relative time synchronization between the systems on both sides, laying the foundation for the subsequent example verification. Based on the proposed communication framework, the dynamic characteristics differences between electrical networks and the characteristics of computing hardware are fully utilized, and an example model of an interconnected AC system network is built through a hardware synchronization framework. The simulation test results show that the error is within 5% compared with the benchmark model with the same topology parameters, and stable power transmission can be achieved, verifying the correctness and stability of the synchronous communication framework. It can be concluded that the communication architecture proposed in the present application can support joint simulation of FPGA with other hardware platforms, which has practical engineering significance.

[0084] It is worth noting that the contents not described in detail in the embodiments of the present invention belong to the prior art known to professional and technical personnel in the field.

[0085] The above is only a preferred specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by any technician familiar with the technical field within the technical scope disclosed in the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims. The information disclosed in the background technology section of this article is only intended to deepen the understanding of the overall background technology of the present invention, and should not be regarded as an admission or in any form that the information constitutes prior art known to those skilled in the art.

Claims

1. A method for designing a communication architecture between a field programmable gate array and multiple hardware platforms, the method comprising: Step 1: Consider the high-speed communication method between FPGA and other platforms, and conduct a preliminary analysis of the communication method, communication protocol, and interface used between platforms; Step 2: Determine the preliminary communication architecture between FPGA and other hardware platforms based on the high-speed communication method outlined in step 1; Step 3: Optimize the communication architecture between the FPGA and other hardware platforms established in step 2 to better meet the needs of actual new energy simulation scenario applications; Step 4: Verify the communication architecture between FPGA and other hardware platforms proposed in the above steps.

2. According to claim 1, a method for designing a communication architecture suitable for field programmable gate arrays and multiple hardware platforms, characterized in that: In step 1, from the communication aspect, FPGA and other platforms usually use high-speed serial bus standards (peripheral component interconnect express, PCIe) or optical fiber (usually based on SFP interface) for communication. With the help of FPGA interface card and Aurora protocol (or FC-AE protocol, etc.), high-speed and low-latency communication with speeds above 5Gbps and latency below 1μs can be achieved. The following mainly describes these two main high-speed communication methods. FPGA can communicate with other platforms through the SFP interface based on the Aurora protocol. The Aurora protocol is a scalable, lightweight link layer protocol for moving data between point-to-point serial links. The protocol provides a transparent interface for the physical layer, allowing the upper layer to call high-speed transceivers. It has the characteristics of low resource usage, low cost, high speed, easy to use, and support for full-duplex and simplex communication. The Aurora protocol is based on low-voltage differential signal transmission technology. It can transmit data simultaneously on multiple physical channels and provides a complete communication protocol and interface standard, including data frame format, clock and reset control, etc., to achieve reliable data transmission between FPGA and other platforms. This communication protocol has the advantages of high speed, low latency and high reliability, and is widely used in communication equipment, data storage, digital signal processing, high-performance computing and image processing. The schematic diagram of the Aurora communication protocol is shown in Figure 2. For actual user implementation, Xilinx provides Aurora-8B / 10B IP to help FPGA achieve communication with other platforms. Aurora-8B / 10B means encoding 8-bit data into 10 bits for transmission to balance the number of "0" and "1" in the data and achieve DC balance. This encoding method has an overhead of 20% and an efficiency of 80%. As shown in Figure 3, the Aurora 8B / 10B core implementation block diagram, the main components of the Aurora8B / 10B core are as follows: Channel logic module: Each GTP, GTX, or GTH transceiver (hereafter referred to as transceiver) is driven by an instance of the channel logic module. This module initializes each transceiver and handles the encoding and decoding of control characters and error detection. Global Logic Module: The global logic module performs the binding and verification phases of channel initialization. During operation, this module generates the random idle characters required by the Aurora protocol and monitors all channel logic errors. RX User Interface: The AXI4-Stream RX user interface transfers data from the channel to the device and performs flow control functions. TX User Interface: The AXI4-Stream TX user interface transfers data from the device to the channel and performs flow control functions. A standard clock compensation module is embedded in the core, which controls the periodic transmission of clock compensation characters. The Aurora8B / 10B IP core provided by Xilinx supports the AXI4-Stream protocol. Depending on whether the AXI4-Stream protocol is repackaged, two data transmission interfaces are provided: the Framing interface (frame transmission interface) and the Streaming interface (stream transmission interface). The Framing interface adds control signals such as the frame header and frame tail on the basis of AXI4-Stream, making the transmission more accurate, but it will reduce the transmission efficiency and use more resources. The Streaming interface is basically a simplified AXI4-Stream interface, which only contains data validity, handshake and data signals. It has high transmission efficiency, but cannot guarantee the accuracy of transmission. In the effective data transmission process of the wind and solar energy real-time simulation hardware equipment of the new energy power system, high reliability of the data is required. Therefore, in the actual communication between FPGA and other platforms, the Framing interface is selected for data transmission. As shown in Figure 4, the Aurora8B / 10B core Framing interface diagram is used, and Tables 1 and 2 are the Aurora8B / 10B core Framing port tables. Table 1 Aurora8B / 10B core Framing sending port table Table 2 Aurora8B / 10B core Framing receiving port table Based on the Aurora protocol described above, communication between FPGA and other platforms can be completed. After other platforms send data based on the Aurora protocol, the simulated communication diagram that can be captured by the user in the ILA window on the FPGA side is shown in Figure 5. The figure assumes that FPGA immediately transmits the data back to the opposite platform after receiving it, and the port description is consistent with Table 1 and Table 2. To facilitate result analysis, the time when the first 16-digit number of the i-th group of data is received is defined as t rx_begin(i) , (i=1,2,3…), the time when the last 16-digit number of the i-th group of data is received is t rx_end(i) , (i=1,2,3…), the time to transmit a 16-bit number is Δt 16bit Similarly, the time when the first 16-digit number of the first set of data is sent is t tx_begin1 , the time when the last 16-digit number of the first set of data is sent is t rx_end1 The following conclusions are drawn: (1) Based on the Aurora protocol, the time Δt for sending / receiving a certain length of data through the optical port tran It is fixed and depends on the clock set by the Aurora module. Assuming that the Aurora8B / 10B IP core of the FPGA is set in the 100M clock domain and transmits a total of 768 bits of data, the transmission time is Δt for every 16 bits of transmission time. 16bit The time required for receiving / sending is 10ns. When data is transmitted in serial mode based on the Aurora protocol, the time required for receiving / sending is Δt tran The delay time is 480ns, which adds extra delay time. In the following example, the data transmitted is 1568 bits in total, so the receiving / sending completion time is close to 1μs, which is not conducive to transmitting large amounts of data with a very high number of bits. If the data transmission time based on the Aurora protocol has affected the simulation step size, it is necessary to consider instantiating multiple optical ports for data transmission at the same time. (2) The time interval between two consecutive data packets received by the FPGA from the opposite user is defined as the total round-trip time Δt, as shown in formula (1). Δt=t rx_begin(i+1) -t rx_begin(i) (i=1,2,3...) (1) Ideally, we believe that the time interval between two consecutive data packets sent from the opposite platform remains constant, but in reality, the time interval will have a certain amount of jitter. If the opposite platform takes RTDS as an example (RTDS connects to FPGA via optical fiber and transmits data based on the Aurora protocol), after testing, when RTDS runs at a step size of 50μs, the time interval jitter between two consecutive data packets received by FPGA from the opposite platform will not exceed 2 FPGA clocks (20ns), which is almost negligible. Therefore, the time interval between two consecutive data packets received by FPGA can be considered to be an accurate 50μs. The extremely small time interval jitter lays the foundation for the subsequent use of the opposite platform as a clock reference and the design of the synchronization framework. (3) A floating point number is usually sent as 32 bits, but data transmission based on the Aurora protocol can only be 16 bits. In the subsequent framework operation, FPGA development and design, and data integration, it is necessary to check whether the data transmission is correct to avoid incorrect results due to incorrect reception / sending of data. PCIe is a high-speed serial computer expansion bus standard used to connect computer motherboards with various hardware devices such as graphics cards, network adapters, storage devices (such as SSDs), etc. PCIe provides high-bandwidth and low-latency connectivity through point-to-point full-duplex communication. Compared with traditional parallel buses (such as PCI), PCIe can provide higher data transmission speeds and better scalability. FPGAs are often used to handle tasks that require high-speed data transmission, such as real-time signal processing, image processing, and network packet processing. The PCIe interface provides a high-bandwidth, low-latency communication channel between the FPGA and the host system (usually a CPU or GPU system), allowing large-scale data to be quickly transmitted between the FPGA and other system components. In this way, FPGAs and CPUs / GPUs can form a heterogeneous computing architecture, making full use of their respective advantages to improve overall computing performance. The scalability of PCIe also allows multiple FPGAs to be used simultaneously in multiple PCIe slots, thereby achieving higher parallel processing capabilities and throughput. In the following text, the communication between the FPGA and the CPU is achieved through the PCIe connection line.

3. According to claim 2, a method for designing a communication architecture suitable for field programmable gate arrays and multiple hardware platforms, characterized in that: The process of step 2 is specifically as follows: Based on the above-mentioned PCIe and optical fiber high-speed communication method, the following takes the communication between FPGA and RTDS through the optical port and the communication with CPU through PCIE as an example to introduce the communication architecture between FPGA and multiple hardware platforms. The logical communication framework between FPGA and RTDS and CPU is shown in Figure 6. The CPU accesses the following interfaces through the PCIe3.0x8 channel. Among them, the three AXI4-stream interfaces of the XDMA core are connected to the three SFP interfaces respectively to communicate with the external platform through optical fiber (RTDS is taken as an example here); the CPU accesses the register through the AXI4-lite interface of the XDMA, performs address decoding in the ADDR_JUDGE module, and accesses the DO, DI, and AO registers through different address spaces. The CPU can input and output Aurora protocol messages through SFP, and the joint simulation of FPGA and two external platforms can be realized at this time. At the same time, the logical communication framework between FPGA, RTDS, and CPU supports changes. Replacing the Aurora module with the actual new energy real-time simulation operation IP core can realize CPU-FPGA joint simulation. Conversely, replacing the XDMA core part with the new energy real-time simulation operation IP core can realize FPGA-RTDS joint simulation. The DO interface outputs a 10MHz square wave under different reference voltages. The DI interface externally inputs a level signal, and the CPU receives the level value by reading the register and outputs the analog voltage value of -10V-+10V by writing the register value. The above framework is modified to realize the communication framework of FPGA-RTDS joint simulation as shown in Figure 7. Since the actual amount of valid data transmitted is large, and the Aurora protocol only supports the transmission of 16-bit data at a time, it is necessary to convert the data bit width. After the input data is isolated through FIFO, it is sent to the AXI4S_PV module at 100MHz (or other required clock frequency) to be converted into parallel data of the required width, and then input into the calculation IP after the data is stable; after the calculation is completed, the parallel data of the required width is sent to the PV_AXI4S module and converted into 16-bit AXI4-stream output. The conversion modules AXI4S_PV and PV_AXIS set the parallel bus width as a variable parameter, which can be changed at any time according to actual needs. By modifying the DATA_WIDTH parameter, the parallel data width sent to the calculation IP can be changed. Modify the variable bit width code example according to actual needs: module axi4s_pv #( parameter[11:0]DATA_WIDTH=12'd1535 ) module pv_axi4s #( parameter[11:0]DATA_WIDTH=12'd1535 ) 4. According to claim 2, a method for designing a communication architecture suitable for field programmable gate arrays and multiple hardware platforms, characterized in that: The process of step 3 is specifically as follows: The communication architecture established based on step 2 can basically complete the data transmission between FPGA and other hardware platforms. However, in the real-time simulation scenario of new energy, FPGA and other hardware platforms need to be simulated in parallel, which requires consideration of additional issues such as communication timing coordination, adaptation of FPGA and other hardware platforms to parallel simulation functions, and communication delay between platforms. Considering the above problems, it is necessary to optimize the FPGA side. After optimization, this framework can be used to realize the simulation of FPGA and other multiple hardware platforms through optical fiber / PCIE communication. This step takes FPGA-RTDS joint simulation and optical fiber communication as an example. The FPGA and RTDS joint simulation synchronous communication framework diagram proposed by optimizing step 2 is shown in Figure 8. The connection between FPGA and other hardware platforms can be changed at any time according to actual needs. The synchronous communication framework can be divided into three parts: Aurora transceiver module, bit width conversion and serial number storage module, and data processing and calculation module. The framework will explain each part in detail below: (1) Aurora transceiver module FPGA and RTDS communicate through optical fiber. After receiving the data transmitted by the opposite platform, FPGA applies Aurora protocol, that is, Aurora8B / 10B IP core built into Vivado for data exchange. The output data is then connected to AXI4-Stream DATAFIFO IP core, which provides temporary storage (buffer) for AXI4-Stream data stream and sends it to subsequent modules for further calculation at 100MHz (or other required clock frequency), and can isolate the Aurora transceiver module from the subsequent modules in clock domain. (2) Bit width conversion and serial number storage module The AXI4-Stream data input from the upper-level module is a 16-bit number. Since the computing module needs to write the input data at one time, the 16-bit number needs to be converted into a 1536-bit number through the bit width and sent to the subsequent module. At the same time, a serial number is attached to each message to improve data accuracy and facilitate user use. After the data received by the FPGA is stored with a serial number, the data processing and computing module sends an enable signal (at this time, the previous step of the data processing and computing module has been completely solved), and the serial number attached to the solved data is immediately sent back to the opposite platform to meet the framework timing requirements. (3) Data processing and calculation module The top-level instance of the data processing and calculation module is Calculate_module. The data processing and calculation module adopts the code writing mode as a whole. The module port table is shown in Table 3, and the top-level and calculation IP instance diagram of the data processing and calculation module is shown in Figure 9. Since the Calculate_module module is an sv suffix file, a layer of v suffix file needs to be nested in the actual operation process. Table 3 Top-level instantiation Calculate_module module port table In the actual debugging process between FPGA and other platforms, in order to ensure accurate and stable operation between FPGA and other platforms, FPGA must be powered on until the optical port light is on, and then the Aurora channel can be identified for the next step of debugging. In the data processing and calculation module, state machine control is introduced, as shown in Figure 10. The state machine control is divided into two states, namely, idle state and running state. The state machine logic is as follows: before the opposite platform sends the first set of data, that is, before the Cal_start_En enable signal is valid, the state machine is in the idle state, and the FPGA computing core will not start. When the opposite platform sends the first set of data, that is, when the module port detects that the Cal_start_En enable signal is valid, it delays one clock to make the Cal_SFP2rtdsValid enable signal high, and sends the historical value of the FPGA's previous large step end register to the opposite platform. After receiving the data, the opposite platform is brought into the calculation at the current step. The PV_TOP new energy real-time simulation computing core is started while sending data. The clock of the PV_TOP new energy real-time simulation computing core is fixed to trigger once every 2.5μs. When the computing core calculates 20 times (the total time is less than 50μs at this time), the state machine is switched to the idle state, and this cycle is repeated. The timing diagram of some signals in the above process is shown in Figure 11. It is not difficult to see from the timing diagram that during the simulation process, the opposite platform first sends data to the FPGA, and the FPGA immediately transmits the data back to the opposite platform after receiving the data. The above process is defined as a data interaction. The opposite platform and the FPGA only interact with each other once within a large step. In order to ensure the time synchronization framework, the time axis of the FPGA and other platforms is offset, which is roughly half of the hardware communication delay. Based on the above framework, the FPGA and other platforms remain relatively still in time, and the data transmitted in the data interaction corresponds exactly to the value required by the hardware platform, ensuring the synchronization of the joint simulation of the FPGA and other hardware platforms.

5. According to claim 2, a method for designing a communication architecture suitable for field programmable gate arrays and multiple hardware platforms, characterized in that: The process of step 4 is specifically as follows: In order to verify the correctness of the proposed synchronization framework, a two-terminal AC system example model was built based on the FPGA-RTDS hybrid platform, as shown in Figure 12. Compared with the general AC system load example model, this model needs to ensure the time synchronization between FPGA-RTDS to ensure the long-term stability of the system. The RTDS side model mainly includes an AC system at one end, a transformer, a circuit breaker BK1, and a three-phase short-circuit fault branch at the line outlet on one side of the Bergeron type long line. The FPGA model of the new energy real-time simulation hardware equipment mainly includes the other side of the Bergeron-type long line, the circuit breaker BK2, the transformer and the AC system at the other end. Table 4 Parameters of two-terminal AC system example In order to verify the correctness of the above-mentioned synchronous simulation framework and joint simulation, a benchmark model with the same topological parameters was built in the commercial simulation software using its own component library, and the waveforms were compared under the same working conditions. The design conditions are as follows: After the model enters the steady state, the three-phase short circuit fault at the line outlet of the RTDS side model is triggered. The fault triggering time is 5s and lasts for 0.1 seconds. The three-phase voltage of the line on the RTDS side, the three-phase voltage of the line on the FPGA side, and the transformer outlet current on the RTDS side are measured in the model and compared with the benchmark model in the RTDS, as shown in Figure 13. After comparison, the error of the benchmark model with the same topology parameters is within 5%, and stable power transmission can be achieved, which verifies the correctness and stability of the synchronous communication architecture between FPGA and other hardware platforms.

Images