Method and System for Debugging Multiple FPGAs by a PC Based on UDP / IP Protocol

Abstract

The present invention provides a method and system for a PC to debug multiple FPGAs based on the UDP / IP protocol. By respectively setting the receive and transmit synchronization numbers at the FPGA side and the PC side obtaining and saving the synchronization numbers through querying, when sending a debug command or debug result, the receive synchronization number is packetized with the debug command or the transmit synchronization number is packetized with the debug result into a network packet. By judging whether the receive and transmit synchronization numbers at both ends are legal, it is determined whether the packet is lost. When the debug command packet is legal, the debug command packet in the network packet is then converted into a debug command to debug the FPGA, ensuring reliable communication. Since UDP / IP and the upper-layer protocol are fully implemented on the FPGA, the entire debugging process does not require the assistance of other processors, saving debugging resources.

Description

Technical Field

[0001] The present invention belongs to the field of FPGA debugging, and particularly relates to a method and system for a PC to debug multiple FPGAs based on the UDP / IP protocol. Background Art

[0002] During the development and use of FPGAs, online debugging, monitoring, and control functions are very important. During the development process, the online debugging function facilitates problem location. During the use process, it is necessary to monitor the working status of the FPGA.

[0003] The most commonly used debugging method is to use the JTAG bus. Connecting the PC and the FPGA with a JTAG cable and a debugging tool enables debugging. Multiple FPGAs can be connected in series with a JTAG cable for debugging.

[0004] It is also possible to use Xilinx's XVC tool, which is based on TCP and can debug FPGAs through the network.

[0005] However, the JTAG cable is not suitable for networking and is not suitable for dynamically adding or removing devices. When it is necessary to debug the FPGAs of an entire chassis, JTAG is difficult to meet the requirements.

[0006] The XVC tool requires a processor to cooperate to work. The processor runs the TCP protocol stack and the XVC protocol stack. This solution increases costs and is not suitable for FPGAs without an embedded processor.

[0007] The open-source solution github Alexforencich / xfcp can implement network debugging of FPGAs. This solution is based on UDP and the message length is variable. This solution only requires an FPGA to work and does not require an additional processor. However, this solution is based on UDP and does not have a design to ensure reliable communication. The solution consumes a lot of resources, and for the debugging function, occupying too much FPGA resources is not worth the gain. Summary of the Invention

[0008] The main problem to be solved by the present invention is how to debug FPGAs reliably with fewer resources, and provides a method and system for a PC to debug multiple FPGAs based on the UDP / IP protocol.

[0009] To solve the above technical problems, the technical solutions adopted are as follows:

[0010] A method for a PC to debug multiple FPGAs based on the UDP / IP protocol includes the following steps:

[0011] Step 1: The PC end communicates with multiple FPGAs to be debugged through network networking based on the UDP / IP protocol, and each FPGA end has an independent device number;

[0012] Step 2: A receiving synchronization number and a sending synchronization number counter are set on the FPGA side, which are used to count the debug command messages received through the network or the debug result messages sent.

[0013] Step 3: When the PC side establishes a connection with the FPGA to be debugged, the PC side sends a message to query the device number, the receiving synchronization number, and the sending synchronization number of the FPGA side. When the queried device number is consistent with the device number saved on the PC side, the connection is successful, and the queried receiving synchronization number and sending synchronization number are stored on the PC side.

[0014] Step 4: After the connection is successful, the PC side sends a debug command, packs the debug command and the receiving synchronization number into a network message, and transfers the network message to the FPGA to be debugged through the network based on the network protocol.

[0015] Step 5: After the FPGA checks that the network message is correct according to the transmission protocol checksum, it also needs to check whether the receiving synchronization number in the network message is legal. When it is legal, the debug command in the network message is converted into a debug command on the FPGA internal debug bus to debug the FPGA.

[0016] Step 6: Pack the debug result returned by the FPGA internal debug bus and the sending synchronization number into a network message, and transfer the network message to the PC side through the network based on the UDP / IP protocol.

[0017] Step 7: After the PC side checks that the network message is correct according to the transmission protocol checksum, it also needs to check the legality of the sending synchronization number in the network message. When it is legal, the debugging is successful.

[0018] Further, the method for the FPGA to check whether the receiving synchronization number in the network message is legal is as follows:

[0019] When the PC side sends a debug command message, the value obtained by adding 1 to the receiving synchronization number saved on the PC side is packed with the debug command into a message and sent to the FPGA side. The FPGA side checks whether the receiving synchronization number in the message is the same as the value obtained by adding 1 to the receiving synchronization number inside the FPGA. If they are the same, it is a legal message; for a legal message, the receiving synchronization number on the FPGA side is incremented by 1, and at the same time, the FPGA is debugged using the debug command in the message.

[0020] Further, the method for the PC side to check the legality of the sending synchronization number in the network packet and the sending synchronization number of the PC side is as follows: When the FPGA side sends a debug result packet, the sending synchronization number inside the FPGA is incremented by 1, and then the sending synchronization number of the FPGA side and the debug result are combined into a packet and sent to the PC side. The PC side determines whether the value of the sending synchronization number in the packet is the same as the value after the sending synchronization number of the PC side is incremented by 1. If they are the same, the packet is a legal packet.

[0021] Further, the types of the network packets include: query node information packet, node response information packet, debug command packet, debug result packet, retransmission debug result instruction packet;

[0022] The query node information packet includes a packet type field;

[0023] The node response information packet includes: a packet type field, a sending synchronization number, a receiving synchronization number, a device number, UDP checksum correction;

[0024] The debug command packet includes: a packet type field, a receiving synchronization number, debug command data, UDP checksum correction;

[0025] The debug result packet includes: a packet type field, a sending synchronization number, a debug command result, UDP checksum correction;

[0026] The retransmission debug result instruction packet includes: a packet type field, UDP checksum correction.

[0027] Further, when transmitting packets through UDP, the length of the packet is set to a fixed value, and the packets with lengths less than the fixed length in each type of packet are padded with 0s.

[0028] Further, after the PC side sends a debug command packet, the PC side enters a waiting state. If the PC side does not receive a debug result packet given by the FPGA within the specified time, the PC side sends a query node information packet. When receiving the node response information packet from the FPGA, it determines the error location according to the consistency between the receiving synchronization number and the sending synchronization number in the node response information packet and the receiving synchronization number and the sending synchronization number of the PC side.

[0029] Further, the method for determining the error location according to the consistency between the receiving synchronization number and the sending synchronization number in the node response information packet and the receiving synchronization number and the sending synchronization number of the PC side is as follows:

[0030] If the receiving synchronization number in the node response information packet is the same as the receiving synchronization number of the PC side, the debug command packet sent from the PC side to the FPGA side is lost, and the PC side resends the debug command packet;

[0031] If the transmission synchronization number in the node response information packet is the same as that of the PC, it means that the FPGA does not send the debugging result packet, indicating abnormal operation of the FPGA.

[0032] If the transmission synchronization number in the node response information packet is the same as the transmission synchronization number of the PC plus 1, it means that the debugging result packet from the FPGA to the PC is lost. In this case, the PC sends a retransmission debugging result instruction packet, and the FPGA resends the debugging result packet to the PC. When the PC sends the retransmission debugging result instruction packet, the receive synchronization numbers at both the PC and FPGA ends do not change, and the transmission synchronization number of the FPGA remains unchanged when it resends the debugging result packet.

[0033] Further, after the connection between the PC and the FPGA is successful, the PC periodically sends a query node information packet and confirms the connection status according to whether the device numbers in the responded node information packet are consistent.

[0034] When the PC sends a query node information packet and does not receive the node information packet responded by the FPGA, it repeats sending the query node information packet and executes the above steps until the upper limit of the repeated sending times is reached, at which time a network exception notification message is issued.

[0035] Further, the method for the FPGA to check whether the network packet is correctly verified according to the transmission protocol is as follows: the IP checksum is correct, the UDP checksum is correct, and the Ethernet CRC check is correct.

[0036] The present invention also provides a system for the PC to debug multiple FPGAs based on the UDP / IP protocol, which realizes each step of a method for the PC to debug multiple FPGAs based on the UDP / IP protocol.

[0037] Adopting the above technical solutions, the present invention has the following beneficial effects:

[0038] A method and system for the PC to debug multiple FPGAs based on the UDP / IP protocol provided by the present invention, by respectively setting receive and transmission synchronization numbers at the FPGA end and the PC obtaining and saving the synchronization numbers through query. When sending a debugging command or debugging result, the receive synchronization number is packetized with the debugging command or the transmission synchronization number is packetized with the debugging result into a network packet. By judging whether the receive and transmission synchronization numbers at both ends are legal, it is determined whether the packet is lost. When the debugging command packet is legal, the debugging command packet in the network packet is then converted into a debugging command to debug the FPGA, ensuring reliable communication. Since UDP / IP and the upper-layer protocol are fully implemented on the FPGA, the entire debugging process does not require the assistance of other processors, saving debugging resources. Description of the Drawings

[0039] Figure 1 Schematic diagram of the connection process between the PC and the FPGA of the present invention;

[0040] Figure 2 Schematic diagram of the read data operation process;

[0041] Figure 3 Schematic diagram of the write data operation process. Specific implementation manner

[0042] Next, the technical solution of the present invention will be clearly and completely described in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0043] Figures 1 to 3 Shows a specific embodiment of a method for a PC to debug multiple FPGAs based on the UDP / IP protocol in the present application, including the following steps:

[0044] Step 1: The PC end and multiple FPGAs to be debugged perform network networking communication based on the UDP / IP protocol, and each FPGA end has an independent device number.

[0045] In this embodiment, by using the UDP / IP protocol for networking, the PC end is connected to multiple FPGAs, and multiple FPGAs can be debugged. By making each FPGA end have an independent device number, it is convenient to confirm which FPGA is connected through the network.

[0046] Step 2: A receive synchronization number and a send synchronization number counter are set at the FPGA end, which are used to count the debug command packets received through the network or the debug result packets sent.

[0047] In this embodiment, by setting a receive synchronization number and a send synchronization number counter at the FPGA end, it is convenient to count the debug commands received or the debug results sent by the FPGA end.

[0048] Step 3: When establishing a connection between the PC end and the FPGA to be debugged, the PC end sends a packet to query the device number, receive synchronization number, and send synchronization number of the FPGA end. When the queried device number is consistent with the device number saved at the PC end, the connection is successful, and the queried receive synchronization number and send synchronization number are stored at the PC end.

[0049] In this embodiment, the PC establishes a connection with the FPGA to be debugged by sending a query message from the PC. The FPGA responds with the device number, receive synchronization number, and send synchronization number at the current FPGA end. When the device number in the responded node information is the same as the device number that the PC end wants to connect to, the connection is successful. The received synchronization number and send synchronization number queried are stored at the PC end, which is convenient for using the synchronization number to determine whether the message is successfully sent when sending a debug command next.

[0050] Step 4: After the connection is successful, the PC end sends a debug command, packs the debug command and the receive synchronization number together into a network message, and transfers the network message to the FPGA to be debugged through the network based on the network protocol.

[0051] In this embodiment, the types of the network messages include: query node information message, node response information message, debug command message, debug result message, retransmission debug result instruction message;

[0052] The query node information message includes a message type field;

[0053] The node response information message includes: message type field, send synchronization number, receive synchronization number, device number, UDP checksum correction;

[0054] The debug command message includes: message type field, receive synchronization number, debug command data, UDP checksum correction;

[0055] The debug result message includes: message type field, send synchronization number, debug command result, UDP checksum correction;

[0056] The retransmission debug result instruction message includes: message type field, UDP checksum correction.

[0057] By means of the query node information message and the node response information message, the PC end and the FPGA end can establish a connection. The UDP checksum correction bit can verify the accuracy during the message transmission process. By packing the debug command data and the receive synchronization number together into a message, it is convenient for the PC and the FPGA end to verify the legality of the message. Through the message type field, the type of the transmitted message can be known, so as to make corresponding information responses. By setting the retransmission debug result instruction message, in the case that the debug result message sent by the FPGA end is lost, the FPGA end can be required to re-send the information of the previous debug result message.

[0058] The debug command data is used to operate the internal debugging of the FPGA, and the debug result is used to feedback the debug result obtained by the FPGA using the debug data.

[0059] In this embodiment, when transmitting packets via UDP, the length of the packet is set to a fixed value, and packets of various types with a length shorter than the fixed length are padded with 0s. In this embodiment, the length of the packet, i.e., the upper-layer protocol, is fixed at 18 bytes, a UDP checksum correction bit is set in the last 2 bytes of the upper-layer protocol stack, and the UDP checksum bit of the response packet is set to a fixed value. By fixing the length and the last correction bit, the UDP / IP protocol can be trimmed, and fewer LUT and register resources are required when implementing it on an FPGA.

[0060] Since UDP and IP support features such as packet fragmentation, implementing the complete UDP / IP protocol on an FPGA consumes a large amount of resources. By fixing the length of the upper-layer protocol, unnecessary UDP / IP features can be trimmed, and then a protocol stack that is usable and compliant with the UDP / IP specification can be implemented with fewer resources. In this embodiment, both the fixed length and the checksum correction bit are for facilitating the trimming of the protocol, making the protocol stack as small as possible.

[0061] Step 5: After the FPGA checks that the network packet is correct according to the transmission protocol checksum, it also needs to check whether the received synchronization number in the network packet is legal. When it is legal, the debug command in the network packet is converted into a debug command for the internal debug bus of the FPGA to debug the FPGA.

[0062] In this embodiment, when the FPGA receives a network packet, it will check that the CRC, IP checksum, and UDP checksum set in the packet according to the transmission protocol are all correct, and then check the legality of the received synchronization number and the received synchronization number in the FPGA.

[0063] In this embodiment, the method for the FPGA to check the legality of the received synchronization number in the network packet and the received synchronization number in the FPGA is as follows:

[0064] When sending a debug command packet at the PC end, the value obtained by adding 1 to the received synchronization number saved at the PC end is packetized together with the debug command and sent to the FPGA end. The FPGA end checks whether the received synchronization number in the packet is the same as the value obtained by adding 1 to the received synchronization number inside the FPGA. If they are the same, it is a legal packet; for a legal packet, the received synchronization number at the FPGA end is incremented by 1, and at the same time, the debug command in the packet is used to debug the FPGA. By setting the synchronization number to judge the legality, it is simple, convenient, and reliable, and ensures the accuracy of the transmission of the debug command. If they are not the same, it is an illegal packet, indicating that the packet is lost.

[0065] Step 6: The debug result returned by the internal debug bus of the FPGA is packetized together with the transmission synchronization number into a network packet, and the network packet is transmitted to the PC end via the network based on the network protocol.

[0066] In this embodiment, the debugging command data and the received synchronization number are packetized together in the debugging command message, and the transmitted synchronization number and the debugging command result are packetized together into a message in the debugging result message, which can not only realize the transmission of the message, but also verify the legality of the message through the synchronization number in the message.

[0067] Step 7: After the PC checks that the network message is correct according to the transmission protocol verification, it also needs to check the legality of the transmitted synchronization number in the network message. When it is legal, the debugging is successful.

[0068] In this embodiment, the method for the PC to check the legality of the transmitted synchronization number in the network message and the transmitted synchronization number of the PC is as follows: when the FPGA sends the debugging result message, the transmitted synchronization number inside the FPGA is incremented by 1, and then the transmitted synchronization number of the FPGA and the debugging result are combined into a message and sent to the PC. The PC determines whether the value of the transmitted synchronization number in the message is the same as the value after the transmitted synchronization number of the PC is incremented by 1. If they are the same, the message is legal.

[0069] In this embodiment, after the PC sends the debugging command message, the PC enters the waiting state. If the PC does not receive the debugging result message given by the FPGA within the specified time, the PC sends a query node information message. When receiving the node response information message from the FPGA, it judges the error location according to the consistency of the received synchronization number and the transmitted synchronization number in the node response information message and the received synchronization number and the transmitted synchronization number of the PC. The method for judging the error location is:

[0070] If the received synchronization number in the node response information message is the same as the received synchronization number of the PC, the debugging command message sent from the PC to the FPGA is lost, and the PC resends the debugging command message;

[0071] If the transmitted synchronization number in the node response information message is the same as the transmitted synchronization number of the PC, the FPGA does not send the debugging result message and the FPGA works abnormally;

[0072] If the transmitted synchronization number in the node response information message is the same as the value after the transmitted synchronization number of the PC is incremented by 1, it means that the debugging result message from the FPGA to the PC is lost. The PC sends a retransmission debugging result instruction message, and the FPGA resends the debugging result message to the PC. When the PC sends the retransmission debugging result instruction message, the received synchronization numbers of the PC and the FPGA do not change, and the transmitted synchronization number of the FPGA does not change when it resends the debugging result message.

[0073] In this embodiment, by querying the node message information and sending the synchronization numbers for reception and transmission, the PC can determine the current communication status based on the synchronization number information stored locally and the synchronization number information on the FPGA, and perform corresponding remedial operations according to the location of communication failure to ensure the correct transmission of data. When receiving debug commands and sending debug results at the FPGA end, the synchronization numbers are counted. The PC end determines the error location based on the consistency between the queried synchronization number and the saved synchronization number. By checking the transmission synchronization numbers at both ends, it can be confirmed whether the FPGA has sent a message. By setting the reception and transmission synchronization numbers, each message sent and received is verified, ensuring the correctness of the message. With the reception and transmission synchronization numbers, the reliability of communication can be guaranteed. One is to ensure that data reaches the FPGA and the PC, and the other is to ensure that the data arrives in the correct order. The simple UDP protocol cannot guarantee the arrival of data or the order in which data arrives.

[0074] In this embodiment, after the connection between the PC end and the FPGA is successful, the PC end periodically sends a query node information message and confirms the connection status based on whether the device numbers in the responded node information message are consistent; when the PC end sends a query node information message and does not receive a node information message responded by the FPGA, it repeatedly sends the query node information message and executes the above steps until the upper limit of the repeated sending times is reached, and then issues a network exception notification message. By periodically sending a query node information message, it can be determined whether the FPGA is normally connected.

[0075] For example, the debug command message sent by the PC end is lost. After the PC sends a debug command message and the message is lost, the FPGA end does not receive the message (reception synchronization number 0, transmission synchronization number 0), and the FPGA end does not respond. The PC end sends a query node information message, and the FPGA returns a node information message (reception synchronization number 0, transmission synchronization number 0). The PC end compares and finds that the reception synchronization number has not increased, indicating that the message is lost from the PC to the FPGA. The PC resends a debug command message, and the FPGA receives a legal message (reception synchronization number 1, transmission synchronization number 0). The FPGA processes the debug function and sends the result. The FPGA sends a debug result message (reception synchronization number 1, transmission synchronization number 1), and the PC receives the debug result message, and the debug operation is completed.

[0076] For another example, the debug result message sent by the FPGA is lost. First, the PC sends a debug command message. The current state of the FPGA is (receive synchronization number 0, send synchronization number 0). The FPGA receives a legal message (receive synchronization number 1, send synchronization number 0), processes the debug function of the FPGA, and the FPGA sends a debug result message (receive synchronization number 1, send synchronization number 1). At this time, the message is lost and the PC does not receive the message. The PC sends a query node information message, and the FPGA returns a node response information message (receive synchronization number 1, send synchronization number 1). The PC compares and finds that the send synchronization number is 1, indicating that the message is lost from the FPGA to the PC. The PC sends a retransmission debug result instruction message. The current state of the FPGA is (receive synchronization number 1, send synchronization number 1). The FPGA receives the retransmission debug result instruction message (receive synchronization number 1, send synchronization number 1. Because it is a retransmission debug result instruction message, neither the receive synchronization number nor the send synchronization number changes). The FPGA repeats the previously sent debug result message (receive synchronization number 1, send synchronization number 1), and the PC receives the debug result message, and the debugging is completed.

[0077] As can be seen from the above two examples, by separately setting the receive synchronization number and the send synchronization number, the PC can determine in which link the message is lost. By setting the retransmission node information message in the message, the node information and synchronization number situation of the FPGA side can be known. By retransmitting the data message, it is possible to resend in the case of message loss.

[0078] In this embodiment, for multiple FPGAs, by setting the IP address and IP port interface, the PC can access the corresponding FPGA through the network. By connecting multiple FPGAs to the PC through the network, when the PC accesses which FPGA to be debugged, through the IP address and IP PORT, the corresponding FPGA can be connected without using additional equipment.

[0079] The present invention also provides a system for the PC to debug multiple FPGAs based on the UDP / IP protocol, which realizes each step of a method for the PC to debug multiple FPGAs based on the UDP / IP protocol.

[0080] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for PC to debug multiple FPGAs based on the UDP / IP protocol, characterized in that It includes the following steps: Step 1: The PC communicates with multiple FPGAs to be debugged through network networking based on the UDP / IP protocol, and each FPGA has an independent device number; Step 2: A receiving synchronization number and a sending synchronization number counter are set at the FPGA end to count the debug command packets received through the network or the debug result packets sent; Step 3: When establishing a connection between the PC and the FPGA to be debugged, the PC sends a packet to query the device number, receiving synchronization number, and sending synchronization number of the FPGA end. If the queried device number is consistent with the device number saved on the PC, the connection is successful, and the queried receiving synchronization number and sending synchronization number are stored on the PC; Step 4: After the connection is successful, the PC sends a debug command, packs the debug command and the receiving synchronization number into a network packet, and transfers the network packet to the FPGA to be debugged through the network based on the network protocol; Step 5: After the FPGA checks that the network packet is correct according to the transmission protocol check, it also needs to check whether the receiving synchronization number in the network packet is legal. When it is legal, the debug command in the network packet is converted into a debug command on the FPGA internal debug bus to debug the FPGA; Step 6: Pack the debug result returned by the FPGA internal debug bus and the sending synchronization number into a network packet, and transfer the network packet to the PC through the network based on the UDP / IP protocol; Step 7: After the PC checks that the network packet is correct according to the transmission protocol check, it also needs to check the legality of the sending synchronization number in the network packet. When it is legal, the debugging is successful; The method for the FPGA to check whether the receiving synchronization number in the network packet is legal is: When the PC sends a debug command packet, the value obtained by adding 1 to the receiving synchronization number saved on the PC and the debug command are packed into a packet and sent to the FPGA end. The FPGA end checks whether the receiving synchronization number in the packet is the same as the value obtained by adding 1 to the receiving synchronization number inside the FPGA. If they are the same, it is a legal packet; For a legal packet, increment the receiving synchronization number of the FPGA end by 1, and at the same time use the debug command in the packet to debug the FPGA; The method for the PC to check the legality of the sending synchronization number in the network packet and the sending synchronization number of the PC is: when the FPGA end sends a debug result packet, increment the sending synchronization number inside the FPGA by 1, and then form a packet with the sending synchronization number of the FPGA end and the debug result and send it to the PC. The PC checks whether the value of the sending synchronization number in the packet is the same as the value obtained by adding 1 to the sending synchronization number of the PC. If they are the same, it is a legal packet.

2. The method for a PC to debug multiple FPGAs based on the UDP / IP protocol according to claim 1, wherein The types of the network packets include: query node information packet, node response information packet, debug command packet, debug result packet, retransmission debug result instruction packet; The query node information packet includes a packet type field; The node response information packet includes: packet type field, sending synchronization number, receiving synchronization number, device number, UDP checksum correction; The debug command message includes: a message type field, a received synchronization number, debug command data, and UDP checksum correction; The debug result message includes: a message type field, a sent synchronization number, a debug command result, and UDP checksum correction; The retransmission debug result instruction message includes: a message type field and UDP checksum correction.

3. A method for a PC to debug multiple FPGAs based on the UDP / IP protocol according to claim 2, characterized in that, When transmitting messages via UDP, the length of the message is set to a fixed value, and for messages of each type with a length less than the fixed length, the message is padded with 0s.

4. A method for a PC to debug multiple FPGAs based on the UDP / IP protocol according to claim 3, characterized in that, After the PC sends a debug command message, the PC enters a waiting state. If the PC does not receive a debug result message given by the FPGA within the specified time, the PC sends a query node information message. When receiving the node response information message from the FPGA, it determines the error location based on the consistency between the received synchronization number and sent synchronization number in the node response information message and the received synchronization number and sent synchronization number of the PC.

5. A method for a PC to debug multiple FPGAs based on the UDP / IP protocol according to claim 4, characterized in that The method for determining the error location based on the consistency between the received synchronization number and sent synchronization number in the node response information message and the received synchronization number and sent synchronization number of the PC is as follows: If the received synchronization number in the node response information message is the same as the received synchronization number of the PC, the debug command message sent from the PC to the FPGA is lost, and the PC resends the debug command message; If the sent synchronization number in the node response information message is the same as the sent synchronization number of the PC, the FPGA does not send a debug result message, and the FPGA is operating abnormally; If the sent synchronization number in the node response information message is the same as the sent synchronization number of the PC plus 1, the debug result message from the FPGA to the PC is lost. The PC sends a retransmission debug result instruction message, and the FPGA resends the debug result message to the PC. When the PC sends the retransmission debug result instruction message, the received synchronization numbers of the PC and the FPGA do not change, and when the FPGA resends the debug result message, its sent synchronization number does not change.

6. A method for a PC to debug multiple FPGAs based on the UDP / IP protocol according to claim 5, characterized in that, After the PC and the FPGA are successfully connected, the PC periodically sends a query node information message and confirms the connection status based on whether the device numbers in the responded node information message are consistent; When the PC sends a query node information message and does not receive a node information message responded by the FPGA, it repeats sending the query node information message and executes the above steps until the upper limit of the repeated sending times is reached, and then issues a network exception notification message.

7. A method for a PC to debug multiple FPGAs based on the UDP / IP protocol according to any one of claims 1 to 6, characterized in that The method for the FPGA to check whether the network message is correctly verified according to the transmission protocol is: the IP checksum is correct, the UDP checksum is correct, and the Ethernet CRC check is correct.

8. A system for PC to debug multiple FPGAs based on the UDP / IP protocol, characterized in that, Implement each step of the method for PC to debug multiple FPGAs based on the UDP / IP protocol described in any one of claims 1 to 7.

Images