三速以太网IP核接收路径的用户侧少了一个字节

[yzhan286]

我在使用intel三速以太网IP核时，按照用户手册编写了MAC的配置模块，UDP发送模块和UDP接收模块，目前的发送模块已经测试成功，但是接收模块出现了问题，就是接收模块在对MAC的用户侧(ff_rx_data)数据解析时不成功，为了分析原因，用quartus II中的SignalTap抓取SignalTap抓取ff_rx_data信号，发现数据包的头部少了一个字节，导致了后面所有的数据错位。​使用的100M模式，MAC选项只勾选了Align packet headers

to 32-bit boundary其余的均没有使用，FIFO选项：TX和RX均使用的是1024*32bit。请教一下是我的配置有什么问题吗，怎么改就一直是这种现象

[Deshi_Intel]

Hi,

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

[yzhan286]

非常感谢您的回复！

我把我的问题详细描述一下，就是我用电脑的网络调试工具向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，不知我现在是否已经描述清楚，方框中的数据是出现错误的地方，麻烦您再帮我指教一下，谢谢您！

[yzhan286]

非常感谢您的回复！

我把我的问题详细描述一下，就是我用电脑的网络调试工具向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，不知我现在是否已经描述清楚，方框中的数据是出现错误的地方，麻烦您再帮我指教一下，谢谢您！

[yzhan286]

非常感谢您的回复！ 我把我的问题详细描述一下，就是我用电脑的网络调试工具向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，不知我现在是否已经描述清楚，方框中的数据是出现错误的地方，麻烦您再帮我指教一下，谢谢您！

[Deshi_Intel]

Hi,

Thanks. I understand your problem statement now.

• You are sending broadcast address FF:FF:FF FF:FF:FF
• But Signal_Tap only captured FF:FF:FF FF:FF, looks like last 2 bytes of FF is missing

Couple debug suggestion

1. Align packet headers to 32-bit boundary is enabled
2. Align packet headers to 32-bit boundary is disabled
3. Have you enabled TSE IP statistic counter option and read on register (Dword Offset 0x18 – 0x38) to check on potential error ?
4. Did you also monitor TSE IP "status LED signals" to check for potential error ?
5. Do you observed TSE RX FIFO underflow or overflow issue ?
6. Do you still see similar issue when sending unicast address instead of broadcast address ?
7. Do you still see similar issue when sending TCP/IP instead of UDP packet ?
8. Lastly, would you be able to perform TSE IP internal loopback testing to isolate external factor issue ?

• ff_tx -> TSE MAC -> ff_rx

Thanks.

Regards,

dlim

[yzhan286]

您好！

再次感谢您的回复，我在您给的建议下做了如下的测试：

1.使用了本地回环模式即TX->TSE MAC->RX，这个现象依然存在，FIFO端口用的32bit

2.在FIFO宽度设置为8bit的模式下使用本地回环，依然还有这种现象。

3.没有发单播数据报和TCP/IP报，因为我的调试软件在没有知道TSE MAC的MAC地址时不能发送单播报文。

4.FIFO用32bit，不采用​Align packet headers to 32-bit boundary ，也有这种现象。

我把我的工程发给您一下。

软件版本是Quartus II13.0 SP1(64bit)​

再次非常感谢​

[Deshi_Intel]

HI,

Sorry, I sent the message without completing below update.

Couple debug suggestion

1. Align packet headers to 32-bit boundary is enabled

• Did you configure register "tx_cmd_stat" and "rx_cmd_stat" correctly as your earlier screen shot shown "comment out" ?

1. Align packet headers to 32-bit boundary is disabled

• Just for debug purpose to see if it helps

Thanks.

Regards,

dlim

[Deshi_Intel]

HI,

Sorry for the late reply. I have some questions after reviewing your design.

I ahve

Thanks.

Regards,

dlim

[Deshi_Intel]

HI,

Sorry, I meant I have sent you private message.

Thanks.

Regards,

dlim

[Deshi_Intel]

HI,

I haven't hear back from you in the private message.

Do you had an chance to review my comment in the private message ?

Thanks.

Regards,

dlim

[yzhan286]

你好！

我很抱歉没有及时回复您的邮件！

由于前段时间网络的原因，导致我没有登录进支持社区，所以后面就一直没有回复。

现在我的项目接收路径没有用TSE MAC，我自己写了模块对PHY的数据进行解析，可以实现我需要的功能了。

等这段时间忙完了再来解决这个问题。

再次非常感谢您！​

[Deshi_Intel]

HI,

No problem. It's good to know you are able to proceed with your project development.

Alright, for now I am setting this case to closure first.

Feel free to file new forum thread if you still face issue in future.

Thanks.

Regards,

dlim