Hallo Leute,
ich bin ganz neu im bereich FPGA bzw VHDL unterwegs.
Ich habe schon ein paar "Sachen" geschrieben u.A. das senden und
empfangen über einen UART (Byte-weise).Jetzt würde ich aber gerne über
den FPGA eine Protokoll parsen das ich über den UART empfange.
Sprich Adresse, Datenlänge, Datenpacken, CRC,... aus einem unendlichen
Stream identifizieren.
Kann mir für solch ein Aufgabe jemand ein Beispiel zeigen an dem ich
mich langhangeln kann?
Vielen Dank
Für das Protokoll oder dessen einzelne Schichten muss man sich
entsprechende Zustandsdiagramme malen und kann diese dann recht direkt
in Hardware gießen. In den funktionalen Spezifikationen vieler
Protokolle finden man auch schon solche Zustandsdiagramme.
Wichtig ist dabei vor allem die Fehlerbehandlung, die unerlässlich ist,
um sich bei beschädigten Datenpaketen wieder aufsynchronisieren zu
können.
Andreas hat schon den richtigen Tip gegeben:
Zustandsautomaten im engl. Final-State-Maschine (FSM) sind die Lösung.
Wenn das Protokoll nicht allzu kompliziert ist, bekommst Du das recht
einfach hin. Wie Andreas schon sagte, vergiss nicht die FSM so zu
schreiben dass sie auch bei verlorenen Paket nicht hängenbleibt.
Bei sowas langsamen wie UART und bei komplexeren Protokollen kann das
auch per Software in einem Picoblaze oder Microblaze machen. Das ist
aber Geschmackssache.
Ich komme aus der Hardware und hätte es bis vor kurzem komplett dort
drin gemacht. Stelle aber gerade ein Projekt auf Zynq um und muss sehen
dass man auch mit Software und guten IP Cores machen kann und die
Wiederverwendbarkeit sowie die Debugmöglichkeiten schon sehr gut sind.
Wenn ich so dran denke, ich hatte mal ein SPI und I2C Protokoll in VHDL
implementiert wo jeder unterschiedliche Chip so seine Macken hatte und
wie lange ich gebraucht habe dieses in EIN VHDL Modul zu stricken...
Heute ist man schlauer.
Freddy
Zu dem Thema hängenbleiben der FSM:
Wenn der Sender kontinuierlich sendet kannst Du die FSM auch mit einem
Watchdog resetten. D.h. wenn die FSM in einem State hängenbleibt wird
sie irgendwann automatisch zurückgesetzt.
Ist eigentlich recht einfach. Wenn der Sender nicht kontinuierlich
sendet wird es schon komplizierter. Zumindest wenn Du keine Daten
verlieren darfst.
Hallo, also mein Problem war immer, dass man irgendwie den Anfang und
das Ende eines Paketes erkennen möchte. Dazu will man irgendeine
eindeutige Bitfolge verwenden die nicht in den Nutzdaten vorkommen kann.
Und genau das ist eben schwierig.
Gelöst habe ich das so, dass jedes Byte ein feste reserviertes Bit hat
das aussagt ob es ein Paketanfang ist oder nicht. Bei mir ist das
niederwertigste Bit jedes Bytes 0 ausser es ist ein Paketanfang, da ist
es 1. Ja damit verliere ich Nutzdatenrate aber das ist eben ein
Kompromiss. Dafür ist es eben so sehrviel einfacher in Hardware zu
beschreiben wie wenn da jetzt Escaping und alles drinnen wäre.
Hallo,
das hatte schon jemand als Problem gehabt und hat die escape sequenzen
erfunden.
z.B. Start = 0xaa, Stop = 0x55 Escape 0xD3
Nutzdaten 0xaa 0xD3 0x55
gesendet
0xaa 0xD3 0xaa 0xD3 0xD3 0xD3 0x55 0x55
MfG
ich
>Sprich Adresse, Datenlänge, Datenpacken, CRC,... aus einem unendlichen>Stream identifizieren.>Kann mir für solch ein Aufgabe jemand ein Beispiel zeigen an dem ich>mich langhangeln kann?
Ich hätte da ein Beispiel.
Im Huffman decoder werden die Bildanfänge und Enden und die
Quantsierungstabellen aus dem Datenstrom herausgefiltert.
http://opencores.org/project,huffmandecoder
Freddy schrieb:> Final-State-Maschine (FSM)
Es gibt einen wahrnehmbaren Unterschied zwischen einem "Endgültigen
Zustandsautomaten" und einen "endlichen Zustandsautomaten". Deshalb ist
die Verlängerung von FSM eben auch "Finite State Machine"...
Lothar M. schrieb:> Freddy schrieb:> Final-State-Maschine (FSM)>> Es gibt einen wahrnehmbaren Unterschied zwischen einem "Endgültigen> Zustandsautomaten" und einen "endlichen Zustandsautomaten". Deshalb ist> die Verlängerung von FSM eben auch "Finite State Machine"...
Wobei es oft vorkommt, dass man eine final state machine
baut...jedenfalls bei mir :/
Naja, in der theoretischen Informatik ist es ja auch nur wichtig, dass
der Automat in einem Endzustand landet. Wie der dahin gekommen ist,
interessiert keinen... Ganz im Gegensatz zu den HW-Leuten...
Also ich dachte mir das so,
von meinem UART bekomme ich bereits die Daten als 8 Bit std_logic_vector
geliefert. Diese Bytes würde ich gerne in eine Art Parser schicken um
die Nutzdaten heraus zu filtern
Mein "Protokoll" sollte in etwa so aussehen:
1. Byte: 0x0a = Start
2. Byte: 0x0x Datenbyte: 1 Nibbel (also ein halbes Byte) 0x01 bis 0x08
für 1 bis 8 Datenbyte
3. Byte bis max. 11 Byte: Nutzdaten (je nachdem was das Datennibbel sagt
wie lang ;-)
letztes Byte: 0x50 = Ende
Ich tue mich momentan noch extrem schwer mit VHDL und dem parallelem
denken... ich habe mehrere Tage gebraucht, bis mein UART mir Daten
lieferte und die empfangenen Daten auf 8 LEDs ausgab...
Ich wäre für jede Hilfe dankbar!
Georg A. schrieb:> Naja, in der theoretischen Informatik ist es ja auch nur wichtig, dass> der Automat in einem Endzustand landet. Wie der dahin gekommen ist,> interessiert keinen... Ganz im Gegensatz zu den HW-Leuten...
Das ist komplett falsch: In der T.I. ist der Endzustand
extrem interessant, z.B. beim Erkennen von regulären
Ausdrücken etc.. Und wie der Automat dahin gekommen ist,
erst recht.
Aber zum Problem: Das obige Problem lässt sich mit einer
FSM nur zum Teil lösen. Wenn bei obigen Protokoll die
FSM aus dem Tritt kommt, dann muss man auch die Quelle
und das Ziel (d.h. die FSM) entsprechend anpassen, z.B.
durch ein/mehrphasiges Handshake-Protokoll. Aber totale
Sicherheit gibt's bei Protokollen iA nicht.
FPGA <= NULL schrieb im Beitrag #4434330:
> Ich tue mich momentan noch extrem schwer mit VHDL und dem parallelem> denken...
Du musst nicht parallel, sonder seriell denken. Du
startest in z.B. Zustand S1, der auf das erste Byte
wartet. Dann im nächsten Schritt das nächste Byte
verarbeiten etc. Üb das einfach mal mit Zustandautomaten,
indem Du zu deinem Protokoll einen Automaten formuliest
und per konkreten Daten einen Durchlauf machst.
Sigi schrieb:> Üb das einfach mal mit Zustandautomaten,> indem Du zu deinem Protokoll einen Automaten formuliest> und per konkreten Daten einen Durchlauf machst.
Das ist mein Problem, soetwas habe ich noch nie gemacht :-/
Hat jemand ein gutes Skript dazu?
ich schrieb:> Hallo,> das hatte schon jemand als Problem gehabt und hat die escape sequenzen> erfunden.> z.B. Start = 0xaa, Stop = 0x55 Escape 0xD3> Nutzdaten 0xaa 0xD3 0x55> gesendet> 0xaa 0xD3 0xaa 0xD3 0xD3 0xD3 0x55 0x55>> MfG> ich
Also man schreibt dann immer das Ecape-byte vor das Byte das Nutzdaten
sind, aber wie ein Befehl aussieht. Dadurch hat man dann aber
unterschiedlich lange Pakete. Ok, das mag ok sein, ich wollte das nicht.
Aber Danke, werde ich mir merken!
> In der T.I. ist der Endzustand extrem interessant, z.B. beim> Erkennen von regulären Ausdrücken etc.. Und wie der Automat> dahin gekommen ist, erst recht.
Naja, der Weg interessiert nicht wirklich, kann ja durch die
epsilon-Übergänge auch potentiell verschiedene Wege geben. So ein
simpler Automat ist erstmal nur dafür da, um zu überprüfen, ob ein Wort
zu einer durch eine Grammatik (Regex, etc.) definierten Sprache gehört.
Und das tut es, wenn am Ende des Wortes der Automat in einem Endzustand
steht. Allerdings muss der natürlich auch nicht "final" im Sinne einer
Sackgasse sein...
Natürlich kann sowas in der HW auch interessant sein ("Codeschloss",
CRC, etc.), aber der IMO überwiegende Teil der realen HW-Automaten hat
keinen explizit interessierenden Endzustand und der zeitliche Ablauf der
Zustände und deren Ausgaben (sowas hat der gemeine Automat der TI ja
auch nicht) sind das eigentlich entscheidende.
Georg A. schrieb:> Naja, der Weg interessiert nicht wirklich, kann ja durch die> epsilon-Übergänge auch potentiell verschiedene Wege geben. So ein> simpler Automat ist erstmal nur dafür da, um zu überprüfen, ob ein Wort> zu einer durch eine Grammatik (Regex, etc.) definierten Sprache gehört.> Und das tut es, wenn am Ende des Wortes der Automat in einem Endzustand> steht. Allerdings muss der natürlich auch nicht "final" im Sinne einer> Sackgasse sein...
OT: vergiss mal epsilon-Übergänge (lassen sich eliminieren)
bzw. nichtdeterm. Automaten (lassen sich in determ. Automaten
wandeln => eindeutiger Ablauf).
Endliche Automaten und Reguläre Ausdrucke sind nur äquivalent,
Endliche Automaten darf man aber nicht darauf reduzieren, sie
sind zur Beschreibung endloser Abäufe ohne Erinnerung (!)
bestens geeignet, von daher: finale Zustände sind Sonderfälle.
