EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

How to handle a data packet while calculating CRC.

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - How to handle a data packet while calculating CRC.

Goto page 1, 2  Next

yogesh tripathi
Guest

Mon Mar 12, 2018 12:45 pm   



Hi,

I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data.

I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo.


Is there a better technique for it?

Thank-You in advance.

Adam Górski
Guest

Mon Mar 12, 2018 2:45 pm   



On 2018-03-12 12:02, yogesh tripathi wrote:
Quote:
Hi,

I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data.

I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo.


Is there a better technique for it?

Thank-You in advance.


Hi

Calculate CRC on-the-fly together with incoming data.

Adam

yogesh tripathi
Guest

Tue Mar 13, 2018 5:45 am   



On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam Górski wrote:
Quote:
On 2018-03-12 12:02, yogesh tripathi wrote:
Hi,

I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data.

I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo.


Is there a better technique for it?

Thank-You in advance.


Hi

Calculate CRC on-the-fly together with incoming data.

Adam


Hi Adam,

"Calculate CRC on-the-fly together with incoming data." , can you elaborate it a bit more.
I'm getting a 8bit data in one clock cycle from the decoder. Now for crc i need serial shift register.

Emilian Miron
Guest

Tue Mar 13, 2018 5:45 pm   



Implement this transition function as your 8-bit data is coming in on each cyle:
https://en.wikipedia.org/wiki/Cyclic_redundancy_check#CRC-32_algorithm

Or you could have a 2x clock for the inner loop to fit the table access, or compute everything one byte per clock cycle by pipelining the accesses such as:
crc32_now = crc32_prev[23:0] XOR output_from_sram_one_cycle_delay
lookup_sram_index_next = crc32_now[7:0] XOR data_from_packet
crc32_prev = crc32_now

Then make sure you handle the reset conditions on packet start, end of packet, etc.

On Tuesday, March 13, 2018 at 12:05:15 AM UTC-4, yogesh tripathi wrote:
Quote:
On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam Górski wrote:
On 2018-03-12 12:02, yogesh tripathi wrote:
Hi,

I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data.

I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo.


Is there a better technique for it?

Thank-You in advance.


Hi

Calculate CRC on-the-fly together with incoming data.

Adam

Hi Adam,

"Calculate CRC on-the-fly together with incoming data." , can you elaborate it a bit more.
I'm getting a 8bit data in one clock cycle from the decoder. Now for crc i need serial shift register.


gtwrek
Guest

Tue Mar 13, 2018 8:45 pm   



In article <almarsoft.7981620793307616371_at_news.eternal-september.org>,
Bart Fox <bartfox_at_gmx.net> wrote:
Quote:
On Mon, 12 Mar 2018 21:05:09 -0700 (PDT), yogesh tripathi
yogitripathi47_at_gmail.com> wrote:
I'm getting a 8bit data in one clock cycle from the decoder. Now
for crc i =
need serial shift register.
You have some options:
1. Use a precalculated table (rainbow table) for CRC. With 8 bit the
size of the table is usually acceptable.
2. Use the 8x clock for the CRC calculating shift register (not
recommended here).
3. Use a pipelined CRC calculation: The calc module is 8 times in
parallel and you get the final result with eight clocks latency.


Table methods are very likely NOT the correct solution for FPGA
implementations. Those methods are tuned for SW solutions.

CRCs in hardware are actually quite easy / low resources. Shifting
through the 8 bits in one clock cycle will probably work just fine.
There's online websites that have "CRC" calculators which can
do some of this work for you. But I find just coding up the
algorithm in verilog / VHDL to be more compact and clear.

If that doesn't work - i.e. you're not hitting you're desired clock
frequencies - then Bart's suggestion of pipelining the calc is valid.
That can be a little trickier, but still doable. I don't think you'll
need to go this far, unless you're trying to hit some high clock rates.

Regards,

Mark

Bart Fox
Guest

Tue Mar 13, 2018 8:45 pm   



On Mon, 12 Mar 2018 21:05:09 -0700 (PDT), yogesh tripathi
<yogitripathi47_at_gmail.com> wrote:
Quote:
I'm getting a 8bit data in one clock cycle from the decoder. Now
for crc i =
need serial shift register.

You have some options:
1. Use a precalculated table (rainbow table) for CRC. With 8 bit the
size of the table is usually acceptable.
2. Use the 8x clock for the CRC calculating shift register (not
recommended here).
3. Use a pipelined CRC calculation: The calc module is 8 times in
parallel and you get the final result with eight clocks latency.

Bart

Mike Perkins
Guest

Tue Mar 13, 2018 9:45 pm   



On 13/03/2018 04:05, yogesh tripathi wrote:
Quote:
On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam Górski wrote:
On 2018-03-12 12:02, yogesh tripathi wrote:
Hi,

I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data.

I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo.


Is there a better technique for it?

Thank-You in advance.


Hi

Calculate CRC on-the-fly together with incoming data.

Adam

Hi Adam,

"Calculate CRC on-the-fly together with incoming data." , can you elaborate it a bit more.
I'm getting a 8bit data in one clock cycle from the decoder. Now for crc i need serial shift register.


Not necessarily, have a look at:
http://www.easics.com/webtools/crctool

I've used this, albeit a few years ago and the website has changed since.

If I recall you have to invert and swap the bit order to get the correct
CRC. I used a simulator to check the permutations until I got it right.

If you have 8bit data you can generate the CRC on the fly at the same rate.


--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

yogesh tripathi
Guest

Thu Mar 15, 2018 12:45 pm   



On Wednesday, March 14, 2018 at 1:18:40 AM UTC+5:30, Mike Perkins wrote:
Quote:
On 13/03/2018 04:05, yogesh tripathi wrote:
On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam Górski wrote:
On 2018-03-12 12:02, yogesh tripathi wrote:
Hi,

I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data.

I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo.


Is there a better technique for it?

Thank-You in advance.


Hi

Calculate CRC on-the-fly together with incoming data.

Adam

Hi Adam,

"Calculate CRC on-the-fly together with incoming data." , can you elaborate it a bit more.
I'm getting a 8bit data in one clock cycle from the decoder. Now for crc i need serial shift register.

Not necessarily, have a look at:
http://www.easics.com/webtools/crctool

I've used this, albeit a few years ago and the website has changed since.

If I recall you have to invert and swap the bit order to get the correct
CRC. I used a simulator to check the permutations until I got it right.

If you have 8bit data you can generate the CRC on the fly at the same rate.


--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk


Thank-You Mike.
The link gives a provide a HDL package which is basically a Parallel LFSR. You know any related text how to generate a custom LFSR for these CRC ,just for better understanding.

Adam Górski
Guest

Thu Mar 15, 2018 6:45 pm   



Quote:
Hi,

I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data.

I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo.


Is there a better technique for it?

Thank-You in advance.


Hi

Calculate CRC on-the-fly together with incoming data.

Adam

Hi Adam,

"Calculate CRC on-the-fly together with incoming data." , can you elaborate it a bit more.
I'm getting a 8bit data in one clock cycle from the decoder. Now for crc i need serial shift register.


So look for CRC implementation able to process 8bits ( byte ) in single
clock and store data in same time to fifo and to CRC unit.

Hint: Online CRC VHDL generator. There is many.

Best regards

Adam Górski

Mike Perkins
Guest

Thu Mar 15, 2018 10:45 pm   



On 15/03/2018 11:28, yogesh tripathi wrote:
Quote:
On Wednesday, March 14, 2018 at 1:18:40 AM UTC+5:30, Mike Perkins
wrote:
On 13/03/2018 04:05, yogesh tripathi wrote:
On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam Górski
wrote:
On 2018-03-12 12:02, yogesh tripathi wrote:
Hi,

I'm trying to process a Ethernet type package. Suppose if i
have detected SFD and now have a <1600Byte data.

I'm extracting different package
element(ds_addr,src_addr,etc) concatenating them in a long
shift register and at same time passing it to a fifo to
buffer and calculating crc32 which will take some clock
cycles(xoring and shifting). Now if calculated CRC matched
what is received, pass data to nxt stage else rst fifo.


Is there a better technique for it?

Thank-You in advance.


Hi

Calculate CRC on-the-fly together with incoming data.

Adam

Hi Adam,

"Calculate CRC on-the-fly together with incoming data." , can you
elaborate it a bit more. I'm getting a 8bit data in one clock
cycle from the decoder. Now for crc i need serial shift
register.

Not necessarily, have a look at:
http://www.easics.com/webtools/crctool

I've used this, albeit a few years ago and the website has changed
since.

If I recall you have to invert and swap the bit order to get the
correct CRC. I used a simulator to check the permutations until I
got it right.

If you have 8bit data you can generate the CRC on the fly at the
same rate.


-- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk

Thank-You Mike. The link gives a provide a HDL package which is
basically a Parallel LFSR. You know any related text how to generate
a custom LFSR for these CRC ,just for better understanding.


I looked into this a long while ago and gave up!

A LFSR is a simple concept in it's own right but I didn't have time to
decipher a Parallel LFSR. I made the choice of using the result rather
than spend time trying to understand something I would only use once in
a long while.

I'm sure there are proof and theorems on the 'net somewhere!


--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Bart Fox
Guest

Fri Mar 16, 2018 12:45 am   



On Tue, 13 Mar 2018 19:28:17 -0000 (UTC), gtwrek_at_sonic.net (gtwrek)
wrote:
Quote:
Table methods are very likely NOT the correct solution for FPGA
implementations. Those methods are tuned for SW solutions.


Sorry for respeak.Of course is the usage of a lookup-table a valid
design technic for FPGAs.
Maybe not in the range of megabytes, but e.g. for 8 bit input and 8
bit output it's very acceptable.
One example: a low fidelity DDS usually use a small ROM with a sine
table...

Bart Fox

gtwrek
Guest

Fri Mar 16, 2018 1:45 am   



In article <almarsoft.7623430815815314146_at_news.eternal-september.org>,
Bart Fox <bartfox_at_gmx.net> wrote:
Quote:
On Tue, 13 Mar 2018 19:28:17 -0000 (UTC), gtwrek_at_sonic.net (gtwrek)
wrote:
Table methods are very likely NOT the correct solution for FPGA
implementations. Those methods are tuned for SW solutions.

Sorry for respeak.Of course is the usage of a lookup-table a valid
design technic for FPGAs.
Maybe not in the range of megabytes, but e.g. for 8 bit input and 8
bit output it's very acceptable.
One example: a low fidelity DDS usually use a small ROM with a sine
table...


Table lookups, in general, are a very valid tool for some hardware
solutions. Just not for CRCs. A "brute force" table lookup for an
8-bit input, 8-bit CRC would require 2**16 entries by 8 bits. So a
64 KByte table. Not efficient. So one looks up many of the
"Software" table generated techniques to reduce the requirements.
Problem is those techniques are tuned to optimizes SW, not HW.

.... All to replace something less than a 100 LUT6s, and 8 FFs.

CRCs in hardware are very efficient just coded brute force.

Regards,

Mark


Guest

Fri Mar 16, 2018 2:45 am   



Den fredag den 16. marts 2018 kl. 01.29.54 UTC+1 skrev gtwrek:
Quote:
In article <almarsoft.7623430815815314146_at_news.eternal-september.org>,
Bart Fox <bartfox_at_gmx.net> wrote:
On Tue, 13 Mar 2018 19:28:17 -0000 (UTC), gtwrek_at_sonic.net (gtwrek)
wrote:
Table methods are very likely NOT the correct solution for FPGA
implementations. Those methods are tuned for SW solutions.

Sorry for respeak.Of course is the usage of a lookup-table a valid
design technic for FPGAs.
Maybe not in the range of megabytes, but e.g. for 8 bit input and 8
bit output it's very acceptable.
One example: a low fidelity DDS usually use a small ROM with a sine
table...

Table lookups, in general, are a very valid tool for some hardware
solutions. Just not for CRCs. A "brute force" table lookup for an
8-bit input, 8-bit CRC would require 2**16 entries by 8 bits. So a
64 KByte table. Not efficient. So one looks up many of the
"Software" table generated techniques to reduce the requirements.
Problem is those techniques are tuned to optimizes SW, not HW.

... All to replace something less than a 100 LUT6s, and 8 FFs.

CRCs in hardware are very efficient just coded brute force.


http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html#ch6

doesn't look too bad

gtwrek
Guest

Fri Mar 16, 2018 2:45 am   



In article <b12f68ce-d635-4556-8fdc-ece405559d98_at_googlegroups.com>,
<lasselangwadtchristensen_at_gmail.com> wrote:
Quote:
Den fredag den 16. marts 2018 kl. 01.29.54 UTC+1 skrev gtwrek:
In article <almarsoft.7623430815815314146_at_news.eternal-september.org>,
Bart Fox <bartfox_at_gmx.net> wrote:
On Tue, 13 Mar 2018 19:28:17 -0000 (UTC), gtwrek_at_sonic.net (gtwrek)
wrote:
Table methods are very likely NOT the correct solution for FPGA
implementations. Those methods are tuned for SW solutions.

Sorry for respeak.Of course is the usage of a lookup-table a valid
design technic for FPGAs.
Maybe not in the range of megabytes, but e.g. for 8 bit input and 8
bit output it's very acceptable.
One example: a low fidelity DDS usually use a small ROM with a sine
table...

Table lookups, in general, are a very valid tool for some hardware
solutions. Just not for CRCs. A "brute force" table lookup for an
8-bit input, 8-bit CRC would require 2**16 entries by 8 bits. So a
64 KByte table. Not efficient. So one looks up many of the
"Software" table generated techniques to reduce the requirements.
Problem is those techniques are tuned to optimizes SW, not HW.

... All to replace something less than a 100 LUT6s, and 8 FFs.

CRCs in hardware are very efficient just coded brute force.


http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html#ch6

doesn't look too bad


My favorite reference is:
http://www.ross.net/crc/download/crc_v3.txt

Hardware engineers should STOP reading after section 8. That's all you
need to know as a hardware designer. Everything after section 8 is
dedicated to software optimizations where one doesn't have free access
to any bit - like we do in hardware.

Regards,

Mark

David Brown
Guest

Fri Mar 16, 2018 9:45 am   



On 16/03/18 01:29, gtwrek wrote:
Quote:
In article <almarsoft.7623430815815314146_at_news.eternal-september.org>,
Bart Fox <bartfox_at_gmx.net> wrote:
On Tue, 13 Mar 2018 19:28:17 -0000 (UTC), gtwrek_at_sonic.net (gtwrek)
wrote:
Table methods are very likely NOT the correct solution for FPGA
implementations. Those methods are tuned for SW solutions.

Sorry for respeak.Of course is the usage of a lookup-table a valid
design technic for FPGAs.
Maybe not in the range of megabytes, but e.g. for 8 bit input and 8
bit output it's very acceptable.
One example: a low fidelity DDS usually use a small ROM with a sine
table...

Table lookups, in general, are a very valid tool for some hardware
solutions. Just not for CRCs. A "brute force" table lookup for an
8-bit input, 8-bit CRC would require 2**16 entries by 8 bits. So a
64 KByte table. Not efficient.


No, it is 8-bit in (the address), 32-bit out for a 32-bit CRC - 1024 bytes.

Quote:
So one looks up many of the
"Software" table generated techniques to reduce the requirements.
Problem is those techniques are tuned to optimizes SW, not HW.

... All to replace something less than a 100 LUT6s, and 8 FFs.

CRCs in hardware are very efficient just coded brute force.


CRC's in hardware, using a shift register, are very efficient if your
data is coming in a bit at a time. If you have data in memory or
arriving in a wider path, table lookup can be very useful. You can
choose your sizes to give a balance between speed and size. For
example, you could use 4-bit in, 32-bit out tables and run 4 bits at a
time. (Such a solution can be pipelined for greater throughput.)

Goto page 1, 2  Next

elektroda.net NewsGroups Forum Index - FPGA - How to handle a data packet while calculating CRC.

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map