I have a 181 bytes data stream with 4 bytes CRC32 value at the end. The entire message length is 185 bytes.
The data stream is stored in the FPGA onchip memory and waiting to put into wire by TCP.
Before sending out the message, there are some 32 bits data in the data stream need to be modified resulting revising CRC value is needed.
The location of the new bit values are from 41st - 63rd bit (starting the 5th byte) from the LSB of the stream.
As the CRC is within the tcp message payload, the tcp header and ip checksum have to be revised as well.
Currently I have to build a pipeline module for re-calculating the CRC like this:
module crc32 ( input rst, input clk, input [255:0] in_data, input crc_en, output crc_out );
It works but it need to spend 181 bytes / 256 bits ~= 6 cycles for revising the CRC value of a 181 bytes TCP message.
Although the CRC is located at the end of the business message, the tcp header checksum (which is more significant than the tcp payload) can be revised only when the new CRC value is calculated. That's the reason why it have to wait 6 cycles.
Is there any smart revising CRC algorithm so that I can use less number of cycles to revise the CRC of a modified data stream?
- Is there any way to recalculate CRC based on the old CRC value? CRC(new) = revise(CRC(old))?
- I learn from this paper that by patching the data stream to maintain the old CRC value.
CH5 : GETTING A CHOSEN CRC BY ALTERING A CHOSEN POSITION
It is interesting but it require to recalculate crc from n bit to m bit
where n = start bit location of modified field
m = start bit location of the patch field
which doesn't look good for saving clock cycles.