Hy all, I'm currently implementing a receiver (vhdl) part of the ethernet mac which is responsible for the MII interafce. I'm need an crc32 calculator (RTL) to check the FCS field. I've tried using the easics crctoll in order to create the mechanism (for a 4 bit data input) but it does not seems to work. does anyone have a working (rtl) vhdl implementation for this block? or at least a detailed expalnation on how to create it..? Thanks in advance, Moti.
I'd be willing to bet that your problem is bit ordering (hint: take an 8 bit chunk and reverse the order of the bits before throwing it into the easics checker). Although I'm sure there is probably a way, I don't quickly see how you'd do it four bits at a time.
Hi Marc, Thanks for your answer so first of all I have already tried revesring the bits order without any success - I read something about a "magic number" but I'm not sure what to do with it. regarding the 4 bit data path - the easics "crctoll" can generate a vhdl file for 1,2,4,8...64 bits so its not the problem..
I have done a CRC32 with 16bit parallel input using easics and it took me loads of time to figure out that it was working perfectly from the beginning.! Speaking with more people, I found out that most of them had similar problems verifying the outcome.
My advice is to sit down and find a methodical way to test it.
formatting link
using this calculator and putting the settings CRC order (1..64) : 32
CRC polynom (hex) :4C11DB7
Initial value (hex) :FFFFFFFF
Final XOR value (hex) : 0
direct : checked
and the rest of options: unchecked
worked for me at least.
Check this link too, it has one more crc_gen, (I haven't used it myself though).
Did you use the correct reset value for the CRC (usaly 0xFFFFFFFF)? I thing that the checksum that is included in the Ethernet packet is the complement of thr CRC result, i.e. checksum = not CRC.
Is this magic number (residual) given by all CRCs? I have experienced that the USB CRC5/CRC16 have residuals which are for all correct calculations the same. But what about other CRCs?
I want to use a CRC16 with the polynomial 0XBAAD (paper "Cyclic Redendany Code Poynomial Selection for Embedded Networks" Philip Koopman).
But when I simulate it (VHDL code generated by CRC TOOL) and initialize it with '1's than I do not get a residual when trying different data to calculate. So maybe there has to be used a different initial value. But how do I get to know which one to use as initial value?
We're pretty far off topic here, but I'll give it one last stab while presenting some links that might be useful for the FPGA crowd... I found a neat tool on the web:
formatting link
which lets you play with various things. You might be able to feed your simulated data into this tool and see if things match up. Using this tool, I was able to get the residual (MAGIC NUMBER) by clicking "nondirect" then clicking "Convert"... The initial value field will turn into the residual (or bit flipped residue, depending on the CRC implementation).
IE, for CRC-32, clicking nondirect and convert results in C704DD7B and CRC-CCITT results in 1D0F. Using the same procedure for Koopman's new polynomial 0xBAAD results in a possible residue of 3BE9 when calculated in the same way a CRC-CCITT (initial value of FFFF with no bit flipping or reversing).
Various links to HDL code:
formatting link
formatting link
formatting link
Lastly, make sure you are feeding the whole received data block into the CRC checker (including the received CRC). If you can't use the tool above to verify your values, you could use a C program.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.