用vhdl计算（并验证）以太网FCS（crc32）

我正在使用，我正在尝试通过100接收以太网帧 MBit链接

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

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

然而，（正如你可能猜到的）这两个数字不匹配

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

还可以通过pythons crc32函数运行包来验证第一个功能，该功能包括wireshark捕获的帧和通过FPGA串行端口捕获和检索的帧

我想这一定是件小事。我把不必要的东西都脱光了。当通过串行捕获输出时，我添加了一个fifo（Xilinx现成的单元），它与CRC生成器同时锁存，以获得完全相同的字节

---

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

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

---

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

我不久前开始使用以太网MAC，尽管我从未抽出时间来完成它，但我有一个可以在这里使用的工作crc生成器：

它基于IEEE 802.3 CRC上的Xilinx应用程序说明，您可以找到

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

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

编辑：

我从中获取了以太网帧示例，并将其通过CRC检查器，请参见下面的模拟屏幕截图（右键单击，复制URL并在新的浏览器选项卡中查看以获得完全分辨率）：

---

您可以在最后看到残差C704DD7B，尝试使用您自己的CRC检查器执行同样的操作，然后查看您得到的结果。

非常感谢您提供的代码，它看起来非常有用，并且有很好的文档记录。没问题，如果您需要任何解释，请告诉我。我不确定ETH_接收SM过程中的

s_fcs_crc_calc_en

信号的状态-它被设置为高，但之后从未设置为低。它是否在下一个时钟自动设置为低？就我所见，这将导致

s_fcs_crc_calc_en

和

s_fcs_crc_d_valid

永远不会同时变高。不过，如果我在PDF中获得正确的文档，这似乎是正常的行为，因为在同一时间断言这两个值应该具有相同的效果，就像它们在不同的时间被断言一样。Hm。虽然您的回答很有帮助，我认为它起了作用，但我仍然没有得到正确的结果（即，在通过crc对整个框架进行管道连接后，我没有得到剩余的结果）。你有什么我可以注意的其他提示吗？为了记录在案，CRC32发生器的输出逻辑输入中的

数据必须反转，以便在
crc\u输出中生成正确的以太网FCS。