FPGARelated.com
Forums

crc32 vhdl implementation (4 bit data)

Started by Moti Cohen July 4, 2004
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.
Moti Cohen wrote:
> 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..?
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
moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0407040651.2199a09f@posting.google.com>...
> 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.
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.
Marc Randolph <mrand@my-deja.com> wrote in message news:<u4ednTCBZ4B5q3XdRVn-vA@comcast.com>...
> Moti Cohen wrote: > > 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..? > > 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 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..
"Moti Cohen" <moti@terasync.net> wrote in message
news:c04bfe33.0407040651.2199a09f@posting.google.com...
> 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.
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. http://rcswww.urz.tu-dresden.de/~sr21/crc.html 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). http://www.ee.ualberta.ca/~elliott/ee552/studentAppNotes/1998f/ethernet/ethernet.html#vhdl
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:
> moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0407040651.2199a09f@posting.google.com>... > >>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. > > > 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.
-- ------ Patrik Eriksson
Moti Cohen wrote:

> Marc Randolph <mrand@my-deja.com> wrote in message news:<u4ednTCBZ4B5q3XdRVn-vA@comcast.com>... > >>Moti Cohen wrote: >> >>>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..? >> >> >> 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..
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) <= bit(7), bit(4) <= bit(3), etc. If you only have four bits, you can't very well bit reverse 0 to 7. We have used the 8 bit, 16 bit, and 32 bit easics code and they all work fine (after you figure out the right bit order and such). There are two ways to verify a CRC. One is to compute the check CRC on everything up to, but not including, the received CRC. Then do a compare between the two CRC's. The second way is to include the received CRC in the calculation for the check CRC. If you do this, the result is the magic number (assuming the checker was initialized with all 1's). Good luck, Marc
> The second way is to include the > received CRC in the calculation for the check CRC. If you do this, the > result is the magic number (assuming the checker was initialized with > all 1's).
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
ALuPin@web.de (ALuPin) wrote in message news:<b8a9a7b0.0407052258.6f1be41f@posting.google.com>...
> > The second way is to include the > > received CRC in the calculation for the check CRC. If you do this, the > > result is the magic number (assuming the checker was initialized with > > all 1's). > > 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?
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
> 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