千兆UDP学习调试记录（四）
20181009 周二
继续分析源代码，CRC已经说过了，现在来看IP_Receive模块。通过对发送模块的全面、细致解析，再对现在的接收模块进行分析，应该会轻松很多了吧。哈哈。
补充：程序是直接用一个总的流程状态实现的，相比于一般的三段式状态机，各有什么优点呢？
可以尝试把程序写成三段式状态机来实现。
△Iprecieve模块，GMII UDP数据包发送模块。
上一节已经全部梳理了整个以太网传输协议及过程，因此此节不再赘述，下面开始梳理IP（以太网）接收模块的程序源码。
接收过程就是挨着IP帧的格式，顺序接收便OK。8bit位宽的数据进来，按要求组合成32bit位宽数据，并取出首部信息。
到此，就分析完了整个UDP测试模块，下一步的要求，就是用自己的方式实现该UDP协议传输。有几点要求如下：
- 以位宽为8bit的RAM来存数据，不用32bit的RAM；
- 尽量考虑模块的通用性，实用性，拓展性，模块化，为后续工作做好准备；
- 做好测试记录，磨刀不误砍柴工，一定要扎实基础；
- 尽快实现，不要陷到细节里，要站在全局来实现。
流程和发送模块类似，在此不再赘述。
千兆UDP学习之测试记录
20181008-10 经上述章节设计的程序，依次进行，并总结了如下测试。
测试一：针对广播模式进行测试。广播形式的协议设置如下。
第一次测试，连接成功，很顺利。。。
数据抓取正常。
但是回环测试错误，FPGA未能接收调试助手发送的UDP数据！——也就是说，现在的情况是，FPGA的地址不明确，地址未正确解析。
分析：这次的测试结果奇怪，没有出现预想的“广播不到”的情况，调试助手接收到FPGA来的广播地址请求，并且FPGA端发送UDP数据正常，反而是FPGA端未能接收UDP数据，没有“应答”到自己的地址。
测试二：这次测试，就出现了预计的问题，PC端（调试助手）未能解析到FPGA端的广播连接。但是能回显到PC端……
测试三：把向GMII的25M时钟线去掉，如下设置。
因为使用的千兆模式，25M未使用，所以在程序中尝试去掉，然后进行了测试。出现和“测试一”完全一样的情况。
接下来，换成指定PC端MAC地址，再次进行测试。
预计情况，这样应该能解决上述出现的两个“交叉”问题。猜测原因，是因为使用的自动协商，所在PHY芯片没有“正确”工作。
结果：预测失败，结果还是PC端能接收UDP数据，但是不能回显。所以，这个25M时钟线还不能去掉，原因为何，还待进一步考察。
一点思考：
如果这样一遇到问题就来记录的话，学习效率太低了。记录是需要的，但不能让记录用去的时间太多了，应该把时间重点放在推进工作进度上。就是说，遇到问题，不要着急记录，而应是先去尝试方法解决，等解决之后，再来记录。这样的记录才是有效记录，才有更高的参考价值。
测试四：不知为何原因，直接下原装的程序，但是还是一样的结果……所以这就纳闷了。
问题1：电脑居然不能绑定IP了，奇怪，问题如下。
解决办法，见 https://jingyan.baidu.com/article/cb5d61052f45db005c2fe007.html
主要用一下命令：
1、使用 arp -a 命令 查看网关的MAC网卡物理地址
2、使用 netsh i i show in 命令 查看 本地连接的idx编号
3、使用 netsh -c "i i" add neighbors 本地连接的idx “网关IP” “网关mac” 命令绑定
|
netsh -c “i i” add neighbors 11 “192.168.0.2” "00-0a-35-01-fe-c0” |
同理，在Win7上用arp -d并不能完全的删除绑定，必须使用netsh -c "i i" delete neighbors IDX(IDX改为相应的数字)才可删除MAC地址绑定。
该问题解决后，如下。
绑定IP之后，再次下载程序进行测试，现在就没问题了。哎，绕了这么大一圈。
完整正确的测试结果，应如下图所示。为保证测试方便，固化该FPGA程序。
经过上面的“波折”，总结如下的UDP测试流程经验。
- 修改本机PC端的IP等：192.168.0.3
- 绑定本机的静态地址，即把FPGA端的地址加上：
arp -a
netsh -c "i i" add neighbors 11 "192.168.0.2" "00-0a-35-01-fe-c0"
- 下载UDP程序，让两端程序准备好。
- 打开调试助手、Wireshark软件进行测试验证。
PS：有兴趣的朋友，欢迎留言，交流，本人扣扣1021100382 ~