用VHDL语言计算(和验证)以太网现场总线控制器(crc32)

Question

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

对于那些不知道，电路板的特点是物理层芯片，暴露了25 兆赫的接收时钟。我已经(很大程度上)通过缓冲接收到的帧并通过串行链路重新发送它们来验证接收工作正常。

此外，我使用的是CRC32 generator from outputlogic.com。我将接收到的两个字节聚合成字节，并将它们转发给CRC。在帧的末尾，我锁存生成的CRC并将其与我在以太网帧中找到的CRC一起显示在LCD上。

然而，(正如您可能已经猜到的)这两个数字并不匹配。

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

第一个也可以通过pythons crc32函数运行包来验证，包括wireshark捕获的帧和通过串口从现场可编程门阵列捕获和检索的帧。

我猜这一定是某种或多或少微不足道的事情。I pasted the receiving process over here。我把不必要的东西都脱掉了。当通过串口捕获输出时，我添加了一个fifo (来自Xilinx的现成单元)，它与CRC生成器同时锁存，以获得完全相同的字节。

有人知道这是怎么回事吗？

Answer 1

我前段时间开始研究以太网MAC，虽然我一直没有完成它，但我有一个可以工作的CRC生成器，你可以在这里使用：

CRC.vhd

它基于Xilinx App note on IEEE 802.3 CRC，你可以找到here。

CRC是在ethernet receieve component中实例化的，如果您查看ETH_RECEIVE_SM进程，您可以看到FCS是如何加载到检查器中的。

希望您可以通过与我的代码进行比较来发现您的错误。

编辑：

我从fpga4fun获取了样本以太网帧，并将其通过CRC校验器，请参见下面的模拟屏幕截图(右键单击，复制网址并在新的浏览器选项卡中查看完整分辨率)：

​

​

你可以在最后看到剩余的C704DD7B，试着用你自己的CRC校验器做同样的事情，看看你得到了什么。

Answer 2

您使用的生成器可能没有对数据进行预处理和后处理。如果生成器获取一个0字符串并生成一个零crc，那么这就是问题所在。一串零不应该产生零。(它生成的内容取决于零的数量。)

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