Allan:

I looked into making wider CRC's run faster.

At first glance, it seems that the logic grows and grows. So
wider CRC's would seem to run slower due to logic depth.

But I found that the dependence on the internal CRC state does
NOT grow more and more complicated.

What this means is that you can do a calculation based on the
new data in, and combine it with a calculation based on the
internal state.

The advantage of this is that you can pipeline the complicated
calculation based on input data. It can take more than 1 clock.

I think that one should be able to make the CRC calculation for
any width wider than 32 bits take roughly the same time as
a 32-bit calculation, with a pipeline depth which grows with
the input width. Plus lots of extra pipeline flops.

I included a 64-bit calculation in the crc_32.lib which
demonstrates this.
I would expect it and wider CRC's to run in about the time it takes
to cascade 5 XOR's into a flop.

I found a paper on the web by a person from IBM which uses a
different tactic. It describes a way to calculate a much wider CRC
with simple terms, and then collapse it to the final crc_32 at the
end.

As you say, it looks like a 64-bit CRC should be able to run at
10 GBit/sec in an FPGA. I have no idea what IBM needs to do
checksums on which runs substantially faster. Curious.

blue beaver



CRC

each XOR

found in some

bit