书接上篇。
这篇我们主要抓图一下,展示整个上篇开头所描述的过程。写这篇文字的时候代码已经全部调试通过了,这里只是抓图分析和展示。
上图,红色框内第一条:板子要给192.168.3.11发送UDP包,但是不知道其物理地址(MAC地址),就在发送物理地址48个1的局域网ARP广播请求。
红色框内第2条,电脑主机收到这个广播,对比IP是自己的IP,就回复了你要找的192.168.3.11的物理地址是 00.1b...58.
红色框内第3条,板子将32个字节组装成UDP包发给PC。从时间上看,就是PC机发从ARP_REPLY的50uS内,就收到了板子发来的UDP协议。
红色框内第4条,以后每间隔两秒就是收到板子发来的UDP包,这是板子设置的自动发送程序。从上图看,宏观的实验是成功的。
----------------------------
再看看我们发送的以太网数据包。这里电脑只给板子发了一个ARP_REPLY数据包,我们在电脑段用WIRESHRK抓出来,在板子段用内置的逻辑分析仪抓出来,对比一下。
WIRESHARK显示的数据包内容如下:
而实际从RTL8211EG芯片抓到的数据显示如下:
上图我们看到PHY芯片发出的DV(Data Valid)指示的有效数据中并没有包含前导码和起始字节。
我们看到截至上图箭头处是没有错误的。 接着往下看觉得有点不对劲了:
这里我们看到明显多了8个字节。我在想应该是芯片的某些寄存器要设置一下能去掉这个8个字节。这里我们可以简单的模块,在数据包尾部,将DV提前8个周期。
因为我们之前写的VERILOG协议栈在解析ARP数据包时从数据包开头顺序提取信息之后将多余的字节当作校验,同时也暂时没有进行FCS的校验,所以这里是可以兼容这个包的,我们暂时处理(稍后我写代码处理下),继续往下截图。
--------------------------
接下来查看发送给以太网的UDP数据包是否正确:我们发送段设置一个计数器,发送0-31数字,在WIRESHARK里面看到了这31个数字没有问题。
下图框内看到32个字节没错。这里看到UDP的CHECK SUM没有被比对(写任何数值都一样),这就有点没劲了:我们在生成UDP的CHECK SUM 时候,因为CHKSUM在头部,而要得到CHKSUM遍历整个UDP包文,所以用RAM块缓冲,消耗硬件资源不说处理起来多了很大延迟,接收方却不领情,直接忽略。这个问题需要继续看看,有没有别的选项或者别的系统设置可以用上这个checksum,如果都用不上,则可以考虑修改代码,不要费力不讨好...
--------------------------------------
我我们看到上述MAC层报文是大于64字节的,没用用到填充,这样就无法覆盖我们MAC_TX代码中填充部分的覆盖。
我们直接设置把下面代码的TEST_LEN设置为4,发送的UDP字节数为4,
编译运行后再抓包看看:
看到确实填充到了64字节,是用0填充的,这是习惯的做法。我们换成别的数值玩玩看看?
这里用'H88填充试试,
实验OK,这说明我们写全栈代码能控制每个细节,还是很有成就感的。但是实际的应用中大家还是不要标新立异,随大流用00填充。
--------------------------------------------------------------
在空闲期间,PC尝试对FPGA板子的物理地址发送ARP请求,FPGA板子毫不示弱不卑不亢有理有据字正腔圆斩钉截铁地做了回复,如下图。
不知道PC这是什么操作,明明在和FPGA板子通讯说明ARP表里面有了板子IP地址对应的物理地址,还要发起ARP地址转换请求,并且还不是广播的形式发出,非要指名道姓让FPGA板子回复(IP和物理地址都指向板子)。
这里看到ETHENET 层显示黄色,点进去看应该是咱们自己编写的MAC地址 A1....A6不合规,这小事不必在意。