Hallo zusammen,
ich (VHDL-Anfänger) hab zu Übungszwecken mal versucht, eine
Statusmaschine nur mit nebenläufigen Befehlen zu schreiben:
----->8-----------------------------------------
architecture Architektur_main of main is
type statusmaschine_t is ( STATUS_0, STATUS_1, STATUS_2);
signal sig_Status_x: statusmaschine_t := STATUS_1;
begin
-- Statusmaschine
sig_Status_x <= STATUS_1 when ( (sig_Status_x = STATUS_0) and
(in_button0_b = '0') ) else
STATUS_2 when ( (sig_Status_x = STATUS_1) and
(in_button1_b = '0') ) else
STATUS_0 when ( (sig_Status_x = STATUS_2) and
(in_button2_b = '0') );
-- Status in der 7-Segmentanzeige anzeigen
with sig_Status_x select
out_bcd0_bv8 <= func_LED7SEG_bv8("0000") when STATUS_0,
func_LED7SEG_bv8("0001") when STATUS_1,
func_LED7SEG_bv8("0010") when STATUS_2,
func_LED7SEG_bv8("1111") when others;
end Architektur_main;
----->8-----------------------------------------
Ich habe den Code mit Xilinx ISE9.2i synthetisiert und lasse ihn auf
einem XC9500-CPLD laufen. Über eine 7-Segment-Anzeige wird mir der
Status angezeigt.
Das Problem ist, daß das Signal "sig_Status_x" nicht den Initialzustand
("STATUS_1") annimmt, den ich bei der Signal-Deklaration angegeben habe.
Tatsächlich nimmt "sig_Status_x" einen Zustand an, der außerhalb des
Wertebereiches des Typs "statusmaschine_t" liegt (die 7-Segmentanzeige
zeigt "F" an, also greift der "when others"-Zweig des Selects).
Wenn ich davon ausgehe, daß "sig_Status_x" als 2-Bit-Variable bzw.
-Latch angelegt wird, scheint diese mit "11" initialisiert zu werden.
Könnt Ihr mir sagen, warum das nicht funktioniert?
PS: Sorry für fehlende Formatierung
Sebastian F. schrieb: > Wenn ich davon ausgehe, daß "sig_Status_x" als 2-Bit-Variable bzw. > -Latch angelegt wird Davon würde ich nicht ausgehen. Schau dir mal die Synthese-Einstellungen an. Dort könnte z.B. One-Hot-Coding gewählt sein. Also hast du schon mal 3 Bit und folglich 8 Zustände von denen nur 3 auskodiert sind. Aus welchem Grund versuchst du eine FSM so aufzubauen? Wäre ein Prozess nicht sinnvoller? Nebenläufige Befehle erzeugen für gewöhnlich keine Register oder Latches ... ein Prozess schon. Dann sollte es auch mit der Initialisierung klappen. Schau dir mal das Resultat der Synthese im RTL-Viewer an, vielleicht stellst du ja fest, dass überhaupt keine Latches erzeugt werden?!
Die Statusmaschine funktioniert, wenn ich sie erstmal in einen erlaubten
Zustand gebracht hab (durch Einfügen eines Reset-Signals). Nur das
Initialisieren funktioniert nicht.
Inzwischen vermute ich, daß das wieder so eine
Simulation-versus-Synthese-Geschichte ist. Gilt die
Signal-Initialisierung vielleicht nur für den Simulator?
Ich meine, wenn ich so recht darüber nachdenke, hat es sicher einen
Grund, daß alle Bausteine einen Reset-Eingang haben...
> Aus welchem Grund versuchst du eine FSM so aufzubauen?
Nur zu Übungszwecken, hat keinen tieferen Sinn.
Sebastian F. schrieb: > Nur das > Initialisieren funktioniert nicht. Du kannst auch nur speichernde Elemente (also z.B. FFs) initialisieren. Bei ASICs, die sich selber aus dem Sumpf ziehen muessen, brauchst du einen Reset auf '0' oder '1'. Beim FPGA wird beim konfigurieren jedes FF auf den gewuenschten Wert initialisiert, wenn du da nix angibst ueblicherweise auf '0'. Was deine Simulation bzw. dein Synthesetool bei einem Latch macht, tja, das duerfte hochgradig herstellerabhaengig sein...
Das ist interessant: Wenn ich den Code auf einem FPGA laufen lassen, dann funktoniert die Initialisierung. Auf dem CPLD hingegen nicht. berndl (Gast) schrieb: >Beim FPGA wird beim konfigurieren jedes FF >auf den gewuenschten Wert initialisiert, wenn du da nix angibst >ueblicherweise auf '0'. D.h. im FPGA hat ein FF zu Beginn einen definierten Zustand. Beim CPLD hingegen wird der Zustand des FF wohl eher zufällig bzw. von der Hardware abhängig sein, daher braucht man da dann auch einen Reset, richtig?
Sebastian F. schrieb: > D.h. im FPGA hat ein FF zu Beginn einen definierten Zustand. > Beim CPLD hingegen wird der Zustand des FF wohl eher zufällig bzw. von > der Hardware abhängig sein, daher braucht man da dann auch einen Reset, > richtig? Nein. Auch das CPLD wacht in einem bestimmten Zustand auf. Schau Dir einmal den Fitter Report an, dort sind die Gleichungen aufgelisten, sowie für jedes FF auch der Anfangswert.
Vorneweg: da ist gar kein FF beschrieben, sondern ein Latch. Das ist für die weitere Verhaltensanalyse wichtig: > D.h. im FPGA hat ein FF zu Beginn einen definierten Zustand. Die FFs im FPGA können in die Betriebsart "Latch" umgeschaltet und deshalb mit einem definierten Wert geladen werden. > Beim CPLD hingegen wird der Zustand des FF wohl eher zufällig In einem CPLD gibt es aber kein Latch. Solche Konstrukte werden da aus Logik zusammengebaut (die getakteten FFs liegen brach). Und Logik lässt sich nicht initialisieren... mac4ever schrieb: > Nebenläufige Befehle erzeugen für gewöhnlich keine > Register oder Latches ... ein Prozess schon. Hmmmmm...:
1 | latched <= input when speichern='1'; |
2 | registered <= input when rising_edge(speichern); |
Wenn ich mir den Code anschaue fällt mir als erstes folgendes auf: Kein Takt! Und eine State-Machine ohne Takt gibt es nicht! Und Praktisch: Schau mal die Einstellungen zur State Machine in ISE genau durch. Da gibt es Optionen wie "Save State Machine". Da würde ich den Fehler suchen (Nachdem ich einen Takt in das Design implementiert hätte)
Stefan R. schrieb: > Und eine State-Machine ohne Takt gibt es nicht! Da solltest du aber nochmal die Grundlagen ansehen... :-o Eine Zustandsmaschine hat prinzipiell keinen Takt. Nur ist eine Umsetzung mit Takt durch die auf den Bausteinen vorhandenen Speicherelemente einfacher zu realisieren. Denn prinzipiell funktioniert die oben beschriebene FSM ja, nur die Initialisierung geht bei CPLDs schief. > Da würde ich den Fehler suchen Unnötig, der Fehler wurde bereits geklärt.
Ich bin zwar kein Theoretiker, aber Automaten arbeiten Zeitdiskret. Für mich als Praktiker heisst das: Zustände ändern sich bei steigende/fallende Flanken!
Lothar Miller schrieb: > In einem CPLD gibt es aber kein Latch. Solche Konstrukte werden da aus > Logik zusammengebaut (die getakteten FFs liegen brach). Und Logik lässt > sich nicht initialisieren... Das müßte ja das Synthese-Tool erkennen können. Sollte es dann nicht einen Fehler oder eine Warnung geben, daß sich die gewünschte Initialisierung nicht umsetzen läßt? Ich finde es reichlich verwirrend, daß bestimmte Befehle bzw. Befehlsteile (wie z.B. "after x ns") vom Synthese-Tool (in meinem Fall XST) einfach ignoriert werden, ohne daß der Programmier darüber informiert wird. Ich meine, wie kann ich denn sicher sein, daß das, was ich programmiert habe, auch tatsächlich alles im Chip ankommt? Erfahrungssache? > Vorneweg: da ist gar kein FF beschrieben, sondern ein Latch. Das ist auch interessant! Ich hab nämlich bemerkt, daß die Maschine auf dem FPGA zwar korrekt initialisiert wird, aber dafür regelmäßig "abstürzt" (d.h. einen anderen Zustand annimmt, als der Datentyp hergibt). Mit einem Takt und Flankensteuerung war das Problem dann behoben. Ich vermute, daß die Laufzeitunterschiede im FPGA dazu führen, daß die einzelnen Signale der Weiterschaltbedingungslogik Glitches an den Zustands-Latch-Eingängen erzeugen und die Zustands-Latches daher Kombinsationen annehmen können, die es gar nicht geben dürfte.
Na dann hast du ja jetzt auf die harte Tour erfahren, was es bedeutet ein nicht-synchrones Design zu bauen. Für Anfänger gilt: Alles synchron! Dann gibt es auch keine Glitches. Ich für meinen Teil habe Zustandsmaschinen jedenfalls nur mit Takt kennengelernt, wie soll ohne einen Takt auch von einem in den nächsten Takt umgeschalten werden?
Der letzte Satz sollte heissen: von einem Zustand in den nächsten Zustand...
Sebastian F. schrieb: > Ich finde es reichlich verwirrend, daß bestimmte Befehle bzw. > Befehlsteile (wie z.B. "after x ns") vom Synthese-Tool (in meinem Fall > XST) einfach ignoriert werden, ohne daß der Programmier darüber > informiert wird. Ich meine, wie kann ich denn sicher sein, daß das, was > ich programmiert habe, auch tatsächlich alles im Chip ankommt? > Erfahrungssache? Es gibt einen Standard was ein Synthese-Werkzeug umsetzen muss und was nicht: IEEE 1076.6 Zudem musst Du ins Handbuch des Werkzeuges schauen. Und manche Tools geben Dir eine Warning oder eine Info mit der Information das etwas nicht synthetisierbar ist. Btw. IEEE 1076.6 lässt keine Initialisierung bei der Deklaration zu. Doch viele Tools können das trotzdem. Bei XST ist es wohl standardmäßig aktiviert. Bei manch anderem muss man es explizit aktivieren.
faul schrieb: > Na dann hast du ja jetzt auf die harte Tour erfahren, was es bedeutet > ein nicht-synchrones Design zu bauen. Das ist übrigens falsch. Das Design an sich ist synchron. Und zwar zum Signal in_button0_b. Allerdings handelt es sich dabei um ein Design aus Latches. Das ist in einem FPGA oder CPLD zwar eine Sünde, aber in einem ASIC kann man sowas bauen. Allerdings muss ein solches Design umfassender mit Constraints versehen werden und die STA muss genauer ausgeführt werden.
Lothar Miller schrieb: > Hmmmmm...: > latched <= input when speichern='1'; > registered <= input when rising_edge(speichern); Ok, so hab ich das noch nie versucht ... Sebastian F. schrieb: > Ich finde es reichlich verwirrend, daß bestimmte Befehle bzw. > Befehlsteile (wie z.B. "after x ns") vom Synthese-Tool (in meinem Fall > XST) einfach ignoriert werden Das after x ns nicht synthesefähig ist, wird durchaus in der Literatur erwähnt. Die Unterschiede zw. Simulation und Synthese sollte man unbedingt kennen und sich nicht auf das Synthesetool verlassen. Mathi schrieb: > Das ist übrigens falsch. Das Design an sich ist synchron. Und zwar zum > Signal in_button0_b. ... und dann noch zu in_button1_b und in_button2_b ... 3 unsynchrone Signale ... sehr synchron
Stefan R. schrieb: > Ich bin zwar kein Theoretiker, aber Automaten arbeiten Zeitdiskret. Nein. Die Übergänge eines Automaten sind idR. komplett zeitunabhängig. Z.B. Kaffeeautomat: Irgendwann drückt einer mal die starttates, dann wird ein Bescher ausgewrofen, der von der Schwerkraft gezogen beliebig langsam in den Halter fällt. Danach wird Wasser eingelsaaen, was druck- und kalkabhängig schneller oder langsamer geht. Dann das Aufheizen, Abfüllen.... Nirgends in diesem Ablauf ist die Zeit vorrangig nötig. > Für mich als Praktiker heisst das: Zustände ändern sich bei > steigende/fallende Flanken! In der Praxis sind wie gesagt nur die Speicherglieder (hier FFs) diejenigen, die einen Takt brauchen...
Die Automatentheorie schert sich nicht um Gatterlaufzeiten :-) Damit kann man sie zwar als graue Theorie abtun, aber alle Algorithmen der digitalen Signalverarbeitung basieren nun mal auf diesen Grundlagen. Wenn man, wie ich, kein brillianter Mathematiker ist, bleibt einem leider nicht anderes übrig, als diese Modelle als gegeben zu akzeptieren. Ganz egal wie ich meine Schaltung aufbaue: Sie muss möglichst nahe am Ideal der Theorie bleiben und die besagt: zeitdiskrete Abstände und abgestufte Werte. Ich nehme meine Behauptung zurück, wenn ihr mir einen FIR Filter ohne Takt und ein halbes Bit zeigt!
mac4ever schrieb: > ... und dann noch zu in_button1_b und in_button2_b ... > 3 unsynchrone Signale ... sehr synchron Ah, ich hatte übersehen das es drei unterschiedliche in_buttonX_b gibt. Sorry!
Stefan R. schrieb: > Ich nehme meine Behauptung zurück, wenn ihr mir einen FIR Filter ohne > Takt ... zeigt! http://de.wikipedia.org/wiki/Akustische_Oberfl%C3%A4chenwellen-Filter
1 | : |
2 | Der Aufbau bildet einen FIR-Filter. |
3 | : |
Lothar Miller schrieb: > Stefan R. schrieb: >> Ich nehme meine Behauptung zurück, wenn ihr mir einen FIR Filter ohne >> Takt ... zeigt! > http://de.wikipedia.org/wiki/Akustische_Oberfl%C3%A4chenwellen-Filter >
1 | > : |
2 | > Der Aufbau bildet einen FIR-Filter. |
3 | > : |
4 | > |
Das ERSATZSCHALTBILD eines SAW Filters entspricht dem eines FIR-Filters. D.h. nicht, dass es ein FIR Filter und schon gar nicht, dass es eines ohne Takt ist. http://www.axtal.com/data/buch/Kap9.pdf
Stefan R. schrieb: > Das ERSATZSCHALTBILD eines SAW Filters entspricht dem eines FIR-Filters. > D.h. nicht, dass es ein FIR Filter und schon gar nicht, dass es eines > ohne Takt ist. Die Implementierung eines Automaten gelingt am zuverlässgsten mit einem Takt. Das heißt aber nicht, dass es ohne Takt nicht ginge... Zur Beruhigung: ich verwende für den Zustandsspeicher meiner Automaten auch FFs. Und brauche daher einen Takt. Das ERSATZSCHALTBILD des Automaten (die grafische Umsetzung) braucht allerdings keinerlei Takt, und der taucht dort auch nirgends auf...
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.