I was reading your PDF about “Parallel CRC Generation Method” and is very interesting, about this theme I developed a routine to calculate the CRC of packets from the net but I have a doub about this and I know that you are an expert in FPGA programation and for that reason me I ask to you the next.
I´m working with “Started Kit Board Spartan3E” develop a ethernet comunication and now I´m receiving packet from the net
I have a program on VHDL language which calculate the “CRC32″ of a packet from ethernet and it do it fine, I know that because I check the packet I received from the ethernet port with other software that calculate the CRC32(HashCalc) and the result it´s the same, and like a third instance I do the same operation on a web-page that can calculate CRC32 on-line.
All is good to this point, but the problem is with the “CRC32″ that comes with the packet from ethernet, it not correspond with the “CRC32″ of my program and in accordingly neither with the “CRC32″ from the other softwares.
I don´t know how can occur this, I don´t understand what it´s happend, in theory my “CRC” it´s good but no correspons with the “CRC” of the packet.
Could you said me why is occurring this?, exist some diference between the theory an the practice.
I´m going to present you the packet and CRC´s.
Packet from the net. (HEX).
FFFFFFFFFFFF0020ED1C149B080600010800060400010020ED1C149BC804079C000000000000C8040783000000000000000000000000000000000000
Zeros that my program add to the end of packet to calculate the CRC, rule of the theory, 4 bytes (HEX).
00000000
“CRC” from my program and others softwares. (HEX).
A4B1E797
“CRC” of the packet from the net.
12364526
Could you see the diference?, I think it´s other operation at the end of the calculate of the “CRC” which make the diference, something that in theory don´t said, I don´t know.
I appreciate very much that you could explain me why this phenomenon.
Thank you very much in advance and I hope for your answer.
Dear AG,
Thanks for taking your time to read my CRC article.
Regarding your question, it’s hard for me to provide an intelligent answer to why you don’t get the same results for received CRC without looking into the implementation.
Is it possible to compute a case where the data width is >2000? I noticed the limit on 1024. I am looking at the parity equation of x32 + x30 + x21 + x9 + 1 and would like to use a data size of 2080. The parity width is 32. Thanks!
I’m using the Parallel Scrambler tool to produce an x8 version of the scrambling function used for Digital Video Broadcasting (DVB-S2). This scrambler is used as an example on Wikipedia for the discussion of scramblers and is found here:
Upon implementation of this I see an inconsistency between the parameters I need to enter for the logic generation tool, and what the DVB-S2 Specification (ETSI EN 302 307) presents as the function definition. In particular the specification (and wikipedia) say the function is 1 + X(14) + X(15). (with an initialization of 100101010000000).
So with LFSR width of 15, which I provide the tool, ’step2′ provides 1 + x(1) … x(14) and stops, there is no x(15). Hmmm. Perhaps there is a descrepency with x(0) and how this is treated, can you provide insight? For instance it appears maybe the ETSI spec. itself is incorrect? and should be 1 + X(13) + X(14). Or is the logic gen. tool off by one?
For a 15-bit wide polynomial there are 15 check boxes from x^0, which is 1, to x^14. x^15 is a feedback, so it’s always there.
So for “1 + X(14) + X(15)” you select boxes 1 and x^14.
I agree that it’s somewhat confusing, and I probably should add a grayed-out x^15 check box.
I can see that it been a while since anyone have replyed or posted on this site.
So is it still monitored? and is it still possible to ask question. I have on in regard to the scrambler generator.
But i wont start explaning my problem, since it will take time, and it whould be a waste if noone will answer it anyway
Hello, thank you for publishing the code of the parallel scrambler.
I want to use the scrambler with a 16 bit interface where the two bytes should be
scrambled or passed through.
In this way could you give me a hint how to add two scram_en bits to implement this?
A not scrambled byte shall also reset the scrambler to the seed.
Hello Evgeni,
thank you for the hint,
it looks that with pass through the input will lead to the output and the lfsr_q will stall.
But how to pass through the upper 8 bits of a 16 bit bus while scrambling the lower ones or vice versa?
In this way IMO when the upper bits are used only these bits must be XORed to the lfsr and based on which or both bytes are passed through there should be 3 different lfsr_c vectors which are used to update the lfsr_q at the next clock edge.
Or is it much simpler but I haven’t recognized it?
Eng. Evgeni Stavinov
I was reading your PDF about “Parallel CRC Generation Method” and is very interesting, about this theme I developed a routine to calculate the CRC of packets from the net but I have a doub about this and I know that you are an expert in FPGA programation and for that reason me I ask to you the next.
I´m working with “Started Kit Board Spartan3E” develop a ethernet comunication and now I´m receiving packet from the net
I have a program on VHDL language which calculate the “CRC32″ of a packet from ethernet and it do it fine, I know that because I check the packet I received from the ethernet port with other software that calculate the CRC32(HashCalc) and the result it´s the same, and like a third instance I do the same operation on a web-page that can calculate CRC32 on-line.
All is good to this point, but the problem is with the “CRC32″ that comes with the packet from ethernet, it not correspond with the “CRC32″ of my program and in accordingly neither with the “CRC32″ from the other softwares.
I don´t know how can occur this, I don´t understand what it´s happend, in theory my “CRC” it´s good but no correspons with the “CRC” of the packet.
Could you said me why is occurring this?, exist some diference between the theory an the practice.
I´m going to present you the packet and CRC´s.
Packet from the net. (HEX).
FFFFFFFFFFFF0020ED1C149B080600010800060400010020ED1C149BC804079C000000000000C8040783000000000000000000000000000000000000
Zeros that my program add to the end of packet to calculate the CRC, rule of the theory, 4 bytes (HEX).
00000000
“CRC” from my program and others softwares. (HEX).
A4B1E797
“CRC” of the packet from the net.
12364526
Could you see the diference?, I think it´s other operation at the end of the calculate of the “CRC” which make the diference, something that in theory don´t said, I don´t know.
I appreciate very much that you could explain me why this phenomenon.
Thank you very much in advance and I hope for your answer.
A.G.
Dear AG,
Thanks for taking your time to read my CRC article.
Regarding your question, it’s hard for me to provide an intelligent answer to why you don’t get the same results for received CRC without looking into the implementation.
Is it possible to compute a case where the data width is >2000? I noticed the limit on 1024. I am looking at the parity equation of x32 + x30 + x21 + x9 + 1 and would like to use a data size of 2080. The parity width is 32. Thanks!
Hi Mark.
Are you using CRC Generator ?
You can download a stand-alone application from http://sourceforge.net/projects/crc-gen-verilog
It doesn’t have this limitation on a data size.
Thanks,
Evgeni
Hi,
No, I was using the Scrambler generator. Perhaps I will give the crc-gen-verilog tool a try – thanks!
Mark
Hello Evgeni,
I’m using the Parallel Scrambler tool to produce an x8 version of the scrambling function used for Digital Video Broadcasting (DVB-S2). This scrambler is used as an example on Wikipedia for the discussion of scramblers and is found here:
http://en.wikipedia.org/wiki/Scrambler#Additive_.28synchronous.29_scramblers
Upon implementation of this I see an inconsistency between the parameters I need to enter for the logic generation tool, and what the DVB-S2 Specification (ETSI EN 302 307) presents as the function definition. In particular the specification (and wikipedia) say the function is 1 + X(14) + X(15). (with an initialization of 100101010000000).
So with LFSR width of 15, which I provide the tool, ’step2′ provides 1 + x(1) … x(14) and stops, there is no x(15). Hmmm. Perhaps there is a descrepency with x(0) and how this is treated, can you provide insight? For instance it appears maybe the ETSI spec. itself is incorrect? and should be 1 + X(13) + X(14). Or is the logic gen. tool off by one?
Thank You,
J.J.
Hi J.J.,
For a 15-bit wide polynomial there are 15 check boxes from x^0, which is 1, to x^14. x^15 is a feedback, so it’s always there.
So for “1 + X(14) + X(15)” you select boxes 1 and x^14.
I agree that it’s somewhat confusing, and I probably should add a grayed-out x^15 check box.
Thanks,
Evgeni
I can see that it been a while since anyone have replyed or posted on this site.
So is it still monitored? and is it still possible to ask question. I have on in regard to the scrambler generator.
But i wont start explaning my problem, since it will take time, and it whould be a waste if noone will answer it anyway
Regards Vinther.
Hi Vinther,
I’ll try to answer your question.
Thanks,
Evgeni
Hi Evgeni,
Could you supply Paraller Descrambler Generator similar to Paraller Scrambler Generator ?
Thanks,
Kaitlin
Hello, thank you for publishing the code of the parallel scrambler.
I want to use the scrambler with a 16 bit interface where the two bytes should be
scrambled or passed through.
In this way could you give me a hint how to add two scram_en bits to implement this?
A not scrambled byte shall also reset the scrambler to the seed.
Hi Martin,
You can add pass_thru input, and change the logic to:
data_out < = pass_thru ? data_in : (scram_en ? data_c : data_out);You'd need to assert scram_rst to reset the seed.
Hope that helps,
Evgeni
Hello Evgeni,
thank you for the hint,
it looks that with pass through the input will lead to the output and the lfsr_q will stall.
But how to pass through the upper 8 bits of a 16 bit bus while scrambling the lower ones or vice versa?
In this way IMO when the upper bits are used only these bits must be XORed to the lfsr and based on which or both bytes are passed through there should be 3 different lfsr_c vectors which are used to update the lfsr_q at the next clock edge.
Or is it much simpler but I haven’t recognized it?
BR, Martin
You can have, for example:
data_out < = scram_en ? {data_in[15:8], data_c[7:0]}: data_out);