crc32 vhdl implementation (4 bit data)

Howdy 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.

Good luck,

Marc

Hi,

I've developped, for my personnal needs, a crc software. I've took for inputs : g(x)=x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7

• x5 + x4 + x2 + x + 1 and 4 bits bus. The results are :

-- x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7

• x^5 + x^4 + x^2 + x^1 + 1 function fcrc(DIN : std_logic_vector(3 downto 0); CRC : std_logic_vector(31 downto 0)) return std_logic_vector is variable RESUL : std_logic_vector(31 downto 0); begin RESUL( 0):=CRC(28) xor DIN(0); RESUL( 1):=CRC(28) xor CRC(29) xor DIN(0) xor DIN(1); RESUL( 2):=CRC(28) xor CRC(29) xor CRC(30) xor DIN(0) xor DIN(1) xor DIN(2); RESUL( 3):=CRC(29) xor CRC(30) xor CRC(31) xor DIN(1) xor DIN(2) xor DIN(3); RESUL( 4):=CRC(0) xor CRC(28) xor CRC(30) xor CRC(31) xor DIN(0) xor DIN(2) xor DIN(3); RESUL( 5):=CRC(1) xor CRC(28) xor CRC(29) xor CRC(31) xor DIN(0) xor DIN(1) xor DIN(3); RESUL( 6):=CRC(2) xor CRC(29) xor CRC(30) xor DIN(1) xor DIN(2); RESUL( 7):=CRC(3) xor CRC(28) xor CRC(30) xor CRC(31) xor DIN(0) xor DIN(2) xor DIN(3); RESUL( 8):=CRC(4) xor CRC(28) xor CRC(29) xor CRC(31) xor DIN(0) xor DIN(1) xor DIN(3); RESUL( 9):=CRC(5) xor CRC(29) xor CRC(30) xor DIN(1) xor DIN(2); RESUL(10):=CRC(6) xor CRC(28) xor CRC(30) xor CRC(31) xor DIN(0) xor DIN(2) xor DIN(3); RESUL(11):=CRC(7) xor CRC(28) xor CRC(29) xor CRC(31) xor DIN(0) xor DIN(1) xor DIN(3); RESUL(12):=CRC(8) xor CRC(28) xor CRC(29) xor CRC(30) xor DIN(0) xor DIN(1) xor DIN(2); RESUL(13):=CRC(9) xor CRC(29) xor CRC(30) xor CRC(31) xor DIN(1) xor DIN(2) xor DIN(3); RESUL(14):=CRC(10) xor CRC(30) xor CRC(31) xor DIN(2) xor DIN(3); RESUL(15):=CRC(11) xor CRC(31) xor DIN(3); RESUL(16):=CRC(12) xor CRC(28) xor DIN(0); RESUL(17):=CRC(13) xor CRC(29) xor DIN(1); RESUL(18):=CRC(14) xor CRC(30) xor DIN(2); RESUL(19):=CRC(15) xor CRC(31) xor DIN(3); RESUL(20):=CRC(16); RESUL(21):=CRC(17); RESUL(22):=CRC(18) xor CRC(28) xor DIN(0); RESUL(23):=CRC(19) xor CRC(28) xor CRC(29) xor DIN(0) xor DIN(1); RESUL(24):=CRC(20) xor CRC(29) xor CRC(30) xor DIN(1) xor DIN(2); RESUL(25):=CRC(21) xor CRC(30) xor CRC(31) xor DIN(2) xor DIN(3); RESUL(26):=CRC(22) xor CRC(28) xor CRC(31) xor DIN(0) xor DIN(3); RESUL(27):=CRC(23) xor CRC(29) xor DIN(1); RESUL(28):=CRC(24) xor CRC(30) xor DIN(2); RESUL(29):=CRC(25) xor CRC(31) xor DIN(3); RESUL(30):=CRC(26); RESUL(31):=CRC(27); return RESUL; end fcrc; Tell me (in the news group) if it's ok.

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..

Hi Moti,

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.

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.

/Patrik

st wrote:

Howdy Moti,

I probably could have been clearer on my previous post. I may be wrong, but it is my understanding that the BYTE must be bit-reversed. i.e., bit(0)

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?

Rgds

Yes, all CRC's produce a residual - it is a function of the following items:

• The CRC polynomial being used (CRC-16 vs. CRC-CCITT vs. CRC-32, etc)
• The initial value (sometimes all 1's, but not always)
• Bit and byte ordering (application dependant)
• Bit inversion (application dependant: sometimes XOR with all 1's)

Have fun,

Marc

Hi Marc,

thank you for your answer.

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?

Kind regards

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:

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:

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.

Good luck,

Marc