This project is based on the Xilinx Artix7 XC7A35T chip. The
Ethernet chip selected is RTL8211EG PHY chip MAC and PHY interface standard is GMII
development tool is vivado 2018.3
This issue explains the sending code of Ethernet.
Note that sending here refers to sending from the FPGA development board to the PC
The first code does not need to be explained too much, the comments have been marked in detail. The 4-byte check refers to FCS.
In the second part, we can see that this is actually not the IP header mentioned in the comment. Strictly speaking, this is the format of the MAC frame. The preamble plus the start and destination addresses of the MAC, and then 8x0800 indicates that the upper layer protocol of the MAC frame is The IP protocol is as follows:
It is worth noting that all 6 bytes of the MAC target address are written in ff, which means to find the destination address through broadcast. The specific principle is in another article of mine: Based on Xilinx artix 7 Advanced FPGA Application (2): Gigabit Ethernet Communication (Principle) The second period of the supplement is posted here https://blog.csdn.net/weixin_43824941/article/details/108312347
To send the program, we first send the IP header data according to the IP header format. Here we use 32-bit registers to divide the header data into several parts. The overall structure of the IP protocol is as follows:
In the first register, the version number here is IPV4, and its code is 0010 in hexadecimal. 4. Then the unit of the header length is 4 bytes, where 5*4 bytes = 20 bytes. Next, we fill in 0 for the service type; the next 16 bits are the total length of the entire IP packet.
Next, in the second register, the first 16 bits are the packet sequence number, because when transmitting data packets, we often transmit them in fragments (this has little effect on the TCP protocol, because it is transmitted in fragments), this The sequence number can help us uniquely identify the fragmented IP packet.
The next 16 bits have 3 flag bits and 13 chip displacement: used for IP datagram fragmentation.
Three-bit flag: The first bit of this field is not used, and the second bit is the DF (Don't Fragment) bit. When the DF bit is set to 1, it indicates that the IP does not fragment the packet. The third bit is the MF (More Fragments) bit. When fragmenting a data packet, except for the last one, this bit must be set to 1 for every other fragment that composes the datagram.
13-bit fragment offset: used for IP datagram fragmentation. The unit is 8 bytes. Indicates the position of the slice relative to the beginning of the original datagram, and the maximum offset that can be represented is 2132
13 *8=65536 bytes.
Here we see that the latter 16 bits are uniformly represented by 4000, then the expanded value is 0100000000000000. The first three bits indicate that the IP packet is not fragmented, and the latter corresponds to it-if not fragmented, the fragment offset must be 0.
In the 3rd register, contains the survival time, the protocol also has the first checksum.
Write 80110000 in it. First, 80 expansion is 10000000, which is 128. The survival time is reduced by 1 every time a router passes. When it reaches 0, the packet will be discarded. The following 11 expands to 00010001, which is 17, which means that the upper layer of the IP data packet is a UDP data packet (1 represents the ICMP protocol, 2 represents the IGMP protocol, and 6 represents the TCP protocol).
The first checksum is all set to 0 here.
Place the source IP address and the destination IP address in the next register and the next register successively. Note that this destination IP address is to be broadcast to the entire LAN.
Strictly speaking, the next register does not belong to the IP header, but the content of the UDP protocol. Of course, the entire UDP packet is included in the data part of the IP data packet, so it can also be said to be a part of the IP data packet. First look at the UDP format:
In the 6th and 7th registers, we have completed the UDP header, and thus basically completed the data packaging.
At this time, we have to calculate the checksum of the header:
so that we understand why the header checksum was set to 0 before.
The work we have done above is actually assembling data packets without starting to send data.
Next we begin to officially send the data packet:
First enable the GMII port, and then reset the verification function. Then start sending the preamble and start code, and then start sending the source and destination MAC addresses, and then notice that the CRC check is turned on at this time. There are a lot of things about CRC check. I will write another article to explain, here first No introduction.
Here we send the pre-prepared IP packet header, and then send the data to be sent in the RAM into the buffer of the last real data sent here. It is worth noting here that due to the limitation of the GMII port, each data sent is in units of eight bits. Earlier we said that the program also writes the UDP header into the register named IP header, so the UDP header has been sent here.
Here starts to read the data that really needs to be sent from the buffer for transmission. There is a habit of writing FPGA programs , that is, the operation when the counter overflows will be written first, just like the code block in the above figure, we will perform the following operations at the beginning, know that the counter is about to overflow, and then perform the above operations. It is to transmit the last data packet.
The last is CRC check. This we will open a blog dedicated to CRC, FCS and the check bit of the IP header and UDP header.
That's it for this sharing. I am not a professional in the field of network communication. If there is any mistake, please point it out in the comment area!
Thanks for watching!