Hallo, ich habe hier eine kleine Komponente, die nur dazu dienen soll einen Taster zu entprellen. Dazu habe ich eine State Machine genutzt, mit 2 Zuständen. Es funktioniert auch, nur Quartus erkennt scheinbar nicht meine FSM als FSM an. (Im Report ist keine FSM zu finden und der State Machine Viewer zeigt auch keinen Automaten) Habe ich was falsch gemacht, oder woran kann es liegen? Die Datei habe ich angehangen. Gruß
Ohne jetzt genau dein Design zu beaugapfeln: Nimm einfach das FSM-Template vom Quartus(-Editor).
Eine FSM mit 2 Zuständen ist ein einzelnes Flipflop. Ich würde da auch nicht extra "FSM" dazu sagen...
Wozu ist das wichtig, dass eine State Machine als solche erkannt wird? Was hat das für Vorteile?
Angehängte Dateien:
Derek .. schrieb: > Die Datei habe ich angehangen. Die geht so aber nicht durch die Synthese, denn countval und MAX_CNT sind nirgends definiert. Die Zähler kannst du übrigens ruhig als Integer deklarieren, dann sparst du dir diese Umwandlungen im Stil von "countval <= to_unsigned(0, bitdepth);" und schreibst stattdessen "countval <= 0;". Zudem ist endcount am Anfang nicht definiert und wird auch nicht von einem der Resets behandelt. Und letztendlich ist diese Entprellgeschichte eine reine Zufallsfunktion, denn der Zähler countval läuft eigentlich dauernd durch und wenn er gerade mal überläuft und genau dann zufällig der Eingang high ist, dann wird auch der Ausgang high. Und so können auch kürzeste Spikes den Ausgang für einen paar Takte aktivieren. Insgesamt ist mir völlig unklar, warum diese Entprellerei so unheimlich umständlich über 3 Prozesse verteilt ist. Da muss man sich ja echt einen Kopf machen, um zu sehen, wie da letztlich der Entprellzähler losläuft. Die Benennung der Zustände in recht ähnliche Begriffe wie IDLE (= untätig) und WAITING (= warten) trägt zum Verständnis nichts bei. Im Anhang mal mein Ansatz "debounce_ohne_fsm.vhd" für die Aufgabe. Damit kommt dann mit der ebenfalls angehängten Testbench die ebenfalls angehängte Waveform heraus... ;-)
:
Bearbeitet durch Moderator
Danke Lothar für die Verbesserungsvorschläge, welche ich auch berücksichtigen werde. Eben noch was geändert und wieder rückgängig gemacht, da hab ich natürlich vergessen MAX_CNT wieder zu definieren. Aber auch bei meiner Fassung fängt der Zähler erst nach dem Drücken an und nicht kontinuierlich, oder? Liegt es also daran, dass 2 Zustände zu wenig sind, um als FSM "anerkannt" zu werden?
:
Bearbeitet durch User
Angehängte Dateien:
Derek .. schrieb: > Aber auch bei meiner Fassung fängt der Zähler erst nach dem Drücken an > und nicht kontinuierlich, oder? Hast du das nicht selbst auch simuliert? Die Bilder namens "Zufallsentprellung" sind im Prinzip mit deinem Code, aber ohne den unnötigen Reset und mit Integern als Zähler gemacht. Insofern musste ich jetzt tatsächlich erst mal deinen Code zum Luafen bringen. Ich hab jetzt also genau den Code genommen und bin dann gleich über den "rst" gestolpert, der überraschenderweise low aktiv ist und damit "rstn" heißen sollte. Seis drum, die Testbench kurz angepasst, und wie erwartet lautet die Antwort auf deine Frage: Nein, wie zu erwarten ist auch dein Original ein solcher Zufallsentpreller. Ich hab die restlichen Dateien mal angehängt: dein unsigned Original mit MAX_CNT = 40, meine Integer Version und die Waveform, bei der dein unsigned Original gegen die obige Testbench mit invertiertem Reset läuft. BTW: meine obige Behauptung mit dem fehlenden Initwert für endcount stimmt nicht. Dessen Reset hatte sich nur gut versteckt.
:
Bearbeitet durch Moderator
Derek .. schrieb: > Aber auch bei meiner Fassung fängt der Zähler erst nach dem Drücken an > und nicht kontinuierlich, oder? > Liegt es also daran, dass 2 Zustände zu wenig sind, um als FSM > "anerkannt" zu werden? Oder weil es in einer Gatterliste kein Gatter FSM gibt?! Wahrscheinlich hast du das Grundprinzip der FPGA-Synthese nicht verstanden. Dabei wird eine FSM-Beschreibung in ein Zustandsspeichernetzwerk (meistens Handvoll FF) und 2,3 Kombinatorik-netzwerke (meistens LUT) 'umgewandelt'. Eon FPGA-Grundelement: FSM-primitve gibt es nicht. Einfach mal in den Grundlagen: Entwurf von Zustandsautomaten nachschlagen: https://www-user.tu-chemnitz.de/~knmat/V/Alt/Dr%20K%94nig/Digtech7_2.pdf S. 69 ff.
C. A. Rotwang schrieb: > Oder weil es in einer Gatterliste kein Gatter FSM gibt?! Ich meine ja auch das Auffinden des Automaten in dem State Machine Viewer des Programms. Oder wir reden aneinander vorbei... Jedenfalls habe ich nur zum Test einen dritten Zustand hinzugefügt und schon tauchte der "Automat" im State Machine Viewer und im Report auf. Damit ist die Frage wohl beantwortet.
Josef schrieb: > Wozu ist das wichtig, dass eine State Machine als > solche erkannt wird? Was hat das für Vorteile? Mag niemand die Frage beantworten? Ist die Frage dumm? Meine Vermutung: Es hat keine Auswirkung auf die Synthese. Es geht um die übersichtliche Darstellung bei der Simulation. Richtig?
Josef schrieb: > Josef schrieb: >> Wozu ist das wichtig, dass eine State Machine als >> solche erkannt wird? Was hat das für Vorteile? > Meine Vermutung: Es hat keine Auswirkung auf die Synthese. Doch schon. Wobei es nicht um den Zustandsautomaten an sich geht sondern um die passende Implementierung derselben in die vorliegende Hardware. Falls die tools eine Beschreibung als FSM erkennen, dann können sie auch die Freiheitsgrade nutzen die bei der Implementierung der FSM vorhanden sind, wie: -Codierung -Realisierung des Zustandsspeicher durch Embedded RAM statt krauser Logic -resourcen sharing -logic level minimierung ..einfach mal in die Syntheseoptionen für FSM schauen. Es ist halt bei VHDL wichtig über den geschriebenen Code hinaus in die Hardware "zu schauen". http://aircconline.com/vlsics/V3N6/3612vlsics07.pdf
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.