Forum Discussion
yzhan286
New Contributor
New Contributor三速以太网IP核接收路径的用户侧少了一个字节
我在使用intel三速以太网IP核时，按照用户手册编写了MAC的配置模块，UDP发送模块和UDP接收模块，目前的发送模块已经测试成功，但是接收模块出现了问题，就是接收模块在对MAC的用户侧(ff_rx_data)数据解析时不成功，为了分析原因，用quartus II中的SignalTap抓取SignalTap抓取ff_rx_data信号，发现数据包的头部少了一个字节，导致了后面所有的数据错位。 ...
Deshi_Intel
Regular Contributor
Regular ContributorHi,
Can you elaborate further on your problem statement "header of the data packet was one byte less" ?
- Is your payload data corrupted ?
- Or payload data shifted with extra zero padding bits ?
- It would be best if you can circle or highlight the problematic data in your signal_tap result
As for the TSE IP MAC option with "Align packet headers to 32-bit boundaries" enabled.
- TSE MAC IP will auto pad extra 2 bytes of zero data at the beginning of Ethernet Frame.
- Looking at your signal tap result with starting received data of 0000FFFFh. This looks correct and expected result. Correct me if I am wrong.
- You can refer to TSE user guide doc (page 43, chapter 4.1.4.9. IP Payload Alignment) for more detail
- https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_ethernet.pdf
You can always disable the ""Align packet headers to 32-bit boundaries" if it affect your data result alignment.
Thanks.
Regards,
dlim
yzhan286New Contributor
New Contributor非常感谢您的回复！
我把我的问题详细描述一下，就是我用电脑的网络调试工具向FPGA发送一个UDP数据包，以广播的方式发送，MAC接收路径的用户侧应该接收到这样的数据 0000FFFF FFFFFFFF 000EC6C2 5DE00080 + 有效数据载荷。
使能了Align packet headers to 32-bit boundary，所以前面添加了两字节的0，紧跟着的6个字节是目的MAC地址（广播帧：6字节的ff），在跟着的是源MAC地址也就是电脑网卡的地址和协议类型（ip协议0800）。
出现问题的地方就是在目的mac地址得到这6个字节，从singaltap抓取到的数据来看是少了一个字节的ff，不知我现在是否已经描述清楚，方框中的数据是出现错误的地方，麻烦您再帮我指教一下，谢谢您！
