Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Think of your family tonight. Try to crawl home after the computer crashes.


devel / comp.arch.fpga / Re: Cheacksum implementation in VHDL

SubjectAuthor
* Re: Cheacksum implementation in VHDLVincent Li
`* Re: Cheacksum implementation in VHDLMike Perkins
 `* Re: Cheacksum implementation in VHDLgnuarm.del...@gmail.com
  `* Re: Cheacksum implementation in VHDLDavid Brown
   +* Re: Cheacksum implementation in VHDLgnuarm.del...@gmail.com
   |`* Re: Cheacksum implementation in VHDLDavid Brown
   | `- Re: Cheacksum implementation in VHDLgnuarm.del...@gmail.com
   `- Re: Cheacksum implementation in VHDLStef

1
Re: Cheacksum implementation in VHDL

<116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=223&group=comp.arch.fpga#223

  copy link   Newsgroups: comp.arch.fpga
X-Received: by 2002:ad4:54ca:: with SMTP id j10mr26377549qvx.2.1636467262777;
Tue, 09 Nov 2021 06:14:22 -0800 (PST)
X-Received: by 2002:a05:622a:1a9b:: with SMTP id s27mr8608952qtc.417.1636467262590;
Tue, 09 Nov 2021 06:14:22 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.fpga
Date: Tue, 9 Nov 2021 06:14:22 -0800 (PST)
In-Reply-To: <38eb5796@news.barak.net.il>#1/1>
Injection-Info: google-groups.googlegroups.com; posting-host=192.38.81.6; posting-account=bdVE1goAAACgGH7nGCgvJRCOf5CXMnBz
NNTP-Posting-Host: 192.38.81.6
References: <38eb5796@news.barak.net.il>#1/1>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>
Subject: Re: Cheacksum implementation in VHDL
From: 01vincen...@gmail.com (Vincent Li)
Injection-Date: Tue, 09 Nov 2021 14:14:22 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Vincent Li - Tue, 9 Nov 2021 14:14 UTC

onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
> I'm looking for checksum implementation in VHDL (or at least the basic rules
> to build one).
> Regards
> Ron
rip

Re: Cheacksum implementation in VHDL

<smgsjk$1esa3$1@news2.open-news-network.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=227&group=comp.arch.fpga#227

  copy link   Newsgroups: comp.arch.fpga
Path: i2pn2.org!i2pn.org!aioe.org!news.mb-net.net!open-news-network.org!news.bgeserver.de!news.arnold-schiller.de!news2.open-news-network.org!.POSTED.95.146.207.15!not-for-mail
From: spa...@spam.com (Mike Perkins)
Newsgroups: comp.arch.fpga
Subject: Re: Cheacksum implementation in VHDL
Date: Wed, 10 Nov 2021 16:39:11 +0000
Organization: news2.open-news-network.org
Message-ID: <smgsjk$1esa3$1@news2.open-news-network.org>
References: <38eb5796@news.barak.net.il>
<116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 10 Nov 2021 16:39:16 -0000 (UTC)
Injection-Info: news2.open-news-network.org; posting-host="95.146.207.15";
logging-data="1536323"; mail-complaints-to="abuse@bgeserver.de"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Content-Language: en-GB
In-Reply-To: <116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>
 by: Mike Perkins - Wed, 10 Nov 2021 16:39 UTC

On 09/11/2021 14:14, Vincent Li wrote:
> onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
>> I'm looking for checksum implementation in VHDL (or at least the basic rules
>> to build one).
>> Regards
>> Ron
> rip

Do you really mean checksum, or CRC?

Checksum is easy to understand, CRC less so.

I confess it's a long time since I used/looked up first principles to
generate CRCs and use this website:
https://www.easics.com/crctool/

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

Re: Cheacksum implementation in VHDL

<79fb7820-960d-42fe-bdd6-9208b32fb157n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=231&group=comp.arch.fpga#231

  copy link   Newsgroups: comp.arch.fpga
X-Received: by 2002:ae9:e502:: with SMTP id w2mr35987149qkf.315.1637417963893;
Sat, 20 Nov 2021 06:19:23 -0800 (PST)
X-Received: by 2002:a37:4141:: with SMTP id o62mr36351414qka.292.1637417963760;
Sat, 20 Nov 2021 06:19:23 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.fpga
Date: Sat, 20 Nov 2021 06:19:23 -0800 (PST)
In-Reply-To: <smgsjk$1esa3$1@news2.open-news-network.org>
Injection-Info: google-groups.googlegroups.com; posting-host=24.138.223.107; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 24.138.223.107
References: <38eb5796@news.barak.net.il> <116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>
<smgsjk$1esa3$1@news2.open-news-network.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <79fb7820-960d-42fe-bdd6-9208b32fb157n@googlegroups.com>
Subject: Re: Cheacksum implementation in VHDL
From: gnuarm.d...@gmail.com (gnuarm.del...@gmail.com)
Injection-Date: Sat, 20 Nov 2021 14:19:23 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 30
 by: gnuarm.del...@gmail. - Sat, 20 Nov 2021 14:19 UTC

On Wednesday, November 10, 2021 at 12:39:22 PM UTC-4, Mike Perkins wrote:
> On 09/11/2021 14:14, Vincent Li wrote:
> > onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
> >> I'm looking for checksum implementation in VHDL (or at least the basic rules
> >> to build one).
> >> Regards
> >> Ron
> > rip
> Do you really mean checksum, or CRC?
>
> Checksum is easy to understand, CRC less so.
>
> I confess it's a long time since I used/looked up first principles to
> generate CRCs and use this website:
> https://www.easics.com/crctool/

The only hard part to CRC is understanding the nomenclature. There are several options for computing CRCs based on polarity and direction. Specifying this is not consistent and often it is assumed that you know the "standard". With the combinations it can be very hard to get it right and be able to verify that. So by all means make sure you verify your results in the simplest medium you can before proceeding to anything more complex like coding.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

Re: Cheacksum implementation in VHDL

<snb2g1$tdu$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=232&group=comp.arch.fpga#232

  copy link   Newsgroups: comp.arch.fpga
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.fpga
Subject: Re: Cheacksum implementation in VHDL
Date: Sat, 20 Nov 2021 15:59:13 +0100
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <snb2g1$tdu$1@dont-email.me>
References: <38eb5796@news.barak.net.il>
<116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>
<smgsjk$1esa3$1@news2.open-news-network.org>
<79fb7820-960d-42fe-bdd6-9208b32fb157n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 20 Nov 2021 14:59:13 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="97de0f5820112279033bb40994fc41ca";
logging-data="30142"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/OVbMYqQgO+tkhh2mTCL6vgnyoyT9ogqc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:/y2vxRu9kAxHzNjTinO3ricdmKo=
In-Reply-To: <79fb7820-960d-42fe-bdd6-9208b32fb157n@googlegroups.com>
Content-Language: en-GB
 by: David Brown - Sat, 20 Nov 2021 14:59 UTC

On 20/11/2021 15:19, gnuarm.del...@gmail.com wrote:
> On Wednesday, November 10, 2021 at 12:39:22 PM UTC-4, Mike Perkins
> wrote:
>> On 09/11/2021 14:14, Vincent Li wrote:
>>> onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
>>>> I'm looking for checksum implementation in VHDL (or at least
>>>> the basic rules to build one). Regards Ron
>>> rip
>> Do you really mean checksum, or CRC?
>>
>> Checksum is easy to understand, CRC less so.
>>
>> I confess it's a long time since I used/looked up first principles
>> to generate CRCs and use this website:
>> https://www.easics.com/crctool/
>
> The only hard part to CRC is understanding the nomenclature. There
> are several options for computing CRCs based on polarity and
> direction. Specifying this is not consistent and often it is assumed
> that you know the "standard". With the combinations it can be very
> hard to get it right and be able to verify that. So by all means
> make sure you verify your results in the simplest medium you can
> before proceeding to anything more complex like coding.
>

That's what I usually see as a challenge for CRC's - getting different
implementations to agree. If you can use the same implementation on all
parts, then the details (bit ordering, polarity, polynomial, etc.) don't
matter. My usual solution is using a lookup table of 256 entries. It's
simple for 8-bit CRC's, and not too difficult for 16-bit or 32-bit
CRC's, and should be as straightforward to make on an FPGA as it is in
C, Python, or whatever programming language takes your fancy. That
makes it easy to get matching results on multiple systems. But it would
take a bit more FPGA resources than a bit-wise linear feedback register.

Re: Cheacksum implementation in VHDL

<67467037-c7d9-41d6-85b1-a49d93c3f6f9n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=235&group=comp.arch.fpga#235

  copy link   Newsgroups: comp.arch.fpga
X-Received: by 2002:a05:620a:372a:: with SMTP id de42mr39950388qkb.14.1638201977661;
Mon, 29 Nov 2021 08:06:17 -0800 (PST)
X-Received: by 2002:a05:622a:554:: with SMTP id m20mr44820764qtx.382.1638201977450;
Mon, 29 Nov 2021 08:06:17 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.fpga
Date: Mon, 29 Nov 2021 08:06:17 -0800 (PST)
In-Reply-To: <snb2g1$tdu$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=24.138.223.107; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 24.138.223.107
References: <38eb5796@news.barak.net.il> <116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>
<smgsjk$1esa3$1@news2.open-news-network.org> <79fb7820-960d-42fe-bdd6-9208b32fb157n@googlegroups.com>
<snb2g1$tdu$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <67467037-c7d9-41d6-85b1-a49d93c3f6f9n@googlegroups.com>
Subject: Re: Cheacksum implementation in VHDL
From: gnuarm.d...@gmail.com (gnuarm.del...@gmail.com)
Injection-Date: Mon, 29 Nov 2021 16:06:17 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 57
 by: gnuarm.del...@gmail. - Mon, 29 Nov 2021 16:06 UTC

On Saturday, November 20, 2021 at 10:59:20 AM UTC-4, David Brown wrote:
> On 20/11/2021 15:19, gnuarm.del...@gmail.com wrote:
> > On Wednesday, November 10, 2021 at 12:39:22 PM UTC-4, Mike Perkins
> > wrote:
> >> On 09/11/2021 14:14, Vincent Li wrote:
> >>> onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
> >>>> I'm looking for checksum implementation in VHDL (or at least
> >>>> the basic rules to build one). Regards Ron
> >>> rip
> >> Do you really mean checksum, or CRC?
> >>
> >> Checksum is easy to understand, CRC less so.
> >>
> >> I confess it's a long time since I used/looked up first principles
> >> to generate CRCs and use this website:
> >> https://www.easics.com/crctool/
> >
> > The only hard part to CRC is understanding the nomenclature. There
> > are several options for computing CRCs based on polarity and
> > direction. Specifying this is not consistent and often it is assumed
> > that you know the "standard". With the combinations it can be very
> > hard to get it right and be able to verify that. So by all means
> > make sure you verify your results in the simplest medium you can
> > before proceeding to anything more complex like coding.
> >
> That's what I usually see as a challenge for CRC's - getting different
> implementations to agree. If you can use the same implementation on all
> parts, then the details (bit ordering, polarity, polynomial, etc.) don't
> matter. My usual solution is using a lookup table of 256 entries. It's
> simple for 8-bit CRC's, and not too difficult for 16-bit or 32-bit
> CRC's, and should be as straightforward to make on an FPGA as it is in
> C, Python, or whatever programming language takes your fancy. That
> makes it easy to get matching results on multiple systems. But it would
> take a bit more FPGA resources than a bit-wise linear feedback register.

Meh... it still doesn't assure equivalent implementations. I did this just a year or so ago and had the hardest time with it because of all these details and the fact that there is no consistent nomenclature for it all. In FPGAs you think in terms of shifting bits and XORing stuff. The software implementations typically do the table lookup and twiddle things in ways that suit byte organizations rather than matching the algorithm/math description very much. Given it is important as to which bits you pick for your output and which way you shift the data and where the data enters the shifter.... maybe I'm just getting old and the hair I no longer see on the outside is growing on the inside mucking up the works.

In contrast I found LFSR to be very simple indeed, even if calculated 32 bits at a time and it always worked, matching other implementations.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Re: Cheacksum implementation in VHDL

<so3a57$oal$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=237&group=comp.arch.fpga#237

  copy link   Newsgroups: comp.arch.fpga
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.fpga
Subject: Re: Cheacksum implementation in VHDL
Date: Mon, 29 Nov 2021 20:37:10 +0100
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <so3a57$oal$1@dont-email.me>
References: <38eb5796@news.barak.net.il>
<116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>
<smgsjk$1esa3$1@news2.open-news-network.org>
<79fb7820-960d-42fe-bdd6-9208b32fb157n@googlegroups.com>
<snb2g1$tdu$1@dont-email.me>
<67467037-c7d9-41d6-85b1-a49d93c3f6f9n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 29 Nov 2021 19:37:11 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="15d65cdf00a00bdf0a8bb233b74e84b7";
logging-data="24917"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18szo5ECP4IprHqRxxlT6DzVBPutb72T0s="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:P4XMpEnwrP0c82agpWZHLYGAPWY=
In-Reply-To: <67467037-c7d9-41d6-85b1-a49d93c3f6f9n@googlegroups.com>
Content-Language: en-GB
 by: David Brown - Mon, 29 Nov 2021 19:37 UTC

On 29/11/2021 17:06, gnuarm.del...@gmail.com wrote:
> On Saturday, November 20, 2021 at 10:59:20 AM UTC-4, David Brown
> wrote:
>> On 20/11/2021 15:19, gnuarm.del...@gmail.com wrote:
>>> On Wednesday, November 10, 2021 at 12:39:22 PM UTC-4, Mike
>>> Perkins wrote:
>>>> On 09/11/2021 14:14, Vincent Li wrote:
>>>>> onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
>>>>>> I'm looking for checksum implementation in VHDL (or at
>>>>>> least the basic rules to build one). Regards Ron
>>>>> rip
>>>> Do you really mean checksum, or CRC?
>>>>
>>>> Checksum is easy to understand, CRC less so.
>>>>
>>>> I confess it's a long time since I used/looked up first
>>>> principles to generate CRCs and use this website:
>>>> https://www.easics.com/crctool/
>>>
>>> The only hard part to CRC is understanding the nomenclature.
>>> There are several options for computing CRCs based on polarity
>>> and direction. Specifying this is not consistent and often it is
>>> assumed that you know the "standard". With the combinations it
>>> can be very hard to get it right and be able to verify that. So
>>> by all means make sure you verify your results in the simplest
>>> medium you can before proceeding to anything more complex like
>>> coding.
>>>
>> That's what I usually see as a challenge for CRC's - getting
>> different implementations to agree. If you can use the same
>> implementation on all parts, then the details (bit ordering,
>> polarity, polynomial, etc.) don't matter. My usual solution is
>> using a lookup table of 256 entries. It's simple for 8-bit CRC's,
>> and not too difficult for 16-bit or 32-bit CRC's, and should be as
>> straightforward to make on an FPGA as it is in C, Python, or
>> whatever programming language takes your fancy. That makes it easy
>> to get matching results on multiple systems. But it would take a
>> bit more FPGA resources than a bit-wise linear feedback register.
>
> Meh... it still doesn't assure equivalent implementations. I did
> this just a year or so ago and had the hardest time with it because
> of all these details and the fact that there is no consistent
> nomenclature for it all. In FPGAs you think in terms of shifting
> bits and XORing stuff. The software implementations typically do the
> table lookup and twiddle things in ways that suit byte organizations
> rather than matching the algorithm/math description very much. Given
> it is important as to which bits you pick for your output and which
> way you shift the data and where the data enters the shifter... maybe
> I'm just getting old and the hair I no longer see on the outside is
> growing on the inside mucking up the works.
>
> In contrast I found LFSR to be very simple indeed, even if calculated
> 32 bits at a time and it always worked, matching other
> implementations.
>

I guess experience varies, and the algorithm you find simplest will
depend on that experience. The "best" algorithm will also depend on
whether your data is coming in as a bitstream, or in bytes, or larger
lumps, along with the size and speed requirements.

An 8-bit CRC done by table lookup involves a single 256-entry by 8-bit
wide table - for each incoming byte, you xor with the current CRC
register then look it up in the table to get the new CRC value. IIRC, a
32-bit CRC will involve 4 tables, each 256 entries of 32 bits, and
you'll have 4 xors, all of which can be done in parallel. I think that
to get the same performance in a bit-wise LFSR you'd need 32 of them
chained in a pipeline. (Correct me if that's wrong.)

Still, whichever way you implement the CRC, it's often best if you can
replicate the same algorithm at both ends - whether it be
software-friendly lookup tables in an FPGA, or FPGA-friendly LFSR's in
software. Then you don't need to worry about the different naming for
all the little details of bit ordering, inversion, etc.

Re: Cheacksum implementation in VHDL

<nnd$6c45ecb4$2a4bf242@a6926152578ae596>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=238&group=comp.arch.fpga#238

  copy link   Newsgroups: comp.arch.fpga
Newsgroups: comp.arch.fpga
From: me...@this.is.invalid (Stef)
Subject: Re: Cheacksum implementation in VHDL
References: <38eb5796@news.barak.net.il>
<116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>
<smgsjk$1esa3$1@news2.open-news-network.org>
<79fb7820-960d-42fe-bdd6-9208b32fb157n@googlegroups.com>
<snb2g1$tdu$1@dont-email.me>
Mail-Copies-To: nobody
User-Agent: slrn/1.0.3 (Linux)
Message-ID: <nnd$6c45ecb4$2a4bf242@a6926152578ae596>
Organization: Newsxs
Date: Tue, 30 Nov 2021 09:31:27 +0100
Path: i2pn2.org!i2pn.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe003.abavia.com!abp001.abavia.com!news.newsxs.nl!not-for-mail
Lines: 18
Injection-Date: Tue, 30 Nov 2021 09:31:27 +0100
Injection-Info: news.newsxs.nl; mail-complaints-to="abuse@newsxs.nl"
X-Received-Bytes: 1435
 by: Stef - Tue, 30 Nov 2021 08:31 UTC

On 2021-11-20 David Brown wrote in comp.arch.fpga:

>
> That's what I usually see as a challenge for CRC's - getting different
> implementations to agree. If you can use the same implementation on all
> parts, then the details (bit ordering, polarity, polynomial, etc.) don't
> matter. My usual solution is using a lookup table of 256 entries. It's

This site is very helpfull when trying to figure out which
implementation to use.
https://reveng.sourceforge.io/crc-catalogue/legend.htm

--
Stef

We are Microsoft. Unix is irrelevant. Openness is futile. Prepare
to be assimilated.

Re: Cheacksum implementation in VHDL

<fa5ccbed-9ce3-4f16-9a5a-ffd5c8ffad76n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=241&group=comp.arch.fpga#241

  copy link   Newsgroups: comp.arch.fpga
X-Received: by 2002:ac8:5712:: with SMTP id 18mr13704943qtw.584.1639595272969;
Wed, 15 Dec 2021 11:07:52 -0800 (PST)
X-Received: by 2002:a05:620a:131a:: with SMTP id o26mr9771523qkj.71.1639595272752;
Wed, 15 Dec 2021 11:07:52 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.fpga
Date: Wed, 15 Dec 2021 11:07:52 -0800 (PST)
In-Reply-To: <so3a57$oal$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=24.137.246.135; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 24.137.246.135
References: <38eb5796@news.barak.net.il> <116382e8-3114-4088-bd78-db0e345ae3a7n@googlegroups.com>
<smgsjk$1esa3$1@news2.open-news-network.org> <79fb7820-960d-42fe-bdd6-9208b32fb157n@googlegroups.com>
<snb2g1$tdu$1@dont-email.me> <67467037-c7d9-41d6-85b1-a49d93c3f6f9n@googlegroups.com>
<so3a57$oal$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <fa5ccbed-9ce3-4f16-9a5a-ffd5c8ffad76n@googlegroups.com>
Subject: Re: Cheacksum implementation in VHDL
From: gnuarm.d...@gmail.com (gnuarm.del...@gmail.com)
Injection-Date: Wed, 15 Dec 2021 19:07:52 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 99
 by: gnuarm.del...@gmail. - Wed, 15 Dec 2021 19:07 UTC

On Monday, November 29, 2021 at 3:37:16 PM UTC-4, David Brown wrote:
> On 29/11/2021 17:06, gnuarm.del...@gmail.com wrote:
> > On Saturday, November 20, 2021 at 10:59:20 AM UTC-4, David Brown
> > wrote:
> >> On 20/11/2021 15:19, gnuarm.del...@gmail.com wrote:
> >>> On Wednesday, November 10, 2021 at 12:39:22 PM UTC-4, Mike
> >>> Perkins wrote:
> >>>> On 09/11/2021 14:14, Vincent Li wrote:
> >>>>> onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
> >>>>>> I'm looking for checksum implementation in VHDL (or at
> >>>>>> least the basic rules to build one). Regards Ron
> >>>>> rip
> >>>> Do you really mean checksum, or CRC?
> >>>>
> >>>> Checksum is easy to understand, CRC less so.
> >>>>
> >>>> I confess it's a long time since I used/looked up first
> >>>> principles to generate CRCs and use this website:
> >>>> https://www.easics.com/crctool/
> >>>
> >>> The only hard part to CRC is understanding the nomenclature.
> >>> There are several options for computing CRCs based on polarity
> >>> and direction. Specifying this is not consistent and often it is
> >>> assumed that you know the "standard". With the combinations it
> >>> can be very hard to get it right and be able to verify that. So
> >>> by all means make sure you verify your results in the simplest
> >>> medium you can before proceeding to anything more complex like
> >>> coding.
> >>>
> >> That's what I usually see as a challenge for CRC's - getting
> >> different implementations to agree. If you can use the same
> >> implementation on all parts, then the details (bit ordering,
> >> polarity, polynomial, etc.) don't matter. My usual solution is
> >> using a lookup table of 256 entries. It's simple for 8-bit CRC's,
> >> and not too difficult for 16-bit or 32-bit CRC's, and should be as
> >> straightforward to make on an FPGA as it is in C, Python, or
> >> whatever programming language takes your fancy. That makes it easy
> >> to get matching results on multiple systems. But it would take a
> >> bit more FPGA resources than a bit-wise linear feedback register.
> >
> > Meh... it still doesn't assure equivalent implementations. I did
> > this just a year or so ago and had the hardest time with it because
> > of all these details and the fact that there is no consistent
> > nomenclature for it all. In FPGAs you think in terms of shifting
> > bits and XORing stuff. The software implementations typically do the
> > table lookup and twiddle things in ways that suit byte organizations
> > rather than matching the algorithm/math description very much. Given
> > it is important as to which bits you pick for your output and which
> > way you shift the data and where the data enters the shifter... maybe
> > I'm just getting old and the hair I no longer see on the outside is
> > growing on the inside mucking up the works.
> >
> > In contrast I found LFSR to be very simple indeed, even if calculated
> > 32 bits at a time and it always worked, matching other
> > implementations.
> >
> I guess experience varies, and the algorithm you find simplest will
> depend on that experience. The "best" algorithm will also depend on
> whether your data is coming in as a bitstream, or in bytes, or larger
> lumps, along with the size and speed requirements.
>
> An 8-bit CRC done by table lookup involves a single 256-entry by 8-bit
> wide table - for each incoming byte, you xor with the current CRC
> register then look it up in the table to get the new CRC value. IIRC, a
> 32-bit CRC will involve 4 tables, each 256 entries of 32 bits, and
> you'll have 4 xors, all of which can be done in parallel. I think that
> to get the same performance in a bit-wise LFSR you'd need 32 of them
> chained in a pipeline. (Correct me if that's wrong.)

I don't know what you mean about equivalent performance in a "bit-wise LFSR". Why are you conflating the two things? An LFSR can be done as many bits at a time as you wish.

> Still, whichever way you implement the CRC, it's often best if you can
> replicate the same algorithm at both ends - whether it be
> software-friendly lookup tables in an FPGA, or FPGA-friendly LFSR's in
> software. Then you don't need to worry about the different naming for
> all the little details of bit ordering, inversion, etc.

Sure, but different horses for different courses. What is best in an FPGA is not always best in software, etc. It's not hard to get the two ends working together as much as it is to find good reference data to test against to assure you are actually implementing the correct algorithm, correctly.

When you say "both ends", you do realize that often CRCs are used in standards where you are only working on one end and the other is existing equipment. Then you have to understand the terminology in all it's glory to get it right.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209


devel / comp.arch.fpga / Re: Cheacksum implementation in VHDL

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor