vhdl - 在 vhdl 中计算（并验证）以太网 FCS (crc32)

Question

我正在使用Spartan 3E Starter Kit，并尝试通过 100 MBit 链路接收以太网帧。

对于那些不知道的人，该板具有一个 PHY 芯片，将接收时钟暴露在 25 MHz。我已经（几乎）通过缓冲接收到的帧并通过串行链路重新发送它们来验证接收工作正常。

此外，我正在使用outputlogic.com 的 CRC32 生成器。我将接收到的 nybbles 聚合为字节并将它们转发给 CRC。在帧结束时，我锁存生成的 CRC 并将其与我在以太网帧中找到的 CRC 一起显示在 LCD 上。

但是，（正如您可能已经猜到的）这两个数字不匹配。

527edb0d  -- FCS extracted from the frame
43a4d833  -- calculated using the CRC32 generator

第一个也可以通过 pythons crc32 函数运行包来验证，包括由wireshark捕获的帧和通过串行端口从FPGA捕获和检索的帧。

我想它一定或多或少是微不足道的。我把接收过程贴在这里。我剥离了所有不必要的东西。通过串行捕获输出时，我添加了一个 fifo（赛灵思现成的单元），它与 CRC 生成器同时锁存以获得完全相同的字节。

有谁知道这有什么问题？

Answer 1

不久前我开始研究以太网 MAC，虽然我从来没有完成它，但我确实有一个工作的 CRC 生成器，你可以在这里使用它：

CRC.vhd

它基于关于 IEEE 802.3 CRC 的 Xilinx 应用说明，您可以在此处找到。

The CRC is instantiated in the ethernet receieve component, if you look at the ETH_RECEIVE_SM process you can see how the FCS is loaded into the checker.

Hopefully you can spot your mistake by comparing with my code.

Edit:

I took the sample ethernet frame from fpga4fun and passed it through the CRC checker, see the simulation screenshot below (right click, copy URL and view in a new browser tab for full resolution):

You can see the residual C704DD7B at the end there, try doing the same with your own CRC checker and see what you get.

Answer 2

您使用的生成器可能没有对数据进行预处理和后处理。如果该生成器采用一串零并产生零 crc，那么这就是问题所在。一串零不应产生零。（它产生的结果取决于零的数量。）

以太网 crc 的处理是将 crc 反转，然后应用 crc 算法，然后再次反转 crc。