Tuesday, July 29, 2014

Last day of debugging 1 Gbps transmitter's MAC

Today the first thing was testing the packetizer via simulation and the last thing that was emulation using Xilinx Chipscope, which took majority of the time as it is tricky and needs lot of debugging. The goal of the today's activity was to make sure that sender (which in this case is FPGA) does not miss packets or drop packets. For example, if FPGA is configured to send 102 packets ( which is sending 34 lines of 720p frame where each line is 1280 pixels and each line is sent as 3 packets ), it sends all the packets in a sequence starting from 0 to 101 without missing any packet from 0 to 101. The reason 102 packets were chosen because receiver PC randomly misses a few of the packets from 102 packets. This was confirmed by Wireshark. Every time, FPGA sends 102 packets, the receiver PC randomly drops 4 to 6 packets from 102 packets. If the number of packets sent from the transmitter FPGA are increased, then receiver drops more packets and these are random every time transmitter sends packets.

So before blaming the receiver for packet drop, it is good to check the transmitter. As mentioned above, i went through the chain of simulation. Please refer to the original proposal where i highlighted the importance of simulation on Pages 10 and 11. Simulation is done after each step of Xilinx Build flow as show in the Figure below.

 

Here are the snapshots that show RTL, post-synthesis, post-translate, post-map and post-pnr simulations. Post-pnr simulation is actually done with SDF delay annotation. All these simulations show that packets went from sequence number 0 to 101











Then after this came the step of verifying with Xilinx Chipscope, which took the whole day. Here are sequence of shots that show sequence number going from 0 to 101. 

















After verifying through simulation chain and emulation using Chipscope, we are confident that transmitter is not dropping or missing packets.

Now we either need to slow down the transmitter or make sure receiver is fast enough to capture the transmitter. This is the aim for the rest of the week.

Please share your feedback

Thanks! 





1 comment:

  1. In the chipscope screenshots, what are we looking at? Where is "seqn" being probed?

    Do you have a feel for rate that is being sent over the line? Do you know if the MAC enforces the inter-packet-gap?

    Good investigations, overall we might find the UDP at high rates (the rates needed to transfer the video) might not be reliable enough. In this case it might be determined the PC is not keeping but in general we might find that the % of bandwidth that can be used to transfer 99% of the packets is lower than first expected.

    ReplyDelete