Method for data transmission between hosts based on FPGA (Field Programmable Gate Array)

Abstract

The invention provides a method for data transmission between hosts based on an FPGA (Field Programmable Gate Array), and the method for data transmission comprises the following steps: 1, when a user needs to transmit data, calling a transmission function interface of network programming, and transmitting the data to a protocol stack; 2, the protocol stack adds a corresponding TCP packet header and an IP packet header according to needs, calls a data sending interface registered by a bottom driver, and sends data to the driver; 3, the drive program checks the queue state and judges whether data can be sent or not, and if the data can be sent, the step 4 is executed; otherwise, the BUSY state is directly returned to the protocol stack, and the protocol stack selects a proper opportunity to carry out retry; 4, obtaining idle items in the queue, filling descriptors of the idle items, and adding 1 to a producer pointer; 5, the FPGA continuously detects whether the sending queue is empty or not, and if it is detected that the queue item is non-empty, the step 6 is executed; otherwise, continuing to perform circular detection; step 6, judging whether the AURORA READY signal is valid or not, and if yes, entering step 7; step 7, obtaining a queue item of the sending queue; 8, reading the data from the CPU end, filling a packet header, a frame length and a packet tail according to needs, and sending the data to the AURORA; step 9, judging whether the data corresponding to the command is sent completely or not, if not, returning to step 6, and if the command is completed, entering step 10; step 10, sending the MSIX interrupt to a CPU (Central Processing Unit); 11, the CPU releases corresponding sending resources after receiving the interruption; 12, informing a protocol stack that the frame data packet is sent; and step 13, updating producer and consumer pointers corresponding to the sending queue.

Description

Technical Field

[0001] The present invention relates to the technical field of data communication transmission, and in particular to a method for performing data transmission between FPGA-based hosts. Background Art

[0002] Data transmission refers to the process of sending and receiving data between two or more devices through a communication channel. It is the basis for information exchange between devices and is widely used in computer networks, telecommunication systems and the interconnection between various digital devices.

[0003] In today's rapidly developing digital world, data transmission not only needs to ensure high reliability, that is, data can be accurately transmitted from one point to another, but also the demand for transmission rate continues to grow. With the advancement of technology and the diversification of application scenarios, users expect to enjoy seamless, high-quality data exchange while also experiencing faster response speeds and higher efficiency.

[0004] When general network cards are transmitting data between devices, they are often limited by the configuration of network switching, and their maximum transmission unit (MTU) can usually only support up to 9700 bytes. This limitation has a significant impact on data transmission efficiency, especially in application scenarios that need to process large amounts of data or require high-speed transmission.

[0005] Since MTU defines the maximum size of a single data packet, a lower MTU value means that data needs to be divided into more small packets for transmission. This not only increases the processing burden of the network layer, but may also cause additional delays and resource consumption because each data packet needs to go through the process of creation, sending, routing, and receiving. Especially in a high-load environment, frequent exchanges of small data packets may quickly exhaust the network bandwidth, thereby reducing the overall transmission efficiency.

[0006] Figure 1 It is the overall framework of standard network devices. Since standard network devices cannot achieve accurate data flow control based on the underlying PHY communication, and the transmission media are all based on unreliable transmission, data packet loss and errors often occur. At the same time, it is limited by the limitations of network switching and forwarding packets. Therefore, MTU usually supports a maximum of 9700.

[0007] Therefore, how to increase the bandwidth of data transmission between devices and reduce CPU occupancy is a problem that needs to be solved at present. Summary of the invention

[0008] The purpose of the present invention is to provide a method for data transmission between FPGA hosts, which can improve the bandwidth of data transmission between devices and reduce the occupancy rate of CPU.

[0009] In order to achieve the above object, the present invention provides a method for data transmission between FPGA hosts, wherein the method for data transmission comprises the following steps:

[0010] Step 1: When the user needs to send data, call the sending function interface of network programming to send the data to the protocol stack;

[0011] Step 2: The protocol stack adds the corresponding TCP header and IP header as needed, and calls the data sending interface registered by the underlying driver to send the data to the driver;

[0012] Step 3: The driver checks the queue status to determine whether data can be sent. If data can be sent, it proceeds to step 4; otherwise, it directly returns the BUSY status to the protocol stack, and the protocol stack selects an appropriate time to retry;

[0013] Step 4: Get the free item in the queue, fill its descriptor, and increase the producer pointer by 1;

[0014] Step 5: FPGA continuously checks whether the sending queue is empty. If it detects that the queue item is not empty, it goes to step 6; otherwise, it continues to loop detection;

[0015] Step 6: Determine whether the AURORA READY signal is valid. If it is valid, proceed to step 7;

[0016] Step 7: Get the queue item of the sending queue;

[0017] Step 8: Read data from the CPU, fill in the header, frame length, and tail as needed, and send the data to AURORA;

[0018] Step 9: Determine whether the data corresponding to the command has been sent. If not, return to step 6. If the command has been completed, proceed to step 10.

[0019] Step 10: Send MSIX interrupt to CPU;

[0020] Step 11: After receiving the interrupt, the CPU releases the corresponding sending resources;

[0021] Step 12: Notify the protocol stack that the frame data packet has been sent;

[0022] Step 13: Update the producer and consumer pointers corresponding to the sending queue.

[0023] In the optional solution, in step 6, the method for determining whether the AURORA REDAY signal is valid is:

[0024] When the Aurora interface receiving end detects that the cache reaches the set highest threshold, the FPGA pulls down the sending end REDAY signal through the Aurora flow control interface. At this time, the REDAY signal is invalid; when the cache is lower than the set lowest threshold, the FPGA pulls up the sending end REDAY signal through the Aurora flow control interface. At this time, the REDAY signal is valid.

[0025] The present invention provides a method for data transmission between FPGA hosts, wherein the method for data reception comprises the following steps:

[0026] Step 1: FPGA loops to check whether the receiving queue is empty; if it is empty, it continues to check; otherwise, it goes to step 2;

[0027] Step 2: Receive data frame header and packet length information;

[0028] Step 3: Determine whether FIFO can receive data. If FIFO has reached the specified water level, a READY signal is given to the sender; otherwise, go to step 4.

[0029] Step 4: Receive a packet of data;

[0030] Step 5: Determine whether the current frame of data has been received. If it has been received, proceed to step 6; otherwise, return to step 4 and continue to receive the next packet of data.

[0031] Step 6: Update the producer pointer of the receiving queue to point to the next free position in the queue to prepare for the writing of subsequent data;

[0032] Step 7: Send a receive interrupt to the CPU to notify it that the data has been received;

[0033] Step 8: After receiving the receive interrupt, the CPU determines whether the receive queue is empty; if it is empty, it exits the interrupt processing; if it is not empty, it goes to step 9;

[0034] Step 9: The CPU obtains the corresponding queue item in the receiving queue;

[0035] Step 10: The CPU obtains the length information of the received data packet and fills it into the corresponding position in the protocol stack format;

[0036] Step 11: The CPU notifies the protocol stack that a new data packet has been successfully received, and the protocol stack begins to process the data;

[0037] Step 12: After the protocol stack completes processing, the user-mode program is notified that data reception has been completed;

[0038] Step 13: Allocate a new buffer for the next data reception and fill it into the queue item of the corresponding receiving queue;

[0039] Step 14: Update the producer pointer and consumer pointer of the receiving queue.

[0040] The beneficial effects of the present invention are:

[0041] The method of the present invention can improve the bandwidth of data transmission between devices and can reduce the occupancy rate of the CPU; users can conveniently realize data transmission by using network programming; and users can conveniently use existing network transmission tools to perform data transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The above and other objects, features and advantages of the present invention will become more apparent through a more detailed description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, in which like reference numerals generally represent like components.

[0043] Figure 1 This is an overall framework diagram of a standard network device in the prior art.

[0044] Figure 2 The figure is a schematic diagram of hardware interconnection for data transmission between FPGA hosts in one embodiment of the present invention.

[0045] Figure 3 A software framework diagram for data transmission between FPGA hosts in one embodiment of the present invention.

[0046] Figure 4 The present invention is a flowchart of a method for transmitting data between FPGA hosts in one embodiment of the present invention.

[0047] Figure 5 The present invention is a flowchart of a method for receiving data between FPGA hosts in one embodiment of the present invention. DETAILED DESCRIPTION

[0048] The present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. According to the following description and drawings, the advantages and features of the present invention will become clearer. However, it should be noted that the concept of the technical solution of the present invention can be implemented in a variety of different forms and is not limited to the specific embodiments described herein. The drawings are all in a very simplified form and are not in precise proportions, and are only used to conveniently and clearly assist in explaining the purpose of the embodiments of the present invention.

[0049] It should be understood that when an element or layer is referred to as being "on, adjacent to, connected to or coupled to other elements or layers, it may be directly on, adjacent to, connected to or coupled to other elements or layers, or there may be intervening elements or layers. In contrast, when an element is referred to as being "directly on, directly adjacent to, directly connected to or directly coupled to other elements or layers, there may be no intervening elements or layers. It should be understood that, although the terms first, second, third, etc. may be used to describe various elements, components, regions, layers and / or parts, these elements, components, regions, layers and / or parts should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer or part from another element, component, region, layer or part. Therefore, without departing from the teachings of the present invention, the first element, component, region, layer or part discussed below may be represented as a second element, component, region, layer or part.

[0050] Spatially relative terms such as "under," "below," "below," "under," "above," "above," etc., may be used herein for ease of description to describe the relationship of an element or feature shown in the figures to other elements or features. It should be understood that in addition to the orientations shown in the figures, the spatially relative terms are intended to include different orientations of the device in use and operation. For example, if the device in the accompanying drawings is flipped, then the elements or features described as "under other elements" or "under" or "under" will be oriented as "on" the other elements or features. Therefore, the exemplary terms "under" and "under" may include both upper and lower orientations. The device may be oriented otherwise (rotated 90 degrees or other orientations) and the spatial descriptors used herein are interpreted accordingly.

[0051] The purpose of the terms used herein is only to describe specific embodiments and is not intended to be limiting of the present invention. When used herein, the singular forms "one", "an" and "said / the" are also intended to include plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms "consisting of" and / or "comprising", when used in this specification, determine the presence of the features, integers, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, parts and / or groups. When used herein, the term "and / or" includes any and all combinations of the relevant listed items.

[0052] In the fields of high-performance computing, electronic warfare, radar signal processing, etc., users often face the problem of large-bandwidth data transmission between hosts. The background of this paper is based on the need for large-bandwidth data transmission between hosts and different boards in the radar signal processing system, and the need for a fully domesticated design.

[0053] The present invention discloses a method for highly reliable lossless data transmission between FPGA hosts. FPGA has powerful on-chip computing capabilities due to its on-chip resource reconfigurability and flexible hardware layout characteristics, and is widely used in various fields. Data transmission between FPGA and host is a common problem faced by users. The present invention uses a method to virtualize FPGA into a network device, and the transmission medium uses AURORA protocol to replace the MAC and PHY layers of the network. Users can develop based on general SOCKET programming, which meets the universality and can realize lossless data transmission based on AURORA protocol.

[0054] Example 1

[0055] Reference Figures 2 to 4 This embodiment provides a method for data transmission between FPGA hosts, wherein the data transmission method includes the following steps:

[0056] Step 1: When the user needs to send data, call the sending function interface of network programming to send the data to the protocol stack;

[0057] Step 2: The protocol stack adds the corresponding TCP header and IP header as needed, and calls the data sending interface registered by the underlying driver to send the data to the driver;

[0058] Step 3: The driver checks the queue status to determine whether data can be sent. If data can be sent, it proceeds to step 4; otherwise, it directly returns the BUSY status to the protocol stack, and the protocol stack selects an appropriate time to retry;

[0059] Step 4: Get the free item in the queue, fill its descriptor, and increase the producer pointer by 1;

[0060] Step 5: FPGA continuously checks whether the sending queue is empty. If it detects that the queue item is not empty, it goes to step 6; otherwise, it continues to loop detection;

[0061] Step 6: Determine whether the AURORA READY signal is valid. If it is valid, proceed to step 7;

[0062] Step 7: Get the queue item of the sending queue;

[0063] Step 8: Read data from the CPU, fill in the packet header, frame length, and packet tail as needed, and send the data to AURORA;

[0064] Step 9: Determine whether the data corresponding to the command has been sent. If not, return to step 6. If the command has been completed, proceed to step 10.

[0065] Step 10: Send MSIX interrupt to CPU;

[0066] Step 11: After receiving the interrupt, the CPU releases the corresponding sending resources;

[0067] Step 12: Notify the protocol stack that the frame data packet has been sent;

[0068] Step 13: Update the producer and consumer pointers corresponding to the sending queue.

[0069] Specifically, in step 1, the user passes the data to be sent to the network protocol stack by calling the network programming interface (such as the send() function). This step submits the user data to the network protocol stack for subsequent packaging and sending.

[0070] In step 2, the protocol stack encapsulates the data, adds TCP and IP headers, and then calls the data sending interface provided by the underlying driver to pass the encapsulated data to the driver. This step adds the necessary network protocol headers to the data to make it conform to the format of network transmission, and passes the data to the driver for hardware-level transmission.

[0071] In step 3, the driver checks the status of the send queue to determine whether there are free queue items available for sending data. If there are free items in the queue, it proceeds to the next step; if there are no free items, it returns the "BUSY" status to the protocol stack, and the protocol stack will try to send again at the appropriate time. This step ensures that there is available space in the send queue to avoid data loss, and at the same time ensures that data can be sent through the retry mechanism.

[0072] In step 4, the driver obtains a free item in the transmit queue, fills in the descriptor of the queue item (such as data address, length, etc.), and moves the producer pointer of the queue forward by one position. This step prepares the queue item to store the data to be sent and updates the queue status so that the FPGA can read and send the data correctly.

[0073] In step 5, the FPGA continuously monitors the send queue to check whether there is a non-empty queue item. If the queue item is found to be non-empty, it means that there is data to be sent, and the next step is entered; if the queue item is empty, the loop detection continues. This step ensures that the FPGA can find the data to be sent in time to avoid delays in data transmission.

[0074] In step 6, FPGA checks whether the READY signal of AURORA is valid. In this step, the method for determining whether the AURORA REDAY signal is valid is as follows: when the Aurora interface receiving end detects that the cache reaches the set maximum threshold, the FPGA pulls down the REDAY signal of the sending end through the Aurora flow control interface, and the REDAY signal is invalid at this time; when the cache is lower than the set minimum threshold, the FPGA pulls up the REDAY signal of the sending end through the Aurora flow control interface, and the REDAY signal is valid at this time. This step can promptly notify the sender to suspend sending when the receiver cannot receive data.

[0075] In step 7, the FPGA takes out a queue item from the transmission queue and prepares to transmit data. This step obtains the description information of the data to be transmitted and prepares for the actual transmission of the data.

[0076] In step 8, the FPGA reads the data from the CPU and adds information such as the header, frame length, and trailer as needed to ensure that the data format meets the requirements of the receiving end. This step ensures that the data format is correct so that the receiving end can correctly parse and process the data.

[0077] In step 9, the FPGA checks whether the data corresponding to the current command has been completely sent. If the data has not been sent, it returns to step 6 to continue sending; if the data has been sent, it proceeds to the next step. This step ensures that the data is sent completely to avoid data loss or incompleteness.

[0078] In step 10, the FPGA sends an MSIX interrupt signal to the CPU to notify the CPU that the data transmission is completed. This step promptly notifies the CPU that the data transmission is completed through the interrupt mechanism so that the CPU can perform subsequent processing.

[0079] In step 11, after receiving the MSIX interrupt, the CPU releases the resources related to the sending operation, such as queue items, buffers, etc. This step cleans up the used resources and prepares for subsequent data sending.

[0080] In step 12, the CPU notifies the protocol stack that the frame data packet has been successfully sent. This step synchronizes the status of the protocol stack so that it knows that the data has been sent and can perform subsequent operations, such as confirming the sending or releasing resources.

[0081] In step 13, the producer and consumer pointers of the sending queue are updated to reflect the state change of the queue. This step ensures the correct operation of the queue and avoids data duplication or loss.

[0082] Example 2

[0083] Reference Figure 2 Figure 3 and Figure 5This embodiment provides a method for data transmission between FPGA hosts, wherein the data receiving method includes the following steps:

[0084] Step 1: FPGA loops to check whether the receiving queue is empty; if it is empty, it continues to check; otherwise, it goes to step 2;

[0085] Step 2: Receive data frame header and packet length information;

[0086] Step 3: Determine whether FIFO can receive data. If FIFO has reached the specified water level, a READY signal is given to the sender; otherwise, go to step 4.

[0087] Step 4: Receive a packet of data;

[0088] Step 5: Determine whether the current frame of data has been received. If it has been received, proceed to step 6; otherwise, return to step 4 and continue to receive the next packet of data.

[0089] Step 6: Update the producer pointer of the receiving queue to point to the next free position in the queue to prepare for the writing of subsequent data;

[0090] Step 7: Send a receive interrupt to the CPU to notify it that the data has been received;

[0091] Step 8: After receiving the receive interrupt, the CPU determines whether the receive queue is empty; if it is empty, it exits the interrupt processing; if it is not empty, it goes to step 9;

[0092] Step 9: The CPU obtains the corresponding queue item in the receiving queue;

[0093] Step 10: The CPU obtains the length information of the received data packet and fills it into the corresponding position in the protocol stack format;

[0094] Step 11: The CPU notifies the protocol stack that a new data packet has been successfully received, and the protocol stack begins to process the data;

[0095] Step 12: After the protocol stack completes processing, the user-mode program is notified that data reception has been completed;

[0096] Step 13: Allocate a new buffer for the next data reception and fill it into the queue item of the corresponding receiving queue to ensure that the queue always has free space for receiving data;

[0097] Step 14: Update the producer pointer and consumer pointer of the receiving queue.

[0098] Specifically, in step 1, the FPGA continuously checks the status of the receiving queue to determine whether the queue is empty. If the queue is empty, it means that there is no data to be received, and the FPGA continues to loop detection; if the queue is not empty, it means that there is data to be received, and the next step is entered. This step ensures that the FPGA can respond to new data reception requests in a timely manner to avoid data loss.

[0099] In step 2, the FPGA starts to receive the header information of the data frame, including the frame header and packet length information. The frame header usually contains information such as synchronization bytes and protocol type, and the packet length information indicates the length of the data packet to be received next. This step obtains the length information of the data packet so that the complete data packet can be correctly received.

[0100] In step 3, the FPGA checks the status of the internal FIFO (first-in-first-out queue) to determine whether there is enough space to receive data. If the FIFO has reached the specified water level (i.e., close to full), it sends a READY signal to the sender to notify the sender to suspend sending data; if the FIFO has not reached the water level, it proceeds to the next step. This step prevents data loss due to FIFO overflow and controls the sender's sending speed through the READY signal.

[0101] In step 4, the FPGA starts receiving a packet of data and stores it in the FIFO according to the packet length information obtained in step 2. This step receives and temporarily stores data in preparation for subsequent processing.

[0102] In step 5, the FPGA checks whether all data packets of the current frame have been received. If so, it proceeds to the next step; if not, it returns to step 4 to continue receiving the next packet of data. This step ensures the integrity of a frame of data and avoids receiving incomplete data packets.

[0103] In step 6, the FPGA updates the producer pointer of the receiving queue to point to the next free position in the queue so that subsequent data can continue to be written into the queue.

[0104] In step 7, the FPGA sends a receive interrupt signal to the CPU to notify the CPU that the data has been received. This step notifies the CPU in time that the data is ready so that the CPU can perform subsequent processing.

[0105] In step 8, after receiving the interrupt, the CPU checks whether the receiving queue is empty. If the queue is empty, it means that there is no data to be processed, and the CPU exits the interrupt processing; if the queue is not empty, it goes to the next step. This step ensures that the CPU only processes the actual data to avoid unnecessary processing.

[0106] In step 9, the CPU obtains the corresponding data table entry from the receiving queue, and the table entry contains information such as the storage location and length of the data. This step obtains the specific information of the data for subsequent processing.

[0107] In step 10, the CPU obtains the length information of the received data packet and fills it into the corresponding position in the data structure of the protocol stack.

[0108] In step 11, the CPU notifies the protocol stack that a new data packet has been successfully received, and the protocol stack starts processing the data, such as unpacking, checking, etc. This step starts the protocol stack's data processing flow.

[0109] In step 12, after the protocol stack completes processing, the user state program is notified that data reception has been completed and the user state program can read the data. This step notifies the application program that the data is ready and can be further processed or used.

[0110] In step 13, a new buffer is allocated for the next data reception and filled into the entry of the receiving queue to ensure that the queue always has free space for receiving new data. This step prepares for subsequent data reception and ensures that the system can continuously receive data.

[0111] In step 14, the producer pointer and consumer pointer of the receiving queue are updated to reflect the state change of the queue. This step maintains the correct operation of the queue and ensures the correct reception and processing of data.

[0112] The hardware frameworks relied on by the above two embodiments are as follows: Figure 2 As shown, it can also be expanded to support multi-device interconnection. When multiple devices are interconnected, it is necessary to expand the forwarding of the MAC address based on the AURORA link layer to the specified port.

[0113] General network cards are limited by the unreliable transmission of network exchanges, and data packet loss is relatively frequent (packet loss is mainly due to the influence of the network transmission medium and the inability to promptly notify the sender to suspend sending data when the receiver's buffer cannot receive data; since the bottom layer of the present invention adopts AURORA transmission, the transmission medium adopts reliable optical fiber transmission, and the ARUORA protocol can promptly notify the sender to suspend sending when the receiver cannot receive data). When a large MTU is used, retransmission will waste a lot of time when packets are lost, which will result in lower bandwidth when too large an MTU is used. Therefore, it is necessary to select a suitable MTU size. Currently, network equipment manufacturers usually set the maximum MTU to 9700. The FPGA-based TCP / IP Over AURORA transmission technology used in the present invention is based on reliable transmission, and no packet loss will occur during the transmission process. Therefore, based on this technology, the MTU can be expanded to 64K, which greatly reduces the CPU overhead caused by processing small data packets. At the same time, since the MTU is expanded to 64K, the bandwidth of data transmission between the host and the FPGA is greatly increased.

[0114] The present invention uses FPGA-based TCP / IP Over AURORA technology to expand the MTU to 64K, which greatly reduces the CPU overhead caused by processing small data packets. At the same time, since the MTU is expanded to 64K, the bandwidth of data transmission between the host and the FPGA is greatly increased. At the same time, based on the AURORA protocol, accurate data flow control of both communicating parties can be achieved. When the other device cannot receive data, a back pressure signal will be given. After receiving the back pressure signal, the sending end can suspend data transmission and resume transmission after the other party can receive data.

[0115] The present invention satisfies the user's convenience while meeting the large bandwidth of data transmission, and greatly reduces the CPU occupancy rate. Even if an embedded processor is used, a high data transmission bandwidth can be achieved.

[0116] The above description is only a description of the preferred embodiments of the present invention, and is not intended to limit the scope of the present invention. Any changes or modifications made by a person skilled in the art in the field of the present invention based on the above disclosure shall fall within the scope of protection of the claims.

Claims

1. A method for data transmission between FPGA hosts, characterized in that: in, The method for sending data includes the following steps: Step 1: When the user needs to send data, call the sending function interface of network programming to send the data to the protocol stack; Step 2: The protocol stack adds the corresponding TCP header and IP header as needed, and calls the data sending interface registered by the underlying driver to send the data to the driver; Step 3: The driver checks the queue status to determine whether data can be sent. If data can be sent, it proceeds to step 4; otherwise, it directly returns the BUSY status to the protocol stack, and the protocol stack selects an appropriate time to retry; Step 4: Get the free item in the queue, fill its descriptor, and increase the producer pointer by 1; Step 5: FPGA continuously checks whether the sending queue is empty. If it detects that the queue item is not empty, it goes to step 6; otherwise, it continues to loop detection; Step 6: Determine whether the AURORA READY signal is valid. If it is valid, proceed to step 7; Step 7: Get the queue item of the sending queue; Step 8: Read data from the CPU, fill in the header, frame length, and tail as needed, and send the data to AURORA; Step 9: Determine whether the data corresponding to the command has been sent. If not, return to step 6. If the command has been completed, proceed to step 10. Step 10: Send MSIX interrupt to CPU; Step 11: After receiving the interrupt, the CPU releases the corresponding sending resources; Step 12: Notify the protocol stack that the frame data packet has been sent; Step 13: Update the producer and consumer pointers corresponding to the sending queue.

2. The method for data transmission between FPGA hosts according to claim 1, characterized in that: In step 6, the method for determining whether the AURORA REDAY signal is valid is: When the Aurora interface receiving end detects that the cache reaches the set highest threshold, the FPGA pulls down the sending end REDAY signal through the Aurora flow control interface. At this time, the REDAY signal is invalid; when the cache is lower than the set lowest threshold, the FPGA pulls up the sending end REDAY signal through the Aurora flow control interface. At this time, the REDAY signal is valid.

3. A method for data transmission between FPGA hosts, characterized in that: in, The method for receiving data comprises the following steps: Step 1: FPGA loops to check whether the receiving queue is empty; if it is empty, it continues to check; otherwise, it goes to step 2; Step 2: Receive data frame header and packet length information; Step 3: Determine whether FIFO can receive data. If FIFO has reached the specified water level, a READY signal is given to the sender; otherwise, go to step 4. Step 4: Receive a packet of data; Step 5: Determine whether the current frame of data has been received. If it has been received, proceed to step 6; otherwise, return to step 4 and continue to receive the next packet of data. Step 6: Update the producer pointer of the receiving queue to point to the next free position in the queue to prepare for the writing of subsequent data; Step 7: Send a receive interrupt to the CPU to notify it that the data has been received; Step 8: After receiving the receive interrupt, the CPU determines whether the receive queue is empty; if it is empty, it exits the interrupt processing; if it is not empty, it goes to step 9; Step 9: The CPU obtains the corresponding queue item in the receiving queue; Step 10: The CPU obtains the length information of the received data packet and fills it into the corresponding position in the protocol stack format; Step 11: The CPU notifies the protocol stack that a new data packet has been successfully received, and the protocol stack begins to process the data; Step 12: After the protocol stack completes processing, the user-mode program is notified that data reception has been completed; Step 13: Allocate a new buffer for the next data reception and fill it into the queue item of the corresponding receiving queue; Step 14: Update the producer pointer and consumer pointer of the receiving queue.

Images