Hallo, ich habe eine Statemachine in VHDL beschrieben. Die erzeugte Schaltung ist leider sehr komplex. Komplexer als gedacht. Das liegt vor allem an der Repräsentation der "stored_items" und das verdrahten in der FSM mit "stored_items_next" Kann mir jemand Tipps geben was ich besser machen könnte? Vielen Dank! Eckhardt
Warum willst Du da was d'ran ändern? Komplex ist doch schön! Mal im Ernst. "Zu komplex" ist eine unvollständige Qualifikation. Es fehlt der Vergleich. Passt es nicht auf den Chip? Oder was ist jetzt eigentlich das Problem?
Sagen wir es so. Ich bin absoluter Neuling in dem Thema und habe Angst hier dumme Dinge zu beschreiben. Gerade die Repräsentation der "Stored Items" fällt mir stark auf. Evtl. kann man hier etwas besser machen? Deshalb frage ich. Ich möchte ja etwas dazulernen. Die Schaltung funktioniert. Die weiteren .vhdl Dateien habe ich nicht beigefügt. Danke nochmals!
>Ich möchte ja etwas dazulernen. Gut, dann lernst Du hier folgendes: "Zu komplex" ist eine unvollständige Qualifikation. Es fehlt der Vergleich. >Gerade die Repräsentation der "Stored Items" fällt mir stark auf. Und mir fällt der Geruch von Stilton auf. :-) Was soll das nun heissen? Und müssen wir raten oder was? Lies mal den Artikel: http://www.mikrocontroller.net/articles/Netiquette Und noch eins: Mach Dir keine Sorgen was falsches zu schreiben. Viel problematischer ist, das Du uns hier einfach ein Codestück vör die Füsse wirfst und lediglich sagst, das ist unschön.
Was fehlt ist, Beschreibung, Synthese und Analyse. Beschreibung des Problems, wie Du zu dieser Lösung kommst und was die Lösung für Eigenschaften hat. Konkrete Eigenschaften und kein Gefasel wie "unschön" oder "auffallend". Dann kannst Du uns mal schreiben wie Du diese Eigenschaften bewertest. Und DANN können wir mal gemeinsam überlegen wie man das anders machen kann.
Mach mal langsam. Ich habe sehr wohl beschrieben was ich hals unschön empfinde. Da ich neu auf dem Gebiet bin weiß ich nicht so recht was gut und was schlecht ist. Jeder hat einmal angefangen. Wenn ich wüsste, was hier zu komplex ist oder ob es zu komplex ist, dann hätte ich nicht gefragt. Jeder hat mal angefangen und es ist schwer zu Beginn da richtig durchzublicken.
>Mach mal langsam.
Und Du weise mich nicht zurecht.
Herzlich willkommen in meinem CSS-File.
Und schönes Leben noch.
Das kann (muß) raus: use ieee.std_logic_unsigned.ALL; Siehe: Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete" Ansonsten, ich würde inzwischen mehr synchrone Prozesse verwenden. Sonst werden die Sensitivitylisten recht unübersichtlich. Duke
Mir fällt da gleich der Prozess für die LEDs auf: die zwei Zuweisungszeilen hätten es verdient, als Concurrent-Anweisungen allein dazustehen...
Vielen Dank für die Tipps. Ich habe das gleich alles eingearbeitet. Danke nochmals!
> An sich ist der Code vom Stil in Ordnung
Wobei das auch Geschmackssache ist. Ich stehe eher auf alles in einem
Prozess. Der kleine getaktete Prozess für next-state macht für mich
nicht so wirklich Sinn. Es ist sicher hübsch, dass man da das
theoretische Automatenmodel gleich sieht (tau=Speicher=next-state), dann
sollte man aber gleich Messias Gaisler folgen und die
Ausgangswerterzeugung in einen dritten Prozess verfrachten. Alles
theoretisch super-sauber, aber absolut bescheuert in der Wartung. Ich
bekomm jedenfalls Kopfschmerzen von sowas.
Die Ein-Prozess-Methode wie auch die hier gezeigte Zwei-Prozess-Variante
hat nur ein Problem. Wenn man den Code aus einer Zustandsbeschreibung
(Bubbles, etc.) rausentwickelt, muss man die Ausgangswerte für jeden
Zielzustand potentiell mehrfach setzen (analog dem Zielzustand halt).
Das sorgt für Codeduplizierung und ist ganz böse. Heisst es jedenfalls.
Wer vom Automatenmodell herkommt, kann den Code aber gleich daraus
synthetisieren lassen, daher ist das da eigentlich egal.
Wenn man aber sowas von Hand strickt und den Automaten als
Programmablauf sieht (d.h. der Takt schaltet zB. eine Zeile im Ablauf
weiter), dann stört das überhaupt nicht, weil der nächste Zustand gar
nichts mit der nächsten Ausgabe zu tun hat. Entscheidend ist nur der
jetzige Zustand, der einen Ausgang im nächsten Takt erzeugt. Die
Zustandsweiterschaltung ist davon unabhängig und sorgt nur für die
Ausführung der "nächsten Zeile".
Georg A. schrieb: > dann > sollte man aber gleich Messias Gaisler folgen und die > Ausgangswerterzeugung in einen dritten Prozess verfrachten. Da hast Du wohl vor lauter Kopfschmerzen etwas den Überblick verloren ;-) Bei Gaisler sind es zwei Prozesse: einer getaktet für die Register und der zweite für die Kombinatorik. Außerdem ist der ganze Kram in records verpackt, so daß nichts vergessen wird (Defaultzuweisung, Sensitivity-List). > Alles > theoretisch super-sauber, aber absolut bescheuert in der Wartung Auch praktisch super und sauber. Gerade in der Wartung. Wenn man sich mit der klassischen Datenblock-Beschreibung, wegen irgendwelcher Kleinigkeit oft genug ins Knie geschossen hat, wird man das zu schätzen lernen. Duke
Duke Scarring schrieb: > Georg A. schrieb: >> dann sollte man aber gleich Messias Gaisler folgen und die >> Ausgangswerterzeugung in einen dritten Prozess verfrachten. > Bei Gaisler sind es zwei Prozesse: einer getaktet für die Register und > der zweite für die Kombinatorik. > Außerdem ist der ganze Kram in records verpackt, so daß nichts vergessen > wird (Defaultzuweisung, Sensitivity-List). Der eigentliche Knackpunkt dieser Methode (das, was "Softies" so gut daran gefällt), ist, dass dabei in Prozessen durchgehend mit Variablen "gerechnet" wird. Dabei vergisst der "Programmierer" gern, dass er es nicht mit einem Software-Funktionsblock, sondern mit einer Hardwarebeschreibung zu tun hat.
Kann mir jemand erklären, was das Problem dieses Codes sein soll? Die mehrfachen Zuweisungen werden doch wegsynthetisiert, bzw über enable gelöst und die Codegrösse als solche ist doch nicht das Problem. Eher mickrig.
> Bei Gaisler sind es zwei Prozesse: einer getaktet für die Register und > der zweite für die Kombinatorik. Ich habe da was von zweien in der Kombinatorik gelesen. Einen für next-state und einen fürs Ausgangsmapping. Aber was soll der blöde Registerprozess überhaupt? Nur damit der Coder nicht zu oft mit dem bösen <= in Berührung kommt? > Auch praktisch super und sauber. Gerade in der Wartung. Ist mir unverständlich... Alles total auseinandergerissen...
Wie man das nun macht ist reine Geschmackssache. Ich beispielsweise mag Prozesse aus dem von lkmiller genannten Grund nicht so gerne. Daher habe ich nur einen kleinen Prozess, der das Register für die SM darstellt und den kompletten Rest mache ich per when-Konstrukt. Aber wie gesagt ist das alles Geschmackssache, und darüber zu debattieren führt nur zu Flamewars. Den Code des OP finde ich auch nicht schlecht. Alles übersichtlich eingerückt, Leerzeilen dort, wo welche hingehören und alles brav kommentiert. :)
Ob man das allerdinge in jedem Takt machen muss, erscheint mir fraglich:
1 | -- depending on money, counting products and switches - calculate the resulting
|
2 | -- money, product fillings, the output product number and an error code
|
3 | -- this is used in a state in the fsm
|
4 | prod_output_proc: entity work.output_product(arch_output_product) |
Und ich würde mehr mit (eingeschränkten) Integern arbeiten, wenn keine Bitorientierte Arbeitsweise nötig ist. Z.B. der error, der ja nur 1 Wert zwischen 0 und 15 annehmen kann. Und das kann zu seltsamen Fehlern und Effekten führen, weil so ein paar Definitionen doppelt vorhanden sind:
1 | use ieee.numeric_std.all; |
2 | use ieee.std_logic_unsigned.ALL; |
Siehe dazu den Beitrag "Re: LTC2624 in VHDL (Spartan3E starter)"
Huhu Da ich gerade dabei bin ein Beispiel für einen Mealyautomaten zu suchen, bin ich recht der Annahme, dass es sich hier um einen Mealyautomaten handelt? Stimmt das? In der Theorie heißt es ja, dass die Ausgabe dann von der Eingabe und vom Zustand selbst abhängt. Es fällt mir sogar schwer hier zu definieren, was denn in diesem Fall die Ausgabe denn sein soll? Vielen Dank Swenja
Ok. Danke. Und da diese Aushänge natürlich nicht nur vom Zustand selbst abhängen, haben wir es tatsächlich mit einem Mealyautomaten zu tun. Super. Dann kann ich meinen Automaten nach diesem Strickmuster beginnen. Oder liege ich falsch?
Hallo Swenja, ich hätte gedacht ich habe einen klassischen Moore Automaten entworfen. Die Ausgabe hängt doch eigentlich nur vom Zustand selbst ab. Falls ich falsch liege korrigiert mich gerne... Viele Grüße Eckhardt
Eckhard Göhring schrieb: > ich hätte gedacht ich habe einen klassischen Moore Automaten entworfen. > Die Ausgabe hängt doch eigentlich nur vom Zustand selbst ab. Auf jeden Fall gibt es keine direkte Wirkung vom Eingang auf den Ausgang. Es kann also sicher kein Mealy Automat sein. Das ist ein Moore Automat mit ein paar kleinen "Unterautomaten" (aka. Zähler).
Es ist ein Moore Automat. Die Verwendung von Zählern haben darauf keinen Einfluss. Vielmehr ist bilden der Zustand des Zählers und der Zustand der FSM einen "übergeordneteten" Zustand des Gesamtsystems. Abgesehen davon lassen sich Moore- und Mealy-Automaten sowieso ineinander überführen, von daher ist es eh Wurscht*. ^^ (* Jedenfalls aus der praktischen Sicht des Programmierers. Dem theoretischen Informatiker ist der Unterschied natürlich alles andere als egal.)
Vielen Dank! Da habe ich mich wohl geirrt wie ihr alle eindeutig bestätigt. Dann schaue ich einmal nach anderen Beispielen denn ich muss einen Mealy-Automaten realisieren.
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.