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)
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
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
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
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?
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:
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.
Wie hast du das eigentlich so schnell hinbekommen?!
da01020304055a0102030405002e2e002c002a00280026002400220020001e001c001a00
180016001400120010000e000c000a000800060004000200
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.
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
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
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
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 )
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.
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
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.
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.
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.
1
(generatecrc)AXI->TXMAC->loopbackxgmii---|
2
(checkcrc)AXI<-RXMAC<---------------------|
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
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
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.
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!
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
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?
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
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
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).
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.
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:
1
din : in unsigned(7 downto 0);
Wenn der bitseriell waere, waere er viel kuerzer.
Gruss
WK
>> 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.vhdlStrubi 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 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.
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:
1
perlcrc.pl
Funktioniert und generiert einen Verilog 8 Bit parallel CRC
..
Aber wenn ich die Flags verwende kommt ein Fehler xD
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
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..
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.