Hi all Now, the data is being wrapped by UDP frame, UDP frame is being wrapped by IPv4 frame and the result is being encapsulated by Ethernet frame. The packet is being transferred by VCU118 and being received on PC successfully.
I got an email from Adam about putting everything together which I would be happy to do that and I'm the process. Below, there are some details about specifications and what I went through. 1- ARP table is not supported yet. The reason is that I have the PC's MAC address so I didn't need ARP table. I'll work on that. 2- Data fragmentation is not supported. Should fragmentation happen? At the moment the packet size is constant and equals to 64Bytes. 3- I need to do benchmarking. Please share possible methods. The main issue I faced was with Ethernet frame. At first, everything seemed to be correct but the packets were being dropped by the interface. I used "Wireshark" and "tcpdump" to debug the issue and I found the problem. I had put "Preamble, SFD and FCS" bits (12Bytes in total) in the header. However, by observing other validated packets received by the interface, I learned that I do not need them. Currently the Ethernet header looks like: 248a079168840a0a0a0100000800 0x248a07916884 -> PC MAC address 0x0a0a0a010000 -> VCU118 MAC address 0x0800 -> IPv4 (Total Header Size : 14Bytes) IPv4 Header looks like: 4500003200004000ff1163700a0202320a020215 4 -> IPv4 5 -> Header Size 00 -> DSCP and ECN 0032 -> Total IPv4 Length + UDP frame (50 Bytes) 0000 -> Identification 4000 -> Flags and Fragment Offset ff -> Time to Live 11 -> UDP frame 6370 -> Checksum 0a020232 -> VCU118 IP 10.2.2.50 0a020215 -> PC IP 10.2.2.21 (Total Header Size: 20 Bytes) UDP Header looks like: 0fa09c40001e0000 0fa0 -> Source Port 4000 9c40 -> Destination Port 40000 001e -> UDP Length + Data (30 Bytes) 0000 -> UDP checksum (Total Header Size : 8Bytes) TOTAL HEADER SIZE -> Ethernet + IPv4 + UDP = 42 Bytes. So there will be 64-42= 22 Bytes for the data. I would be happy to get your feedbacks and opinions. Best Regards Arash Roshanineshat On Mon, Feb 26, 2018 at 3:13 PM, Roshanineshat, Arash < arash.roshanines...@cfa.harvard.edu> wrote: > Hi > > I'm trying to implement a design using UltraScale+ 100G Ethernet on a > VCU118 board. I use Vivado 2017.4 and UltraScale+ 100G Ethernet IP > core subsystem version 2.4. > > I'll give you a quick background about what I have done so far, please > let me know if I took a wrong step at any point. > > I want to implement OSI model which consists of following layers: > > 7-Application layer > 6-Presentation layer > 5-Session Layer > 4-Transport > 3-Network Layer > 2-Data Link Layer > 1-Physical layer > > According to what I learned from Xilinx's forum community, 100G IP > core will take care of Ethernet protocol (Layers 1 and 2) and I have > to implement Layers 3 and 4. However, Linux operating system will take > care of Layers 3 and 4 for me. Therefore, I only need to generate the > data and use GTY transceivers to transfer them to the network. Right? > > To customize GTY Transceivers to use QSFP1, and to test it I did the > following: > > 1-As GTY documentation says, QSFP1 is located in left side quads and > in quad 231. > 2-I selected X1Y48~51 channels of CMACE4 X0Y7. I chose this value > because I saw it will put the transceivers on quad bank 231. > 3-I chose CAUI4 mode (4 lanes x 25.7812G) Simple TX. > 4-I generated an IP core using the above settings. > 5-I generated an Open IP Example design using the IP generated above > to experiment with it. > 6-I connected gt_refclks to QSFP_SI570_CLOCK_C_P/N for QSFP1 > 7-I initiated a IBUFS to convert a LVDS clock to single-ended clock > and connected it to init_clk > 8-Create a xdc file according to my VCU118 pinouts. > 9-generated the bitcode > > I loaded the bitcode to the FPGA board and I noticed TX_gt_locked, > TX_done, TX_busy LEDs are blinking correctly. So I *guess* the data is > being generated too. the problem I have now is that I cannot bring up > the QSFP interface and our 100G infiniband switch, reports that the > QSFP port connected to the FPGA is "down". > > What I'm suspicious about is that I have selected a wrong GTY > transceiver configuration, however, It seems to me, everything is > according to the documentation and the other reason I can think of is > the clock values. > > I would be grateful if you could advise me on possible solutions or > debugging methods that I can try. > > Best Regards > Arash Roshanineshat > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
