CRC von Ethernet Frame berechnen

[Prüfsummenherr (Gast)]

hi,

ich würde gerne die crc summe berechnen von meinem axi-stream ethernet 
frame

Der wird dieser Reihenfolge gesendet
Und Immer 64 Bit pro Takt

5a50dad0d1d2d3d4000000805152535400040003000200010008000700060005000c000b 
000a00090010000f000e000d00140013001200110018001700160015001c001b001a0019

Destination Adresse:
DAD0D1D2D3D4

Source Adresse:
5A5051525354

Type 8 ethernet type 0800

Beginnt mit Daten: 0000 0001 0002 0003



https://crccalc.com
/?crc=5a50dad0d1d2d3d400000080515253540004000300020001000800070006000500 
0c000b000a00090010000f000e000d00140013001200110018001700160015001c001b00 
1a0019&method=crc32&datatype=hex&outtype=0

Laut Simulation kommt da aber 0x00000000ca39b7c8 raus

Da muss ich sicherlich eine bestimmte Reihenfolge einhalten bei der 
Berechnung oder?

CRC-32 (IEEE 802.3)

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> Da muss ich sicherlich eine bestimmte Reihenfolge einhalten bei der
> Berechnung oder?

Da wuerd' ich mal schwer davon ausgehen. Deine 64bit Haeppchen scheinen 
mir ja ziemlich zusammengewuerfelt zu sein. CRC-Berechnungstools 
wollen's wohl lieber in der "richtigen" Reihenfolge.

Gruss
WK

[Duke Scarring (Gast)]

Ich habe immer gern mit dem Wireshark auf einem Host-PC nachgeschaut, ob 
die Prüfsumme richtig ist.
WIMRE ging das nur, wenn der 'promiscous mode' aktiv und 'CRC 
offloading' nicht aktiv war. Außerdem musste man im Wireshark noch ein 
Häckchen setzten, damit er die fehlerhaften Pakte farblich markiert 
(irgendwas mit FCS).
Damit ließ sich auch das eine Paket finden, wo die Prüfsumme mal falsch 
berechnet wurde. Außerdem sieht man, was als Prüfsumme erwartet wird.

Irgendiwe war da auch noch was mit Reihenfolge der Bits:
https://en.wikipedia.org/wiki/Ethernet_frame#Frame_check_sequence

Duke

[Dergute W. (derguteweka)]

Moin,

Duke Scarring schrieb:
> Ich habe immer gern mit dem Wireshark auf einem Host-PC nachgeschaut, ob
> die Prüfsumme richtig ist.

Das ist aber arg unzuverlaessig. Da muessen eben viele Haekchen 
"richtig" gesetzt sein, und alle HW zwischendrinnen "richtig" (d.h. auch 
Packerl mit falscher CRC weiterleiten, was nicht selbstverstaendlich 
ist) mitspielen.
Ist viel wahrscheinlicher, dass Pakete mit falscher CRC einfach so 
irgendwo rueckstandsfrei verdunsten...

Gruss
WK

[Prüfsummenherr (Gast)]

Habe hier mal eine xgmii Nachricht aus meiner Simulation.

Dort steht die generierte CRC-Summe am Ende:
0x678e60ee

Das hier ist die Nachricht:

015a0504030201da
002e2e0005040302
00260028002a002c
001e002000220024
00160018001a001c
000e001000120014
00060008000a000c
678e60ee00020004

Bin mir noch nicht sicher wie herum man CRC darauf anwenden muss.
Also folgendes klappt nicht:

## Adresse vorne:
015a0504030201da002e2e000504030200260028002a002c001e00200022002400160018 
001a001c000e00100012001400060008000a000c00020004

CRC-32
  0x9EFDE317   0xCBF43926   0x04C11DB7
CRC-32/BZIP2
  0xBA05A098   0xFC891918   0x04C11DB7

## Adresse hinten:
0002000400060008000a000c000e00100012001400160018001a001c001e002000220024 
00260028002a002c002e2e0005040302015a0504030201da

CRC-32
  0xCFEADAC2   0xCBF43926   0x04C11DB7
CRC-32/BZIP2
  0x128B2C75   0xFC891918   0x04C11DB7

Muss ich denn innerhalb der Nachrichten etwas umdrehen?

[Prüfsummenherr (Gast)]

Hier ist eine crc engine aus dem VHDL code, die zum Überprüfen eben 
genau dieser messages verwendet wird.
Soweit ich das verstanden habe...

[/code]

------------------------------------------------------------------------ 
------
   -- CRC engine
   ------------------------------------------------------------------------ 
------
   function calc_crc (
      size                             : in integer;
      data_in                          : in std_logic_vector;
      fcs                              : in std_logic_vector)
   return std_logic_vector is

      variable crc                     : std_logic_vector(31 downto 0);
      variable crc_feedback            : std_logic;

      type array_type is array (0 to 3) of std_logic_vector(7 downto 0);
      variable data                    : array_type;

   begin
      if size > 0 then
         data(0)                       := data_in(7 downto 0);
      end if;
      if size > 1 then
         data(1)                       := data_in(15 downto 8);
      end if;
      if size > 2 then
         data(2)                       := data_in(23 downto 16);
      end if;
      if size > 3 then
         data(3)                       := data_in(31 downto 24);
      end if;

      crc := not fcs;
      for J in 0 to size - 1 loop
         for I in 0 to 7 loop
            crc_feedback               := crc(0) xor data(J)(I);

            crc(4 downto 0)            := crc(5 downto 1);
            crc(5)                     := crc(6)  xor crc_feedback;
            crc(7 downto 6)            := crc(8 downto 7);
            crc(8)                     := crc(9)  xor crc_feedback;
            crc(9)                     := crc(10) xor crc_feedback;
            crc(14 downto 10)          := crc(15 downto 11);
            crc(15)                    := crc(16) xor crc_feedback;
            crc(18 downto 16)          := crc(19 downto 17);
            crc(19)                    := crc(20) xor crc_feedback;
            crc(20)                    := crc(21) xor crc_feedback;
            crc(21)                    := crc(22) xor crc_feedback;
            crc(22)                    := crc(23);
            crc(23)                    := crc(24) xor crc_feedback;
            crc(24)                    := crc(25) xor crc_feedback;
            crc(25)                    := crc(26);
            crc(26)                    := crc(27) xor crc_feedback;
            crc(27)                    := crc(28) xor crc_feedback;
            crc(28)                    := crc(29);
            crc(29)                    := crc(30) xor crc_feedback;
            crc(30)                    := crc(31) xor crc_feedback;
            crc(31)                    :=             crc_feedback;
         end loop;
      end loop;

   -- return the CRC result
      return not crc;
   end calc_crc;
[code]

[Dergute W. (derguteweka)]

Moin,

Hier ist eine aehnlich gelagerte Problemstellung mit Beispiel:

Beitrag "CRC berechnung eines Ethernet-Frames in C"

Wenn ich aus deinem Beispiel:

Prüfsummenherr schrieb:
> Das hier ist die Nachricht:
>
> 015a0504030201da
> 002e2e0005040302
> 00260028002a002c
> 001e002000220024
> 00160018001a001c
> 000e001000120014
> 00060008000a000c
> 678e60ee00020004

Diese Commandline zusammenkloppe:

reveng -m CRC-32 -c da01020304055a0102030405002e2e002c002a00280026002400220020001e001c001a00180016001400120010000e000c000a000800060004000200

kommt das raus:

ee608e67

Koennte also passen.(Mit den ueblichen Drehereien)

Gruss
WK

[Prüfsummenherr (Gast)]

Dergute W. schrieb:
> Gruss
> WK

Danke das war sehr wichtig :D
...


reveng -m CRC-32 -c
wollte ich gestern das erste mal testen.
Habe mir das Programm runtergeladen.
Dann versucht das in der console auszuführen.
Habe aber ubuntu keine ahnung ob es damit geht.

s/reveng-3.0.2$ reveng -m CRC-32 -c da01020304055a0102030405002e2e002c002a00280026002400220020001e001c001a00180016001400120010000e000c000a000800060004000200

reveng: command not found


reveng-3.0.2$ ls
bin       config.h  Mk.ARMTube  model.c   relink.pl   reveng.rc
bmpbit.c  contrib   Mk.RISCOS   poly.c    reveng.c    RISCOSify
CHANGES   COPYING   Mk.ROSGCC   preset.c  reveng.h    tomtorfs-wrapper
cli.c     Makefile  Mk.Win32    README    reveng.ico

Habe gerade auch mal make eingetippt aber das geht auch nicht

reveng-3.0.2$ sudo make
gcc -O3 -Wall -ansi -fomit-frame-pointer -DPRESETS -DBMPTST -o bmptst bmpbit.c
( ./bmptst && touch bmptst ) || ( rm bmptst bmptst.exe && false )
reveng: configuration fault.  Update config.h with these definitions and recompile:
  #define BMP_BIT   64
  #define BMP_SUB   32
rm: cannot remove 'bmptst.exe': No such file or directory
make: *** [Makefile:88: bmptst] Error 1

Da steht man soll config.h updaten

[Prüfsummenherr (Gast)]

Wie hast du das eigentlich so schnell hinbekommen?!


da01020304055a0102030405002e2e002c002a00280026002400220020001e001c001a00 
180016001400120010000e000c000a000800060004000200

[Pete K. (pete77)]

Prüfsummenherr schrieb:
> reveng-3.0.2$ ls
> bin       config.h  Mk.ARMTube  model.c   relink.pl   reveng.rc
> bmpbit.c  contrib   Mk.RISCOS   poly.c    reveng.c    RISCOSify
> CHANGES   COPYING   Mk.ROSGCC   preset.c  reveng.h    tomtorfs-wrapper
> cli.c     Makefile  Mk.Win32    README    reveng.ico

Schau mal, ob in ./bin ein "reveng" enthalten ist.
Dann kannst Du mit der expliziten Pfadangabe ./bin/reveng  arbeiten.

[Prüfsummenherr (Gast)]

ne aber andere programme geben ja das gleiche zurück :D

https://emn178.github.io/online-tools/crc32.html
https://crccalc.com/

Mich würde interessieren wie du diese Nachricht so schnell umgeordnet 
hast.
Hast du das manuell gemacht?

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> Da steht man soll config.h updaten

jepp. Ist etwas vorsintflutlich. Nachdem ich das bei mir geaendert 
hatte, lief make auch durch. Ist wohl so n 64bit-system-ding.

Prüfsummenherr schrieb:
> Mich würde interessieren wie du diese Nachricht so schnell umgeordnet
> hast.
> Hast du das manuell gemacht?
<schaem>Ja, mehr oder weniger tatsaechlich von Hand 
eingetippert.</schaem>
Um ein fancy tool zu schreiben oder zu suchen war's mir dann doch zu 
wenig Daten und morgens ist die Motivation auch noch da.

Gruss
WK

[Prüfsummenherr (Gast)]

Dergute W. schrieb:
> <schaem>Ja, mehr oder weniger tatsaechlich von Hand
> eingetippert.</schaem>

naja immerhin hast du damit meinen Tag gerettet.

Dergute W. schrieb:
> jepp. Ist etwas vorsintflutlich. Nachdem ich das bei mir geaendert
> hatte, lief make auch durch. Ist wohl so n 64bit-system-ding

ok ich teste das bald mal

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> naja immerhin hast du damit meinen Tag gerettet.

Dann musste ja jetzt "nur noch" das Erzeugen/Verarbeiten der zig 
Gigabit/sec Daten im Griff haben; und schon ist's fertig :-)

Gruss
WK

[Prüfsummenherr (Gast)]

Dergute W. schrieb:
> Moin,
>
> Prüfsummenherr schrieb:
>> naja immerhin hast du damit meinen Tag gerettet.
>
> Dann musste ja jetzt "nur noch" das Erzeugen/Verarbeiten der zig
> Gigabit/sec Daten im Griff haben; und schon ist's fertig :-)
>
> Gruss
> WK


* Wie ist das eigentlich,  wenn man nicht alle Frame Daten aufeinmal zur 
Verfügung hat?

* Denn ich lasse mir diese (aus Testgründen) stückweise generieren.
Dabei lasse ich mir immer 64 Bit generieren.

* Soll man die dann alle speichern und dann erst CRC berechnen?

* Oder kann man auch nach und nach CRC berechnen und dann ein Gesamt-CRC 
erhalten?

* Mein MAC hat im default Modus auch immer hinten noch eine CRC Summe in 
seinem XGMII Frame..
* Der muss das doch auch irgendwie hinbekommen.




______________________________________________


Nur noch als Zusatz ... Wiki crc32 in C Ethernet...(Ist ausführbar und 
denke korrekt. Aber man versteht den Code nicht xD )

#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>

#define CRC32MASKREV   0xEDB88320            /* CRC-32 Bitmaske, umgekehrte Bitfolge */

int      bitstream[] = { 1,0,0,0,0,1,1,0 };  /* ASCII-"1", LSB zuerst */
int      bitcount    = 8;
uint32_t crc32_rev   = ~0;                   /* Schieberegister, Startwert (111...) */

int main(void)
{
    int i;
    for (i = 0; i < bitcount; i++)
    {
        if ((crc32_rev & 1) != bitstream[i])
            crc32_rev = (crc32_rev >> 1) ^ CRC32MASKREV;
        else
            crc32_rev = (crc32_rev >> 1);
    }
   // printf("0x%08X\n", crc32_rev);
    printf("0x%08X\n", ~crc32_rev);          /* inverses Ergebnis, MSB zuerst */
    return EXIT_SUCCESS;
}

[Fitzebutze (Gast)]

Prüfsummenherr schrieb:
> * Oder kann man auch nach und nach CRC berechnen und dann ein Gesamt-CRC
> erhalten?

Man kann, zu jeder CRC gibt es eine serialisierte Version, die lässt 
sich in beliebig grosse Happen aufteilen.

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> * Wie ist das eigentlich,  wenn man nicht alle Frame Daten aufeinmal zur
> Verfügung hat?

Dann muss man den CRC auch nicht berechnen.
CRC Berechnung passiert normalerweise, waehrend der MAC schon das 
Packerl ausgibt. Und wenn der MAC das Frame ausgibt, dann gibts kein 
Halten mehr, dann muessen mit jedem Takt Daten kommen...

Prüfsummenherr schrieb:
> Aber man versteht den Code nicht xD
man != du :-)

Das sieht mir nach einer bitseriellen Version von CRC aus. Das ist immer 
die simpelste Moeglichkeit: Mit so einem Schieberegister mit XOR 
Rueckkopplungen.
Erst wenn man dann immer mehr als 1 Bit pro Takt berechnen will (z.b. 8 
oder gar 32...), blaeht sich diese simple Schaltung etwas auf...

Aber warum machst du so'ne Wallung um den CRC? Wenn du nicht selbst den 
Code des Generators schreiben musst, dann bau's doch einfach so ein, wie 
der Herr Xilinx sich das so gedacht hatte.

Gruss
WK

[Prüfsummenherr (Gast)]

Habe gerade die binäre Polynomdivision noch mal angeschaut..
also der Teiler wird immer bis zur ersten 1 geschoben und dann gexort.

Ja habe jetzt schon in meinen generierten Ethernet-Frames Platz gemacht 
für eine eigene crc Summe!
Dort steht aktuell noch ein dummy drin..
0xabcdabcd.
Würde den jetzt schon gerne richtig füllen.

Habe nur noch keine passende CRC Umsetzung gefunden,, die ich 
einigermaßen testen konnte. Bzw. bin hoffentlich kurz davor...
z.B. das ist für crc 8 ... ist glaube ich auch seriell.

https://vhdlguru.blogspot.com/2015/11/part-2-vhdl-code-for-cyclic-reduntancy.html
_____________________________________________________

Hier wird ein crc Register beschrieben :
http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html
Vielleicht kann man dieses Konstrukt einfach  unendlich lange 
durchführen.
Denn das crc Register bleibt ja gleich.

Hier eine schlechte Beschreibung:
________________________________

Dort wird die Nachricht immer reingeschoben, bis links eine 1 rauskommt.
ist das der Fall. wird das Register gexort mit dem crc Polynom.
Die ersten 8 Byte bleiben dann im Register und werden wieder 
weitergeschoben.
Solange bis es nichts mehr zum weiterschieben gibt.


Dann wird weitergeschoben.

1. CRC-8 register initialized with 0.
         --- --- --- --- --- --- --- ---
        | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |  <-- b1100001000000000
         --- --- --- --- --- --- --- --- 
4. Left-Shift register. MSB 1 pops out:
         --- --- --- --- --- --- --- ---
   1 <- | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 |  <-- b0000000
         --- --- --- --- --- --- --- ---
5. Left-Shift register. MSB 1 pops out: b100110010 ^ b100011101 = b000101111 = 0x2F:
         --- --- --- --- --- --- --- ---
        | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 |  <-- b000000
         --- --- --- --- --- --- --- ---
         
         --- --- --- --- --- --- --- ---
        | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |   <-- <empty>
         --- --- --- --- --- --- --- ---

[Dergute W. (derguteweka)]

Moin,

Mir ist grad etwas unklar, was du da vorhast, und ob und welche Probleme 
du dabei hast.

Gruss
WK

[Prüfsummenherr (Gast)]

ah ok in der tb von 
https://vhdlguru.blogspot.com/2015/11/part-2-vhdl-code-for-cyclic-reduntancy.html

gibt es mind. 2 Tests für crc8

Bei dem ersten Test wird 0x78 nacheinander bitweise reingeschickt

Und nach ein paar Takten kommt dann 0x6F raus -- also wenn das Flag crc 
auch high ist.

Ich glaube ich brauche das ganze nur viel größer.

[Prüfsummenherr (Gast)]

Problem:

Ich soll in meine Ethernetframe hinten noch eine selbst berechnete CRC 
anhängen.

Der MAC soll keine eigene berechnen.
Wenn ich die Nachricht dann wieder per loopback empfange soll ich prüfen 
ob crc korrekt war.

(generate crc) AXI-> TX MAC -> loopback xgmii  ---|
(check    crc) AXI <-RX MAC <---------------------|

Habe bereits 4 Byte Platz gemacht um CRCs passend dranzuhängen.
Jetzt müssen es nur noch richtige CRCs sein.

Als ersten Test reicht natürlich ein CRC Beispiel-Code.
So einen bin ich gerade am Suchen und Testen :P

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> Ich soll in meine Ethernetframe hinten noch eine selbst berechnete CRC
> anhängen.

Dann wirst du wohl sowas von dem Kaliber brauchen, was du am 27.04.2022 
07:49 gepostet hast.

Gruss
WK

[Prüfsummenherr (Gast)]

Dergute W. schrieb:
> 07:49 gepostet hast

ah das war aus der 10GEMAC Testbench.
Müsste mir das noch mal anschauen.

_____________
...

https://github.com/gardners/c65gs/blob/master/crc.vhdl

Das hatte ich vorhin auch schon probiert aber nicht verstanden.
Habe einen Input und da sollte nach ein paar clks mein crc wert 
kommen... sehe ich aber nie..

Dort können aber auch immer nur 8 Bit rein.
Was aber vielleicht nicht schlimm ist.

[Prüfsummenherr (Gast)]

Ah habe gerade die nicht mehr vorhandene xapp209.pdf von xilinx 
gefunden.
Dort müsste es hinweise dazu geben.

[Prüfsummenherr (Gast)]

Ok habe mir die Diagramme in der Anleitung angeschaut und dann so lange 
getestet bis eine Konversion nach CRC stattfindet
https://crccalc.com/
Damit habe ich immer gegengeprüft
Der Wert ist aber nur in der Zeile "CRC-32/MPEG-2" ersichtlich.

In der Anleitung ist noch die Rede von einem Perl Script, das man für 
weitere Umwandlungen benötigt...

Aber für meine Zwecke sollte es völlig ausreichend sein CRC-32/MPEG-2 zu 
verwenden. Was auch immer das ist!

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> Aber für meine Zwecke sollte es völlig ausreichend sein CRC-32/MPEG-2 zu
> verwenden. Was auch immer das ist!

Das ist der CRC, mit dem im MPEG Transportstream die Tabellen (z.b. PAT, 
PMT, ...) gesichert sind. Scheint mir aber eine andere 
Geschmacksrichtung CRC zu sein als bei Ethernet.
Aber: whatever floats your boat...

Gruss
WK

[Prüfsummenherr (Gast)]

Ich wollte gerade diesen Generator in mein Design einfügen..
Aber merke ,dass diese 8 Bit pro Takt irgendwie zu wenig sind.
Ich generiere ja 64 Bit pro Takt.

Dann müsste ich ja etwa 8 Takte warten bis die Bytes verrechnet wurden 
xD

Irgendeine Idee was man da gewöhnlich macht?

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> Irgendeine Idee was man da gewöhnlich macht?

Das Selbe, was man schon gemacht hat, um vom bitseriellen CRC auf einen 
byteseriellen CRC zu kommen: parallelisieren.
Was dann noch dazukommt: Die Sonderfaelle, wenn deine Packerl nicht 
Vielfache von 64 bit lang sind.
Aber da gibts doch sicher irgendwas fertiges fuer Ethernet, da musste 
doch nix selber machen - oder ist das ne Hausaufgabe oder sonst 
irgendwas rein theoretisches?

Gruss
WK

[Prüfsummenherr (Gast)]

Danke :)

Dergute W. schrieb:
> oder ist das ne Hausaufgabe oder sonst


Ja xD. D.h. deine Vermutung ist richtig!

Eine CRC-Prüfung wäre gut. Vor dem MAC. Wenn ich keinen vorhandenen Core 
finde, oder ich das selber nicht hinbekomme, muss der Xilinx MAC das 
eben machen.

Die Konfiguration die ich gestern getestet habe, arbeitet ja bereits mit 
8-Bit!
Muss LSFR besser verstehen und die Parallelisierung nachvollziehen.

Ungefähr sowas:

https://www.infineon.com/dgdl/Infineon-AN1089_Parallel_Cyclic_Redundancy_Check_(CRC)_for_HOTLink-ApplicationNotes-v04_00-EN.pdf?fileId=8ac78c8c7cdc391c017d073b6df65f6c

When used with high-speed serial data, especially data
which is encoded in the serial domain, it becomes quite
difficult to implement the CRC calculations using a shift
register. However, it is possible to convert a serial
implementation into a parallel form that accumulates
multiple bits in each clock cycle

[Prüfsummenherr (Gast)]

Das bekommen wir doch locker hin.

(...)But very few engineers understand the mechanics of the
CRC well enough to build a customized parallel CRC
circuit described by an arbitrary CRC generator polyno-
mial. What about you?

http://outputlogic.com/my-stuff/parallel_crc_generator_whitepaper.pdf

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> Eine CRC-Prüfung wäre gut. Vor dem MAC.

Nee, waere sie nicht. Weil dann die Daten 2x angefasst werden muessen. 
Hat schon einen Grund, warum das normalerweise im MAC gemacht wird.

Prüfsummenherr schrieb:
> muss der Xilinx MAC das
> eben machen.
Ja. Dafuer ist der gemacht.

Prüfsummenherr schrieb:
> Das bekommen wir doch locker hin.

Wer ist wir? Ich bin raus; ich hab mir das erst vor ein paar Jahren mal 
mit'm BCH Code, der bei SDI die Audiosamples absichert, angetan. War 
prinzipiell die selbe Shice; musste nur auf 4x parallelisieren. Hat aber 
wenigstens den IP-Core gespart. Und ich kann derweilen den Aufwand fuer 
sowas einschaetzen. ;-)

Du bist da mit deinen Literaturlinks schon auf dem richtigen Weg, aber 
ich kann dir nur davon abraten, da selber was zusammenzustupfeln. Die 
CRC Parallelisierung von 1bit auf 8bit ist noch "relativ simpel", weil 
deine Packerl ja immer vielfache von 8bit (=1Byte) sind. Wenn du aber 
weiter parallelisierst, dann musst du die Sonderfaelle von "krummen" 
(z.b. 65 byte) Paketlaengen abfangen; das macht das ganze sicher nicht 
einfacher.
Ich seh' da ueberhaupt keinen Sinn drinnen, das "zu Fuss" unbedingt 
machen zu wollen.
Wenn du einen passenden Gabelschluessel (XilinxMAC) hast, ziehst du 
Muttern auch nicht mit der Zange an.

Gruss
WK

[Strubi (Gast)]

Zur Parallelisierung hilft einfaches 'Fuzzing', bzw. N-mal aufrufen und 
aufzeichnen, welches Bit beim XOR-Tanz mitmacht, siehe 
https://github.com/hackfin/myhdl.v2we/blob/master/examples/crc.ipynb

Um's als Core-Generator zu nutzen, muss man den zugehoerigen Binder 
starten (siehe README).

[Prüfsummenherr (Gast)]

Dergute W. schrieb:
> Ich seh' da ueberhaupt keinen Sinn drinnen, das "zu Fuss" unbedingt
> machen zu wollen.

Xilinx hat ja extra diese Option drin CRC Generieung beim MAC 
auszuschalten.
Dann gibt es bestimmt Situationen in denen man CRC schon vorher macht 
oder?

Dergute W. schrieb:
> Weil dann die Daten 2x angefasst werden muessen.
> Hat schon einen Grund, warum das normalerweise im MAC gemacht wird.

Oh Mist ok...

Strubi schrieb:
> Zur Parallelisierung hilft einfaches 'Fuzzing', bzw. N-mal aufrufen und
> aufzeichnen, welches Bit beim XOR-Tanz mitmacht, siehe
> https://github.com/hackfin/myhdl.v2we/blob/master/examples/crc.ipynb
>
> Um's als Core-Generator zu nutzen, muss man den zugehoerigen Binder
> starten (siehe README).

Hmm.
Also N-Mal aufrufen?
Dort beim Link ist ganz unten ein VHDL Code von einem seriellen CRC32.
Aber weiter verstehe ich das ganze noch nicht xD.

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> Dann gibt es bestimmt Situationen in denen man CRC schon vorher macht
> oder?

Keine Ahnung. Vielleicht fuer irgendwelche Tests/Simulationen, oder wenn 
man im FPGA aus irgendwelchen Gruenden ein Ethernetpackerl "einfach nur 
so durchreichen" muss - so primitivswitchartig.

Prüfsummenherr schrieb:
> Also N-Mal aufrufen?
Jepp.

> Dort beim Link ist ganz unten ein VHDL Code von einem seriellen CRC32.
> Aber weiter verstehe ich das ganze noch nicht xD.
Der ist eben schon auf 8bit Datenbreite parallelisiert; guckstu:

din : in unsigned(7 downto 0);

Wenn der bitseriell waere, waere er viel kuerzer.

Gruss
WK

[Prüfsummenherr (Gast)]

>
> Prüfsummenherr schrieb:
>> Also N-Mal aufrufen?
> Jepp.

Muss ich erst noch verstehen inwiefern.

Aber ok pro Takt möchte anstatt 1Bit oder parallel 8 Bit,,
  64 Bit berechnen.

>> Dort beim Link ist ganz unten ein VHDL Code von einem seriellen CRC32.
>> Aber weiter verstehe ich das ganze noch nicht xD.
> Der ist eben schon auf 8bit Datenbreite parallelisiert; guckstu:din : in
> unsigned(7 downto 0);
> Wenn der bitseriell waere, waere er viel kuerzer.
>
> Gruss
> WK

ah der kam mir so bekannt vor wie bei
https://github.com/gardners/c65gs/blob/master/crc.vhdl



Strubi schrieb:
> Um's als Core-Generator zu nutzen, muss man den zugehoerigen Binder
> starten (siehe README).

Was bedeutet Core-Generator?

Kann ich damit etwas auch größere Bitlängen wählen?
Dafür müsste ich die "bindings" verstehen :D xD

[Prüfsummenherr (Gast)]

Xilinx hat da auch erst ihre Formeln berechnet mit Perl.
Mal schauen.
Hab mal eines im Anhang..
Hab das von http://en.verysource.com/code/114466_1/crcgen.pl.html

"The algorithm involves looping to simulate the shifting, and concatenating
strings to build the equations after "n" shifts. The Perl script crcgen.pl uses this algorithm to
generate next-state equations for CRC-32 registers 

...

The usage of the crcgen.pl Perl script is quite simple. The command-line options are shown
below.
Usage: crcgen.pl [-crcwidth <width:8,12,16,32>] [-inputwidth <width:1...32>]
[-poly <polynomial>][-crcint <init:preset, reset>], [-h] <outfile>

[Tim (Gast)]

Prüfsummenherr schrieb:
> Muss ich erst noch verstehen inwiefern.
>
> Aber ok pro Takt möchte anstatt 1Bit oder parallel 8 Bit,,
>   64 Bit berechnen.

N mal aufrufen ist nicht unbedingt die cleverste Art einen parallelen 
CRC-Generator zu bauen.

.. aber du warst doch schon nah dran.
Auf outputlogic.com gibt es einen CRC Generator mit beliebiger 
Datenbreite. Der ist doch prima dafür geeignet.

[Prüfsummenherr (Gast)]

Tim schrieb:
> Auf outputlogic.com gibt es einen CRC Generator mit beliebiger
> Datenbreite. Der ist doch prima dafür geeignet.

Ah man... das hätte ich schon vorher finden müssen.

Einfach aus Prinzip xD

Vielen Dank dafür - werde ich auch gleich mal testen.
______________________________________

Nur mal aus Interesse bei dem Xilinx Perl script:

 perl crc.pl

Funktioniert und generiert einen Verilog 8 Bit parallel CRC
..
Aber wenn ich die Flags verwende kommt ein Fehler xD

sudo perl crc.pl -inputwidth 8

==> Undefined argument in option spec

nochmal der Link:
http://en.verysource.com/code/114466_1/crcgen.pl.html

[Dergute W. (derguteweka)]

Moin,

Prüfsummenherr schrieb:
> Muss ich erst noch verstehen inwiefern.
>
> Aber ok pro Takt möchte anstatt 1Bit oder parallel 8 Bit,,
>   64 Bit berechnen.

Naja, du nimmst eben den 1bit breiten CRC und fuellst da in 64 takten 64 
bit seriell rein. Dabei guckst du nach jedem Takt ganz scharf auf dein 
Schieberegister und stellst dabei fest welche Bits da jeweils drinnen 
rumhampeln.
Nach 64 Takten kannst du dann genau sehen, aus welchen urspruenglichen 
Bits sich der CRC zusammensetzt.
So entsteht so zeugs wie: crc32_opencores.vhd

Prüfsummenherr schrieb:
> Was bedeutet Core-Generator?
Das ist irgendein Stueck Software, wo "hinten" ein Stueck andere 
Software - hier z.b. der VHDL code fuer einen CRC Generator rausfaellt.

Tim schrieb:
> N mal aufrufen ist nicht unbedingt die cleverste Art einen parallelen
> CRC-Generator zu bauen.
Zur Laufzeit sicher nicht, aber fuer die Entwicklung von sowas schon.


Gruss
WK

[Prüfsummenherr (Gast)]

oh vielen Dank!

Dergute W. schrieb:
> Naja, du nimmst eben den 1bit breiten CRC und fuellst da in 64 takten 64
> bit seriell rein. Dabei guckst du nach jedem Takt ganz scharf auf dein
> Schieberegister und stellst dabei fest welche Bits da jeweils drinnen
> rumhampeln.

Sehr interessant!
Danke dafür.
______________________________________________________

Habe außerdem den OutputLogic.com generierten Code mal getestet und 3x 
64-Bit Daten hintereinander eingespeißt.
0x2222222222222222 0x2222222222222223 0x2222222222222224

In einem Register steht immer der aktuelle CRC Wert:
0xc423648e

und habe es mit crccalc.com geprüft
CRC-32/MPEG-2
  0xC423648E   0x0376E6E7   0x04C11DB7
___________________________________

Ich hoffe, dass ich damit diese Aufgabe erst mal abhaken kann..

[Strubi (Gast)]

Prüfsummenherr schrieb:
>
> Was bedeutet Core-Generator?
>

Ein Programm, was dir einen IP-Core oder HDL generiert.

Der unten ausgegebene VHDL-Code ist das parallelisierte Resultat, auf 
das kommt man in der Tat nur allgemeingueltig (fuer beliebige Polynome), 
wenn man die serielle LFSR-Beschreibungsfunktion der Bitbreite 
entsprechend wiederholt  aufruft. Genau das macht der Python-Code im 
Jupyter Notebook beim durchspulen ('>>') entsprechender Parameter. 
Optimieren ueberlaesst man dem Synthesetool, die Parameter musst du aber 
korrekt waehlen (insbesondere Polynom und Resetwert).

> Kann ich damit etwas auch größere Bitlängen wählen?

Damit also ja.

> Dafür müsste ich die "bindings" verstehen :D xD

Wenn du Binder meinst: Das ist einfach ein Dienst fuer eine virtuelle 
Maschine, in der alles Noetige installiert ist, um die Jupterlab-IDE 
rattern zu lassen, also: README aufrufen, Knopf klicken, warten bis 
gestartet.