long package CRC check parallel VHDL

[troy99xx]

hello:

ref : polynomial CRC32 for 802.3 (not pure Ethernet, but uses same polynomial )

Not very familiar with CRC but I have read a lot of information on the web.
I have seen places where you you can use online tools to generate VHDL code base on on particular polynomial and data width.
I am confused how to implement in VHDL a running CRC check on incoming parallel data.

For example, on a 128Byte field of data I need to implement a CRC checker on a 64-bit parallel bus (meaning those 128Kb are captured 64-bits at the time) . The data frame includes a CRC field.

1) If I use one of those parallel CRC implementations, do I need to feed the 64-bits on each clock cycle into the CRC generator until all 128Kbytes are completed? This is part I am confused, how is the total CRC for 128kbyte package calculated ?

2) If the data is less than 128kb, do I need to fill zeros to get the correct CRC?

3) If anyone can post some VHDL sample code , it be will helpful

I have read all posts in the site related to CRC but I couldn't find the answer

any help is appreciated

thank you

 

[std_match]

1) Yes. Before the CRC calculation starts, you initiate the "working register" with the pattern specified for the CRC. Then you feed one word per clock cycle until all data is processed.

2) In general, you should not fill the last word with zeros, but you must do so if it is done at the transmitting end. For the general solution, you must only process the real message bits. As you discovered, this is a problem when you process the CRC in larger chunks than the data size granularity.
If the data size can differ by 8 bits, you need 8 different versions of the parallel CRC logic: for 8, 16, 24, 32, 40, 48, 56 and 64 bits.
For the last CRC calculation,the version corresponding to the remaining number of bits must be selected.
For all other clock cycles, the 64-bit version is used.

3) Sorry, I have no code I can post now.

The basic operation for CRC is to calculate the remainder of a modulo-2 division. There are several sources of confusion:

- To make it possible to calculate the remainder one bit at a time for a serial stream, the first bit in the data must be treated as the highest bit in the remainder calculation, even if the data is transmitted with the LSB first. This creates confusion about how the deserialized data bits should be connected to a parallel implementation.

- The polynomial (the divisor) must have one bit more than the number of bits in the CRC. The highest bit must be '1' so it is sometimes not specified.

- The initial value in the "working register" is different for different CRC types.

- The final value should sometimes be inverted before it is used as the CRC.

- The bit and byte order of the transmitted CRC may or may not be the same as for the payload.

- Zeros can be appended to the data in the transmitter, they are not transmitted but used in the remainder calculation. If the number of zeros is equal to the CRC size, a simpler CRC check can be used in the receiver.

- The CRC can be be checked in two ways, either by doing the same as the transmitter and compare the CRC or, if the CRC is transmitted last (or is saved) and the transmitter appended zeros for the remainder calculation (as described above), process the the CRC bits as data to get a special value in the "working register" if the received CRC was correct.

 

[troy99xx]

Thank you for your quick response. I am very new to this so I have a lot of questions.

1) Yes. Before the CRC calculation starts, you initiate the "working register" with the pattern specified for the CRC. Then you feed one word per clock cycle until all data is processed.

2) In general, you should not fill the last word with zeros, but you must do so if it is done at the transmitting end. For the general solution, you must only process the real message bits. As you discovered, this is a problem when you process the CRC in larger chunks than the data size granularity.
If the data size can differ by 8 bits, you need 8 different versions of the parallel CRC logic: for 8, 16, 24, 32, 40, 48, 56 and 64 bits.
For the last CRC calculation,the version corresponding to the remaining number of bits must be selected.
For all other clock cycles, the 64-bit version is used.

Are you saying that if there are 8 or 16 or 32 bits of data left to process in the data package, I should use the 8 ,16,32 CRC generator?
So if I calculate the CRC for the previous bytes with the 64 CRC checker and the last 8 bits with the 8 bit checker, how do I combine the 2 CRC values to obtain the total CRC for the data package?

- To make it possible to calculate the remainder one bit at a time for a serial stream, the first bit in the data must be treated as the highest bit in the remainder calculation, even if the data is transmitted with the LSB first. This creates confusion about how the deserialized data bits should be connected to a parallel implementation.

- The polynomial (the divisor) must have one bit more than the number of bits in the CRC. The highest bit must be '1' so it is sometimes not specified.

x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1
Are you talking the +1 term?

How would you connect the deserialized data to the parallel if LSB or MSB fisrt?

- The initial value in the "working register" is different for different CRC types.

I do not know what you mean by working register? Are you referring to the seed? My design will have a seed

- The final value should sometimes be inverted before it is used as the CRC.

How would I know this? I was given the polynomial (above) and the seed. Does the 803.2 spec. define this?

- The bit and byte order of the transmitted CRC may or may not be the same as for the payload.

I will need to check this . Does the 803.2 spec. define this?

- Zeros can be appended to the data in the transmitter, they are not transmitted but used in the remainder calculation. If the number of zeros is equal to the CRC size, a simpler CRC check can be used in the receiver.

I will need to check this. I don't think is done in my case. Does the 803.2 spec. define this?

- The CRC can be be checked in two ways, either by doing the same as the transmitter and compare the CRC or, if the CRC is transmitted last (or is saved) and the transmitter appended zeros for the remainder calculation (as described above), process the the CRC bits as data to get a special value in the "working register" if the received CRC was correct.

The CRC is appended every 128 bytes blocks x 16 in one frame

Again does the 802.3 spec defines if zeros are appended?


Not sure what you mean by "working register"


thank you very much

 

[std_match]

Are you saying that if there are 8 or 16 or 32 bits of data left to process in the data package, I should use the 8 ,16,32 CRC generator?
So if I calculate the CRC for the previous bytes with the 64 CRC checker and the last 8 bits with the 8 bit checker, how do I combine the 2 CRC values to obtain the total CRC for the data package?

The polynomial and the CRC size are always the same. It is only the input data size to the parallel implementation that changes.
In each clock cycle the intermediate result from the previous clock cycle is modified.
When you use a tool to generate a parallel implementation, you specify the input data size and the CRC size individually.
If the last data chunk is smaller, you must switch to another parallel implementation in the last cycle, with the input data size equal to the remaining bits. As I mentioned earlier, the polynomial and the CRC size do not change.

x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1
Are you talking the +1 term?

No, it is x32 that must be '1'

How would you connect the deserialized data to the parallel if LSB or MSB fisrt?

If the protocol+CRC is specified so that the CRC can be calculated one bit at a time, the first received bit should be connected to the MSB of the parallel CRC logic.

I do not know what you mean by working register? Are you referring to the seed? My design will have a seed

It is the register where you will have the final result of the CRC calculation, when all input data has been processed.
It will also hold the intermediate result from one clock cycle to the next.
For a serial implementation, it is the shift register.

How would I know this? I was given the polynomial (above) and the seed. Does the 803.2 spec. define this?

Everything you need is specified somewhere, but it is very difficult to do a correct implementation from a specification only.
You need some "example" packets with a correct CRC. Then you can change the byte order and the bit order until your implementation gives the correct result. Start with a packet that doesn't have a different size in the last "chunk", because that will add one extra dimension to the problem. To handle the odd-sized last chunk, you must switch between different parallel CRC implementations in the last clock cycle.

Again does the 802.3 spec defines if zeros are appended?

I am guessing here.
I don't think the the last chunk is padded with zeros. This means that you need one parallel CRC implementation for each possible size of the last chunk.
I don't think zeros are added to allow for the simplified check. It would not be very useful anyway, since the CRC is not transmitted last.

 

[troy99xx]

Again thank you . this is helping a lot!!

If the last data chunk is smaller, you must switch to another parallel implementation in the last cycle, with the input data size equal to the remaining bits. As I mentioned earlier, the polynomial and the CRC size do not change.

Assuming there are 8 bits left (data[7..0]) to clock in the equations below for the CRC generator
Do you mean that I need to implement in the CRC generator itself controls like byte enables that allow the last bits data[7..0] to be used for the calculation of the new CRC value but bits Data[63..8] keep the same previous intermediate result (meaning the last clock that feeds the generator should not affect the values of bits [63..8] but it should update only data [7..0] for the equations below. If this is incorrect, I do not understand what you mean by " you must switch to another parallel implementation in the last cycle" (example??)

crc_c(0) <= data(0) XOR data(6) XOR data(9) XOR data(10) XOR crc_i(16) XOR crc_i(26) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28);
crc_c(1) <= data(0) XOR data(1) XOR data(7) XOR data(11) XOR crc_i(17) XOR crc_i(27) XOR data(13) XOR crc_i(23) XOR crc_i(29) XOR data(6) XOR data(9) XOR crc_i(16) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28);
crc_c(2) <= data(0) XOR data(1) XOR data(2) XOR data(8) XOR crc_i(18) XOR data(14) XOR crc_i(24) XOR crc_i(30) XOR data(7) XOR crc_i(17) XOR data(13) XOR crc_i(23) XOR crc_i(29) XOR data(6) XOR data(9) XOR crc_i(16) XOR crc_i(25) XOR crc_i(22);
crc_c(3) <= data(1) XOR data(2) XOR data(3) XOR data(9) XOR crc_i(19) XOR data(15) XOR crc_i(25) XOR crc_i(31) XOR data(8) XOR crc_i(18) XOR data(14) XOR crc_i(24) XOR crc_i(30) XOR data(7) XOR data(10) XOR crc_i(17) XOR crc_i(26) XOR crc_i(23);

No, it is x32 that must be '1'

From the implementation point of view, do I need to clock an extra bit or what exactly this mean for the implementation?

I am guessing here.
I don't think the the last chunk is padded with zeros. This means that you need one parallel CRC implementation for each possible size of the last chunk.
I don't think zeros are added to allow for the simplified check. It would not be very useful anyway, since the CRC is not transmitted last.

[/QUOTE]

The data is sent in 16 blocks

BK1Data-CRC,BK2DATA-CRC... etc

Isn't this mean CRC is transmitted last? If it is this way, does it mean they are padding the data or not necessarily?

thanks

 

[std_match]

Assuming there are 8 bits left (data[7..0]) to clock in the equations below for the CRC generator
Do you mean that I need to implement in the CRC generator itself controls like byte enables that allow the last bits data[7..0] to be used for the calculation of the new CRC value but bits Data[63..8] keep the same previous intermediate result (meaning the last clock that feeds the generator should not affect the values of bits [63..8] but it should update only data [7..0] for the equations below. If this is incorrect, I do not understand what you mean by " you must switch to another parallel implementation in the last cycle" (example??)

crc_c(0) <= data(0) XOR data(6) XOR data(9) XOR data(10) XOR crc_i(16) XOR crc_i(26) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28);
crc_c(1) <= data(0) XOR data(1) XOR data(7) XOR data(11) XOR crc_i(17) XOR crc_i(27) XOR data(13) XOR crc_i(23) XOR crc_i(29) XOR data(6) XOR data(9) XOR crc_i(16) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28);
crc_c(2) <= data(0) XOR data(1) XOR data(2) XOR data(8) XOR crc_i(18) XOR data(14) XOR crc_i(24) XOR crc_i(30) XOR data(7) XOR crc_i(17) XOR data(13) XOR crc_i(23) XOR crc_i(29) XOR data(6) XOR data(9) XOR crc_i(16) XOR crc_i(25) XOR crc_i(22);
crc_c(3) <= data(1) XOR data(2) XOR data(3) XOR data(9) XOR crc_i(19) XOR data(15) XOR crc_i(25) XOR crc_i(31) XOR data(8) XOR crc_i(18) XOR data(14) XOR crc_i(24) XOR crc_i(30) XOR data(7) XOR data(10) XOR crc_i(17) XOR crc_i(26) XOR crc_i(23);

The code above can only be used to process 16 input bits in each clock cycle. The logic will be completely different if you want to process 64 or 8 or whatever bits per clock cycle. If you must handle input chunks of different sizes you need the complete logic for all of the possible sizes, and you must select the proper logic in the last clock cycle.
In your case, the intermediate result between clock cycles is always 32 bits, the same size as the CRC you are calculating.

From the implementation point of view, do I need to clock an extra bit or what exactly this mean for the implementation?

The polynomial must have one bit more than the CRC and the highest bit must be '1'. If you look at a bit-by-bit implementation, the other bits in the polynomial represents the places where you do an XOR in the intermediate result. The highest bit is represented by the highest bit in the shift register, which is fed back to the XOR gates. You don't have to think about this bit if you use logic generated by a tool.

The data is sent in 16 blocks

BK1Data-CRC,BK2DATA-CRC... etc

Isn't this mean CRC is transmitted last? If it is this way, does it mean they are padding the data or not necessarily?

Sorry, I remembered wrong about 802.3, the CRC is transmitted last.

Look at these documents: www.xilinx.com/support/documentation/application_notes/xapp209.pdf
https://stackoverflow.com/questions...32-calculation-software-vs-algorithmic-result

It seems that 32 zero bits are appended to the message before the polynomial division.
This means that the simplified checking is possible (the final remainder in the receiver will have a constant value when no errors occured).
The implementation in the Xilinx paper avoids the problem with different chunk sizes by doing all calculations with 8 input bits. I think that they should have mentioned how to handle packets with a size that isn't a multiple of the wanted chunk size.

As I mentioned earlier, you need example packets with correct CRC. The shorter packets, the simpler to debug and to use online tools to do the CRC calculations manually.
I think you can use the example in figure 4 in the Xilinx document to get started. You can see the first values of the 32-bit "working register".
In figure 3 you can see how the transmitted CRC is constructed from the value in the "working register".

 

[lucbra]

Any polynomial can be generated using an online tool that you can find at this link

It generates a function that you can call. It works very fine.

BTW when you use the same CRC function at Tx and Rx side, I used the following procedure:
- feed byte to the CRC generator while transmitting the byte
- do this for every byte you want to transmit, this means you get a running CRC word while transmitting bytes
- at the end of the transmission, you append your crc word at the stream of bytes

- at the receiver side, you feed the received byte to the same crc generator. do this for every byte you receive (also the crc bytes)
- when there is no error in the received bytes, you will find a magic word as output from the crc generator. This is always all zero's.

hope this helps

 

[troy99xx]

If you must handle input chunks of different sizes you need the complete logic for all of the possible sizes, and you must select the proper logic in the last clock cycle.
In your case, the intermediate result between clock cycles is always 32 bits, the same size as the CRC you are calculating.

Yes , my example was for 16 in width just as an example. I guess when you say "complete logic for all sizes" it is not something this online tools will generate. This is the part that I am not sure how to implement. It seems that my previous idea of using "byte enables" and retaining the previous value for bits that do not change on the last byte is not the way to go. Do you have an example of what this 'complete logic" means?


I am using this generator for my starting point since it can handle "initial value" **broken link removed**

Is it correct to assume that initial value is the same as a seed?


thanks

- - - Updated - - -

Any polynomial can be generated using an online tool that you can find at **broken link removed**

I using this generator as it allows me to select an initial seed **broken link removed**

Can you use initial seed with the generator you suggested?

BTW when you use the same CRC function at Tx and Rx side, I used the following procedure:
- feed byte to the CRC generator while transmitting the byte
- do this for every byte you want to transmit, this means you get a running CRC word while transmitting bytes
- at the end of the transmission, you append your crc word at the stream of bytes

- at the receiver side, you feed the received byte to the same crc generator. do this for every byte you receive (also the crc bytes)
- when there is no error in the received bytes, you will find a magic word as output from the crc generator. This is always all zero's.

hope this helps

The problem is that if I do not use a byte interface , I need to handle different widths (as describe in the msg chain above).

thanks

 

[std_match]

Yes , my example was for 16 in width just as an example. I guess when you say "complete logic for all sizes" it is not something this online tools will generate. This is the part that I am not sure how to implement. It seems that my previous idea of using "byte enables" and retaining the previous value for bits that do not change on the last byte is not the way to go. Do you have an example of what this 'complete logic" means?

Your code for updating the "working register" could look something like this if you want to process 32 bits at a time:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
if no_of_bytes_left = 3 then
  -- Place code for processing 24 input bits here
elsif no_of_bytes_left = 2 then
  -- Place code for processing 16 input bits here, like the code in your earlier posting
elsif no_of_bytes_left = 1
  -- Place code for processing 8 input bits here
else
  -- Place code for processing 32 input bits here
end if;

---

Is it correct to assume that initial value is the same as a seed?

Yes, and it should be very easy to adjust the seed in any code. It is just the initial value that is loaded into the "working register".

 

[troy99xx]

Your code for updating the "working register" could look something like this if you want to process 32 bits at a time:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
if no_of_bytes_left = 3 then
  -- Place code for processing 24 input bits here
elsif no_of_bytes_left = 2 then
  -- Place code for processing 16 input bits here, like the code in your earlier posting
elsif no_of_bytes_left = 1
  -- Place code for processing 8 input bits here
else
  -- Place code for processing 32 input bits here
end if;

---

I think this was the same idea that I mentioned above about using byte enables ( I think) , however in your sample above. Does each of the "elsif" calculated a CRC value for that portion of the code? This also goes to my original question of how do you obtain the final CRC for the whole thing?


If I take your example ( I am not using the correct polynomials for each byte or correct VHDL syntax, this is is just for illustration):

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
if no_of_bytes_left = 3 then
 
 
crc_24Bits(0) <= data(0) XOR data(6) XOR data(9) XOR data(10) XOR crc_i(16) XOR crc_i(26) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28); 
crc_24Bits(1) <= data(0) XOR data(1) XOR data(7) XOR data(11) XOR crc_i(17) XOR crc_i(27) XOR data(13) XOR crc_i(23) XOR crc_i(29) XOR data(6) XOR data(9) XOR crc_i(16) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28); 
.
.
.
crc_24Bits(23) <= crc_c(23) <= data(0) XOR data(1) XOR data(15) XOR crc_i(7) XOR crc_i(31) XOR crc_i(17) XOR data(13) XOR crc_i(29) XOR data(6) XOR data(9) XOR crc_i(16) XOR crc_i(25) XOR crc_i(22); 
 
 
 
partial_crc_24Bits(23 DOWNTO 0) <= crc_24Bits (23 DOWNTO 0);    <-------------- Is this correct partial CRC for 24 bits?
 
 
elsif no_of_bytes_left = 2 then
\
crc_16Bits(0) <= data(0) XOR data(6) XOR data(9) XOR data(10) XOR crc_i(16) XOR crc_i(26) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28); 
crc_16Bits(1) <= data(0) XOR data(1) XOR data(7) XOR data(11) XOR crc_i(17) XOR crc_i(27) XOR data(13) XOR crc_i(23) XOR crc_i(29) XOR data(6) XOR data(9) XOR crc_i(16) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28); 
.
.
.
crc_16Bits(15) <= crc_c(15) <= data(3) XOR data(4) XOR data(5) XOR data(7) XOR data(8) XOR crc_i(24) XOR crc_i(23) XOR crc_i(21) XOR crc_i(20) XOR data(9) XOR data(12) XOR crc_i(19) XOR crc_i(28) XOR data(15) XOR crc_i(25) XOR crc_i(31); 
 
 
partial_crc_16Bits(15 DOWNTO 0) <= crc_16Bits(15 DOWNTO 0);    <-------------- Is this correct partial CRC for 16 bits?
 
elsif no_of_bytes_left = 1
 
crc_8Bits(0) <= data(0) XOR data(6) XOR data(9) XOR data(10) XOR crc_i(16) XOR crc_i(26) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28); 
crc_8Bits(1) <= data(0) XOR data(1) XOR data(7) XOR data(11) XOR crc_i(17) XOR crc_i(27) XOR data(13) XOR crc_i(23) XOR crc_i(29) XOR data(6) XOR data(9) XOR crc_i(16) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28); 
.
.
.
crc_8Bits(7) <= crc_c(7) <= data(0) XOR data(2) XOR data(3) XOR data(5) XOR data(7) XOR crc_i(23) XOR crc_i(21) XOR crc_i(19) XOR data(15) XOR crc_i(31) XOR data(8) XOR crc_i(18) XOR crc_i(24) XOR data(10) XOR crc_i(16) XOR crc_i(26); 
 
 
partial_crc_8Bits (7 DOWNTO 0) <= crc_8Bits(7 DOWNTO 0);    <-------------- Is this correct partial CRC for 8 bits?
 
else
crc_32Bits(0) <= data(0) XOR data(6) XOR data(9) XOR data(10) XOR crc_i(16) XOR crc_i(26) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28); 
crc_32Bits(1) <= data(0) XOR data(1) XOR data(7) XOR data(11) XOR crc_i(17) XOR crc_i(27) XOR data(13) XOR crc_i(23) XOR crc_i(29) XOR data(6) XOR data(9) XOR crc_i(16) XOR crc_i(25) XOR data(12) XOR crc_i(22) XOR crc_i(28); 
.
.
.
crc_32Bits(31) <= crc_c(31) <= data(5) XOR data(8) XOR data(9) XOR crc_i(15) XOR crc_i(25) XOR crc_i(24) XOR data(11) XOR data(15) XOR crc_i(21) XOR crc_i(31) XOR crc_i(27); 
 
 
partial_crc_32Bits(31 DOWNTO 0) <= crc_32Bits(31 DOWNTO 0);    <-------------- Is this correct partial CRC for 32 bits?
end if;

---

So if the last package of data is sent 32bits + 8bits+ 32bits CRC

I will have a partial value for 32bits
partial_crc_32Bits(31 DOWNTO 0) -- Partial 32CRC
and a partial value for the last 8 bits
partial_crc_8Bits (7 DOWNTO 0) -- Partial 8 CRC


How do I calculate the total CRC for the last 40 bits having these partial CRC's to compare to the 32bits of CRC in the package?

thanks again!

 

[std_match]

Byte enables will not work since the equations are completely different, depending on the number of bytes to process.

Your example is not correct. There is only one 32-bit CRC register (I have called it the "working register")
Regardless of the number of bytes to process, the same 32-bit register is updated.

In your code, crc_i should be the working register (32 bits).

All 32 bits of crc_i will be updated in each clock cycle, regardless of the number of data bits (8, 16, 24, etc).
This means that there will be 32 equations in each branch of the code.
There will be no common equations between the branches. Each branch will have a unique set of 32 equations.

When the last byte is processed, the CRC will be in crc_i.

 

[troy99xx]

This means that there will be 32 equations in each branch of the code.
There will be no common equations between the branches. Each branch will have a unique set of 32 equations.

When the last byte is processed, the CRC will be in crc_i.

"This means that there will be 32 equations in each branch of the code."
Ok ,it seems that there should be a crc_i (32) in each branch, correct?
However, somehow the cri_i(32) in a particular branch should only be affected by the numbers of bytes selected.
Can you give an example of this?

"There will be no common equations between the branches. Each branch will have a unique set of 32 equations."
Again, if you can give an example.

I really do not understand what each branch suppose to do with the crr_i equations based on the number of bytes


thank you

 

[std_match]

Go to http://www.easics.com/webtools/crctool and design all the CRC generators you need.
You need one for each data length ("Data bus width" = 8, 16, 24, 32 etc).
The tool will create one source file with a function for each CRC generator.

The easics tool creates function with names like "nextCRC32_D24".

Your code could look like this:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
if no_of_bytes_left = 3 then
  crc_i <= nextCRC32_D24(data(23 downto 0), crc_i);
elsif no_of_bytes_left = 2 then
  crc_i <= nextCRC32_D16(data(15 downto 0), crc_i);
elsif no_of_bytes_left = 1
  crc_i <= nextCRC32_D8(data(7 downto 0), crc_i);
else
  crc_i <= nextCRC32_D32(data(31 downto 0), crc_i);
end if;

---

You will probably need to adjust the bit and byte order, which can be quite complicated.
You must have a correct example and try different combinations until you get it right.

More information about CRC calculations:

http://www.ross.net/crc/download/crc_v3.txt