以太网传输图片工程出现的问题总结(含源码)

  基于FPGA的DDR相关知识导航界面，点击查看。

  基于FPGA的以太网相关文章导航，点击查看。

---

  本文对以太网传输图片的工程曾经出现过的问题及解决思路进行整理，便于日后出现类似问题能够快速处理。也指出为什么前文在FIFO IP设计时为啥强调深度的重要性。

1、问题

  当工程综合完毕之后，下载到板子，连接以太网口，相关硬件如下所示：

图1 硬件平台

  PC向开发板发送ARP请求和回显请求，通过Wireshark软件都能抓取开发板的应答数据报文，证明以太网链路畅通。

图2 arp请求和回显请求

  之后通过网络调试助手向开发板传输图片数据，当图片传输完毕后，显示器上显示的界面如下图所示。

图3 显示器显示图片

  为了对比，下图是显示器需要显示的图片，上图中部分左侧的像素显示在了显示器的右边。

图4 显示器需要显示的图片

2、分析

  由于上位机是将一张图片的像素数据依次传输给开发板的，每行像素并没有其实标志，只能通过像素的个数来判断像素位于哪一行。上位机是别人开发一直在用的，应该不会出问题，那么应该就只会存在一种问题，会导致这种结果。

  在FPGA接收上位机的数据后，像素显示在显示器上之前，应该是丢失了部分像素，导致剩下第一行的像素数据不足以在显示器第一行显示，就取了第二行部分数据显示在第一行的后侧，然后第二行取了第三行的部分像素，最终导致最左侧的画面显示在了显示器最右侧。

  现在问题在于，确定那段程序出现问题，导致数据丢失。首先可以使用Wireshark软件抓取上位机传输的图像数据，然后通过ILA抓取开发板接收的上位机图像数据，对比数据是否一致。

  之后进一步使用ILA抓取从写FIFO存入DDR3的MIG IP的数据是否正确，以及MIG IP输出的读取DDR3的数据是否正确，如果前面均没有问题，那么就需要抓取读FIFO输出的数据是否与以太网接收的数据一致，进而排查每个阶段的数据正确性，从而定位到问题的具体位置。

3、实际调试

  首先将工程中的ila0和ila1注释打开，抓取以太网接收并且存入DDR3读写控制模块的写FIFO的相关信号，ila1抓取读、写MIG IP的相关信号，进而确认以太网接收和写DDR3、读DDR3过程中是否出现问题，之所以不将ila2注释打开是因为资源不够。

  然后打开wireshark软件，运行ila，网口调试助手发送数据，之后抓取开头数据进行分析即可。Wireshark为了方便查看发给开发板的数据报文，建议使用ip.addr == 192.168.1.10对报文进行筛选，结果如下：

图5 wireshark抓取报文

  由于采用巨型帧传输的UDP报文，长度为8192字节，每个报文是显示器4行的图像数据。开头数据为128’h4438_4438_3c38_33f6_2bb6_2bd6_33f7_33f6。

图6 Wireshark抓取数据

  然后查看第一帧最后的128位数据为128’h0294_0294_0294_0294_0294_0294_0274_0273，前文分析过，这个问题是因为后面的行最后几个数据用来下一行前几个数据导致的，如果程序出现问题，那么第四行的最后几个数据肯定不是上述这128位像素数据。

图7 Wireshark抓取数据

  下图是ILA0抓取的第一帧数据的开始部分，紫色信号是开发板以太网接收模块输出的数据，与图5的开始部分一致，没有问题。橙色信号是将以太网的8位数据拼接为16位数据存入DDR3的写FIFO中，依次存入的数据为16’h4438、16’h 4438、16’h 3c38、16’h 33f6、16’h 2bb6、16’h 2bd6、16’h 33f7、16’h 33f6，也没有问题。

图8 以太网接收模块第一帧开始数据

  下图是抓取的第一帧数据结束位置的时序，与图6发出的数据依旧一致，结尾最后128位数据依次是16’h 0294、16’h 0294、16’h 0294、16’h 0294、16’h 0294、16’h 029、16’h 0274、16’h 0273。证明以太网接收到存入DDR3写FIFO中的数据是没有问题的。

图9 以太网接收模块第一帧结束数据

  然后需要确认写入DDR3中和读出DDR3的数据是否有问题，首先ILA1抓取写入DDR3第一行图像数据的开始时序如下图所示，写入第一行的开始数据与图5最开始发送的128位数据一致，证明开始写入数据的位置没有问题。

图10 抓取写入DDR3的第一行开始数据

  由于wireshark发送一个报文，显示器需要显示4行，因此这里需要使用ILA抓取第4行的结尾128位数据与wireshark发送第一个报文的最后128位数据进行比较。

  下图蓝色方框的数据就是黄色光标处的数据，与图6最后发送的128位数据保持一致，存入地址为4088的DDR3中。由此证明写入到DDR3的数据也是没有问题的。

图11 抓取写入DDR3的第四行结束数据

  想要抓取从DDR3读出的数据，需要等待以太网发送完一帧数据，才会从DDR3中读出数据进行显示。之后需要利用一下读FIFO复位指示信号，抓取复位之后的一段数据，就可以抓取从DDR3中读出的第一行数据。

  如下图所示，当一帧图像开始显示时，会先复位读FIFO，读FIFO复位完成之后，从DDR3起始地址读出数据存入读FIFO中。DDR3读数据会滞后读指令一段时间，如下图蓝色方框所示，显示从DDR3地址0读出的数据，与图5上位机起始发送的128位数据一致。

图12 抓取读出DDR3的第一行开始数据

  由于DDR3输出数据会滞后读指令一段时间，就导致状态机在发送完读指令后，回到空闲状态，由于DDR3中一行数据还未全部数据，读FIFO中的数据小于一行数据个数，此时状态机会继续跳转到读状态，在从DDR3中读取一行数据，抓取的时序图会显示FIFO复位之后，会连续读取2行数据到FIFO中。

图13 读FIFO复位后连续两次读

  这个逻辑起始没法避免，这是因为DDR3本身硬件决定的，避免的方法可能有两种，一种把读FIFO中存储数据的阈值减小，另一种就是对读出的数据个数进行计数，直到读数据与读指令个数一致时，才判断读FIFO数据个数是否达到指定数据。但是这两种逻辑就会使程序复杂，另一种方式就是增加FIFO容量，使FIFO能够存下两行数据，这是为什么最开始将FIFO深度设置为2048的原因。

图14 状态机跳转

  然后通过调节HDMI刷新第2行数据时，查看DDR3输出的第四行结尾数据与上位机图6发送的结尾数据是否一致，如果一致，则说明读DDR3的时序也是没有问题的。

  下图蓝色方框的数据就是红色方框DDR3地址读出的数据，与图6结尾发送的128位数据一致，由此证明从以太网接收数据，然后将数据存入DDR3，最后读出DDR3数据的整个过程都是没有问题的。

图15 抓取读出DDR3的第四行结束数据

  之后将ila0和ila1注释掉，打开ila2的注释，抓取读FIFO读侧相关信号，查看读出的数据是否一致。

  首先第一行数据显示时的从FIFO读取数据的时序，如下图所示，开始读出的128位数据与图5上位机发送的128位数据还是一致的，证明刷新的起始位置并没有问题。

图16 刷新第零行从读FIFO读出8字节数据

  然后抓取第3行刷新时结尾的128位数据，如下图所示，明显红色方框的数据才是图6中上位机第一帧结尾的数据，而紫红色的8字节数据更像是一行数据的起始数据。

图17 刷新第三行从读FIFO读出8字节数据

  由此证明是读FIFO有问题，写入读FIFO的4行数据没有问题，但是读出的四行数据时，最后一行数据缺少了8字节数据，可能是FIFO溢出导致的。

  一行数据包含1024个像素点，而读FIFO深度设为2048，即使FIFO复位后会马上存入两行数据到读FIFO中，也不会导致FIFO溢出吧。

  然后回到图14，最开始读FIFO应该存入两行数据，但是图16开始时，读FIFO中却只有2038个数据，并不是2046个数据，因此确定是FIFO溢出了。

图18 开始读FIFO数据时FIFO中的数据

  在回到FIFO配置界面，发现将深度设置为2048时，该FIFO只能存储2040个数据，会丢失8个数据，这就与图15抓到缺少8字节数据的结果对上了。

图19 FIFO实际深度

  之后将FIFO深度改为4096，然后将FIFO深度相关信号位宽进行修改，顶层位宽修改为9位，之后重新综合就解决问题了。再次传输图像数据进行显示的结果如下，问题得到解决。

图20 显示图片

4、总结

  结果就是因为FIFO深度设置问题，没有关注FIFO实际深度，最后导致这种问题的出现。但是整个调试思路没有任何问题，适用于所有的工程。

  遇到问题之后，首先应该仔细分析出现这种现象可能出现的原因，然后去通过上位机辅助软件和ILA等在线调试工具去抓取开发板的关键信号，从而排除或者确定猜想，最后定位到问题根本原因，解决并总结问题，避免下次设计时在出现类似问题就行了。

  最后需要本次工程文件在公众号后台回复“FIFO深度问题”（不包括引号），即可获取该工程文件，便于复现。

---

  如果对文章内容理解有疑惑或者对代码不理解，可以在评论区或者后台留言，看到后均会回复！

  如果本文对您有帮助，还请多多点赞👍、评论💬和收藏⭐！您的支持是我更新的最大动力！将持续更新工程！