calculate (and validate) ethernet FCS (crc32) in v

问题:

I'm using the Spartan 3E Starter Kit and I'm trying to receive Ethernet frames on it via a 100 MBit link.

For those who don't know, the board features a PHY chip, exposing the receiving clock with 25 MHz. I have (pretty much) verified that receiving works fine by buffering the received frames and resending them via a serial link.

Furthermore, I'm using a CRC32 generator from outputlogic.com. I aggregate the received nybbles to bytes and forward them to the CRC. At the end of the frame, I latch the generated CRC and display it on the LCD, together with the CRC I found in the ethernet frame.

However, (as you might have guessed) the two numbers do not match.

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

The first one can also be verified by running the package through pythons crc32 function, both with the frame captured by wireshark and the frame captured and retrieved via serial port from the FPGA.

I guess it must be something more or less trivial. I pasted the receiving process over here. I stripped off everything which was not neccessary. When capturing the output via serial, I added a fifo (readily made unit from Xilinx) which latched at the same time as the CRC generator to get exactly the same bytes.

Does anyone have an idea what's wrong with that?

回答1:

I started working on an ethernet MAC a while back, and although I never got round to finishing it I do have a working CRC generator that you can use here:

CRC.vhd

Its based on a Xilinx App note on the IEEE 802.3 CRC, which you can find here.

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.

回答2:

The generator you used may not be pre-processing and post-processing the data. If that generator takes a string of zeros and produces a zero crc, then that's the problem. A string of zeros should not produce zero. (What it produces depends on the number of zeros.)

The processing for the Ethernet crc is to invert the crc, then apply the crc algorithm, then invert the crc again.