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
@ 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
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/vtex9.html http://www.actel.com/documents/State_Machine_AN.pdf
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".
>>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.
@ 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
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.
@ 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
>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.
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.
@ 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
@ 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
@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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.