mikrocontroller.net

Forum: FPGA, VHDL & Co. Design von Statmachines


Autor: Philip Kirchhoff (plip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

ich benutze wenn ein Ablauf etwas komplizierter wird gerne 
Statemachines. Allerdings baue ich sie mangels Erfahrung jedesmal anders 
auf, mal ist das Ergebnis mehr, mal weniger gut. Jetzt habe ich in einem 
Modul meines Profs, das ich verwende gesehen, dass er das ziemlich 
anders gemacht hat als das was ich so fabriziere. Z.B. hat er seine 
Anweisungen nach Mealy- und Moore-Ausgängen getrennt und verwendet kein 
Enum für den State, wie ich es immer mache.

Deshalb frage ich mich, ob es grundsätzliche Regeln und Empfehlungen für 
das Design von SMs in VHDL gibt. Vielleicht hat ja auch jemand nen Link 
parat...

Gruß Philip

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Philip Kirchhoff (plip)

>anders gemacht hat als das was ich so fabriziere. Z.B. hat er seine
>Anweisungen nach Mealy- und Moore-Ausgängen getrennt und verwendet kein
>Enum für den State, wie ich es immer mache.

Schlecht. States sollte man immer mit Enums anlegen. Wegen der 
Lesbarkeit, Portierbarkeit und der Möglichkeit, per Syntheseoption 
verschiedene Kodierungen für die States zu wählen.

>Deshalb frage ich mich, ob es grundsätzliche Regeln und Empfehlungen für
>das Design von SMs in VHDL gibt.

Gibt es.

- Saubere Formatierung
- Enums verwenden
- ich bevorzuge alles in einen getakteten Prozess zu schreiben, ist 
kompakter
- etc.

> Vielleicht hat ja auch jemand nen Link
>parat...

Leider nein.

MFG
Falk

Autor: Thomas Hertwig (mac4ever)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Philip Kirchhoff (plip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich suche oft Fehler, die dadurch entstehen, dass ich irgendwelche 
Übergangsbedingungen vergesse zu setzen oder rückzusetzen etc...
Aber das ist wohl eher ein Problem der Systematik, also anstatt 
draufloszuhacken erstmal nen Zustandsgraphen mit Übergangsbedingungen 
zeichnen...oder noch besser erstmal überlegen was für Zustände und 
Übergänge es überhaupt gibt.:-)

Ich hab irgendwo mal gelesen, dass es unterschiedliche Formen gibt, wie 
ein Synthesetool SMs umsetzt. Bei mir steht z.B. immer was von "one 
hot".

Autor: Philip Kirchhoff (plip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas

Super - danke!

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>anders gemacht hat als das was ich so fabriziere. Z.B. hat er seine
>>Anweisungen nach Mealy- und Moore-Ausgängen getrennt und verwendet kein
>>Enum für den State, wie ich es immer mache.

>Schlecht. States sollte man immer mit Enums anlegen. Wegen der
>Lesbarkeit, Portierbarkeit und der Möglichkeit, per Syntheseoption
>verschiedene Kodierungen für die States zu wählen.


Es ist besser lesbar, enums zu verwenden - die Tools, die ich kenne, 
optimieren und rekodieren jedoch auch state machines, bei denen die 
Zustaende explizit angegeben sind.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jan M. (mueschel)

>Es ist besser lesbar, enums zu verwenden - die Tools, die ich kenne,
>optimieren und rekodieren jedoch auch state machines, bei denen die
>Zustaende explizit angegeben sind.

Das wäre dann allerdings ein unzulässiger Eigensinn, den man den Tools 
schnellstens abgewöhnen sollte. GGf. per Konfiguration etc.

MfG
Falk

Autor: savoo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es gibt auch HDL-Designer, mit welchen man FSM generieren kann.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Prof meinte dazu folgendes:

1 Prozess für den Zustandsspeicher und 1 oder 2 kombinatorische Prozesse 
für eingangs und Ausgangslogik die vom aktuellen Zustand abhängen. 
Generell sollte man Mealy Automaten meiden, so es denn geht.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karl (Gast)

>1 Prozess für den Zustandsspeicher und 1 oder 2 kombinatorische Prozesse
>für eingangs und Ausgangslogik die vom aktuellen Zustand abhängen.

Warum einen extra Prozess für den Zustandspeicher? Das kann man 
problemlos mit der Statelogik verknüpfen. Ist kein bisschen 
unübersichtlicher und hat keinerlei Leistungsnachteile.

>Generell sollte man Mealy Automaten meiden, so es denn geht.

Hmmm.

MfG
Falk

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Warum einen extra Prozess für den Zustandspeicher? Das kann man
>problemlos mit der Statelogik verknüpfen. Ist kein bisschen
>unübersichtlicher und hat keinerlei Leistungsnachteile.

Dass dabei das selbe Syntheseergebnis herauskommt, ist klar. Über die 
(Un)Übersichtlichkeit mag man diskutieren. Der Speicherprozess hat eben 
nur den Takt und evtl. einen reset in der sensitivity list und ist damit 
klar als Speicher erkennbar. Der Logikprozess hat nur den Zustand in der 
sensitivity und ist damit klar als reine Logik zu identifizieren. Gerade 
am Anfang ist diese Trennung IMO sinnvoll, weil man gezwungen wird, sich 
das ganze als Hardware vorzustellen.

>Hmmm.

Die können durchaus mal nen Fallstrick bereithalten, z.B. langsam sein 
oder mit nicht einsynchronisierten Signalen problematisch. Wenn du dazu 
ne andere Meinung hast, würde ich die natürlich gern lesen.

Autor: Thomas Hertwig (mac4ever)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hätte ich auch noch was beizusteuern, da ich letztens ein bösartiges 
Problem hatte.

Meine State-Machine war wie in den von mir genannten Links modelliert. 
Die Simulation war absolut korrekt. Kaum hatte ich das Ganze 
runtergerechnet und auf den FPGA gepackt, ging die FSM ... naja, sagen 
wir: wie sie wollte ;) Ganz sporadisch setzte sie aus und irgendwann 
lief sie dann wieder ( wenigstens bis zum nächsten Hacker ).

Lösung: Alle Signale, auf welche die FSM reagieren sollte, mussten im 
selben Prozess gepuffert werden. Erst danach funktionierte die FSM 
einwandfrei. Ich denke mal, dass Karl mit "einsynchronisierten Signalen" 
genau das meinte.

Ach ja, den Reset sollte man sicherheitshalber auch synchron machen und 
nicht wie in den Beispielen asynchron.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karl (Gast)

>Dass dabei das selbe Syntheseergebnis herauskommt, ist klar.

So klar ist das gar nicht. Es gibt einige (ältere) Texte im Netz, wo 
behauptet/spekuliert wird, dass getrennte Prozesse dem Synthesizer mehr 
Freiheiten lassen würden, und somit bessere Performance erzielt wird. 
Glaub ich aber nicht.

>sensitivity und ist damit klar als reine Logik zu identifizieren. Gerade
>am Anfang ist diese Trennung IMO sinnvoll, weil man gezwungen wird, sich
>das ganze als Hardware vorzustellen.

???
Wieso bewirkt dir Trennung eine schärfere Hardwaredenkweise.

>Die können durchaus mal nen Fallstrick bereithalten, z.B. langsam sein

OK. Das spuckt aber der Timinganalyser aus.

>oder mit nicht einsynchronisierten Signalen problematisch.

Hat mit Mealy nichts zu tun.

>Wenn du dazu
>ne andere Meinung hast, würde ich die natürlich gern lesen.

Naja, bisher hab ich das nicht soooo strickt gesehen, und mir fällt 
spontan auch kein wirkliches gewichtiges Argument gegen Mealy ein.

MFG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thomas Hertwig (mac4ever)

>Lösung: Alle Signale, auf welche die FSM reagieren sollte, mussten im
>selben Prozess gepuffert werden. Erst danach funktionierte die FSM
>einwandfrei. Ich denke mal, dass Karl mit "einsynchronisierten Signalen"
>genau das meinte.

Ja, aber das kann ein beliebiger Prozess sein. Klar, er muss mit dem 
gleichen Takt wie die FSM arbeiten ;-)

>Ach ja, den Reset sollte man sicherheitshalber auch synchron machen und
>nicht wie in den Beispielen asynchron.

Das ist nix neues. Die asynchronen Resets sind akademische Altlasten.

MFG
Falk

Autor: Thomas Hertwig (mac4ever)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@falk

Ich weiß, aber da es gerade allgemein um das Design von FSMs geht, 
können wir ja mal alles zusammentragen auf was man achten sollte. In den 
Dokumenten von Actel und Xilinx werden diese Fakten nämlich auch nicht 
berücksichtigt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.