Hallo, ich sehe oft Beispiele von State Machinen mit zwei Prozessen(nur CLK im ersten Prozess, State<= Nextstate usw). Wieso wird das so gemacht? Was sind die Vorteile für diese Vorgehen. Warum nicht nur ein Prozess? Vielen Dank Viele Grüße
In der 2-Prozess FSM siehst du leichter was später FF werden (sollen). In der 2-Prozess FSM kannst du leichter kombinatorischen Mist machen und nicht synchrone Ausgänge erzeugen. Ist mehr ein Lesbarkeits-Ding, nicht zwingend besser. Ich verwende sie gar nicht. Patrick C. schrieb: > Welche Sprache ? Natürlich VDHL, in Verilog gibs blocking und non-blocking.
Erik B. schrieb: > Natürlich VDHL, in Verilog gibs blocking und non-blocking. Natürlich kannst du auch ein Verilog den Kombinatorischen vom Statelogik Zeug trennen... z.B. kuck hier http://www.asic-world.com/tidbits/verilog_fsm.html
Können ja, müssen nein. Es fehlt noch der Hinweis, dass ich auch ohne 2-Prozess FSM asynchrone Outputs haben kann, die vom State abhängen. ;)
Erik B. schrieb: > In der 2-Prozess FSM kannst du leichter kombinatorischen Mist machen Wie z.B. die bei Anfängern überaus beliebte kombinatorische Schleife... ;-)
markus schrieb: > Wieso wird das so gemacht? Was > sind die Vorteile für diese Vorgehen. Warum nicht nur ein Prozess? Wenn ich nur einen Prozess verwende, ist dieser zwangsläufig getaktet (sequentiell), d.h. alle Zuweisungen an Signale innerhalb des Blocks landen in einem Register - auch wenn eine Speicherung nicht erforderlich oder gewünscht ist. Registrierte Signale werden um jeweils einen Takt verzögert ausgegeben. Mit der Zwei-Prozess-Schreibweise lassen sich sequentielle und kombinatorische Logik trennen. Der erste Prozess ("State Register") ist sequentiell, der zweite ("Next-State-Logic") ein kombinatorischer (d.h. nicht getaktet). Grundsätzlich ist die FSM-Beschreibung nicht auf zwei Prozesse beschränkt, denkbar sind auch drei oder sogar vier Prozesse: 1. State Register (sequentieller/getakteter Prozess) 2. Next-State Logic (kombinatorischer Prozess) 3. Moore-Logic (kombinatorischer Prozess) 4. Mealy-Logic (kombinatorischer Prozess) Welche Form verwendet wird, kann von der Aufgabe, aber auch den Präferenzen des Autors abhängen. Es gibt verschiedene Schulen und jeder ihrer Änhänger hält "seine" Methode selbstverständlich für die einzig wahre. Entsprechende Fragen im Forum werden mit Threads nicht unter 50 Beiträgen bestraft ;-)
Burkhard K. schrieb: > Registrierte Signale werden um jeweils einen Takt > verzögert ausgegeben. Der Statz hat mich hellhörig gemacht, aber bei dem Prozess mit zwei wird doch auch alles um einen Takt verzögert?
markus schrieb: > aber bei dem Prozess mit zwei wird > doch auch alles um einen Takt verzögert? Nur die Ausgabe des getakteten Prozesses wird bis zum nächsten Takt verzögert. Die Ausgabe des kombinatorischen Prozesses erfolgt sofort. Da die Ausgabe des kombinatorischen Prozesses aber ausschließlich als Eingabe für den getakteten Prozess verwendet wird, ändert die State Machine ihre Ausgänge nur Taktsynchron.
Vancouver schrieb: > Nur die Ausgabe des getakteten Prozesses wird bis zum nächsten Takt > verzögert. Die Ausgabe des kombinatorischen Prozesses erfolgt sofort. Im XST User Guide "HDL Coding Techniques": ftp://ftp.xilinx.com/pub/documentation/misc/xstug_examples.zip findet sich unter HDL_Coding_Techniques/state_machines/state_machines_2.vhd ein konkretes Beispiel. Der erste Prozess enthält ein
1 | rising_edge(clk) |
Statement (und "clk" in der Sensitivity-Liste), dem zweiten Prozess fehlt dieses Statement; er ist daher kombinatorisch (hier steht dann "state" in der Sensitivity-Liste).
Vancouver schrieb: > Da > die Ausgabe des kombinatorischen Prozesses aber ausschließlich als > Eingabe für den getakteten Prozess verwendet wird Nicht zwingend, siehe https://de.wikipedia.org/wiki/Mealy-Automat
Beim Mealy nicht, das stimmt. Hatte jetzt nur den Moore im Kopf. Aber Mealy kann auch nicht vernünftig mit einer Ein-Prozess-Schreibweise implementiert werden. Außer man ist bereit, es richtig hässlich zu machen.
Vancouver schrieb: > Außer man ist bereit, es richtig hässlich zu > machen. Jetzt hast du mich neugierig gemacht. Wie in einem Prozess mit Clock, so dass er noch synthesefähig bleibt? Und komm mir jetzt nicht mit nebenläufigen weiteren Zuweisungen, das gilt nicht. ;)
Erik B. schrieb: > Und komm mir jetzt nicht mit nebenläufigen weiteren Zuweisungen, das > gilt nicht. ;) Ich fürchte, darauf würde es hinauslaufen. Wie bei einem asynchronen Reset, also außerhalb des 'if rising_edge()'-Scopes. Der asynchrone Reset ist der einzige Fall, wo man so etwas tun darf ohne vom VHDL-Gott mit einem Blitz gesteinigt zu werden. Ob das in anderen Fällen noch synthesefähig ist, habe ich nie probiert. Es gibt keinen rationalen Grund, das zu tun.
Vancouver schrieb: > Beim Mealy nicht, das stimmt. Hatte jetzt nur den Moore im Kopf. Aber > Mealy kann auch nicht vernünftig mit einer Ein-Prozess-Schreibweise > implementiert werden. Außer man ist bereit, es richtig hässlich zu > machen. Verwendet eigentlich noch jemand die M&M-Unterscheidung? Welche Signale gehen denn in heutige FPGAs noch vom Eingang unsynchronisiert auf irgendwelche FSMs und/oder von dort zusammen mit Eingängen direkt auf Ausgänge? Eine Abhängigkeit von Eingängen gemäss Mealy ist doch eigentlich obsolet, wenn man die FFs der Synchstufen als Zustand nimmt. Man könnte nun mikroskopisch bei der Fomulierung der FSM direkt variable Signale mit denen der FSM verknüpfen und behaupten, dass das eine Mealy Architektur sei - praktisch schnappt man sich aber aus der delay pipe der Signale nur das aus der vorherigen Zeitstufe. Die einzige Ecke wo man sowas heute noch findet, sind IO-Umschaltstufen, wo ein OE eines externen Prozessors direkt verknüpft werden muss, um irgendwelche IOs ansychron zum internen Takt oder Pseudosynchron zum externen Takt umzusetzen und wir kennen ja die Timingthemen rund herum.
Jürgen S. schrieb: > Verwendet eigentlich noch jemand die M&M-Unterscheidung? Im FPGA will man Moore benutzen, aber in Software ist Mealy kein Problem (damit spart man sich Zustände und kann schneller reagieren). Allerdings taktet man eine FSM (wenn man sie taktet) im Controller ein paar Größenordnungen langsamer.
Jürgen S. schrieb: > Verwendet eigentlich noch jemand die M&M-Unterscheidung? Den kleinen Unterschied zu kennen, kann bei kritischem Timinig hilfreich sein - Mealy spart in der Regel Zustände/Takte ein. Jürgen S. schrieb: > Eine Abhängigkeit von Eingängen gemäss Mealy ist doch eigentlich > obsolet, wenn man die FFs der Synchstufen als Zustand nimmt. Bei der Flankenerkennung des Eingangsignals sofern diese als Moore-Automat implementiert wurde. Eine Mealy-FSM dagegen schiebt am Eingang vorhandene Glitches während der Dauer des generierten Pulses an den Ausgang durch.
Jürgen S. schrieb: > Welche Signale gehen denn in heutige FPGAs noch vom Eingang > unsynchronisiert auf irgendwelche FSMs und/oder von dort zusammen mit > Eingängen direkt auf Ausgänge? Betrachte das nicht einfach auf den FPGA als ganzes, sondern einzelne Module. Dann kann man sehr wohl kombinatorische Ausgänge haben, um FF (Ressourcen) oder Takte (Timing) zu sparen. Solange "man weiß was man tut"(TM) und das Ziel ein internes FF unter Timing-Kontrolle ist, ist das auch gar kein Problem. Bei Ausgängen oder irgendwelchen Hardmacros kann es sehr wohl zu Hazards führen. Aber das liegt in der Natur der statischen Timinganalyse. ;) Und das Eingänge und Resets einsynchronisiert werden müssen, sollte eh klar sein, nicht wahr? :D
Erik B. schrieb: > Und das Eingänge und Resets einsynchronisiert werden müssen, sollte eh > klar sein, nicht wahr? :D Genau deshalb habe ich das ja angeführt :-) Damit hat man streng genommen keinen Mealy Automaten mehr. Den hat man insbesondere deshalb nicht, weil die FFs im FPGA (und das nehme ich jetzt mal her) hin und her getrieben werden und damit die entstehende Kombinatorik timing orientiert gesetzt wird. Im Extremfall wird damit die eigentliche Realisation der FSM eines formell aus Moore Automat formierten FSM eine Mealy und umgekehrt. Daher macht die Unterscheidung nur im Bezug auf die Art der Formulierung einen Sinn. Burkhard K. schrieb: > Bei der Flankenerkennung des Eingangsignals sofern diese als > Moore-Automat implementiert wurde. Eine Mealy-FSM dagegen schiebt am > Eingang vorhandene Glitches während der Dauer des generierten Pulses an > den Ausgang durch. Und genau das braucht kein Mensch. Im Gegenteil: Wir haben ja sogar gesehen, dass selbst die Formulierung als Moore in VHDL nicht 100% das Problem löst, wenn FFs wieder durch die Gegend geschoben und in das Design gedrängt werden. Man denkt, man habe ein von den Eingängen isoliertes synchrones Verhalten definiert und die Synthese produziert ein über das Design verteiltes Verhalten mit zeitabhängig der Eingänge. Siehe Reset-Diskussion
S. R. schrieb: > Jürgen S. schrieb: >> Verwendet eigentlich noch jemand die M&M-Unterscheidung? > > Im FPGA will man Moore benutzen, aber in Software ist Mealy kein Problem Richtig, aber wir sind ja hier im VHDL-Teil des Forums, und: Wenn man es pragmatisch sieht, ist Software mit seinen getakteten Funktionen auch eine Art von "Einsynchronisation" und damit eine Repräsentation eines synchronen Designs. Es ist sogar mit Bezug auf das im FPGA mitunter nicht perfekt handhabbare Problem der FSMs und FF Distribution sogar ein sehr! perfektes synchrones Design. Von daher kann man in SW ->scheinbar<- munter Mealys bauen, hat aber zu keinem Zeitpunkt die Probleme, die unter diesem Begriff bei HW-Entwicklung verbucht sind. Die Thematik macht eigentlich nur bei echten Bausteinen mit fixem Verhalten Sinn, wenn man in der Tat Signale (oder nennen wir sie besser Leitungen) um einen physischen Baustein herum geführt werden, dessen Speicherwirkung umgehen und damit echte Eingänge weiterverarbeitet werden. Im FPGA fallen mir da nur externe Resetleitungen und Taktleitungen ein, die auf PLLs gehen und weiter hinten im Design noch überwacht werden müssen. Die Timingprobleme und Budgetprobleme sind entsprechend denen der im Vorsatz erwähnten Schaltungen.
Jürgen S. schrieb: >>> Verwendet eigentlich noch jemand die M&M-Unterscheidung? >> Im FPGA will man Moore benutzen, aber in Software ist Mealy kein Problem > Richtig, aber wir sind ja hier im VHDL-Teil des Forums, und: Na und? Die Unterscheidung ist nach wie vor sinnvoll, und zwar mindestens in unterschiedlichen Bereichen. Jürgen S. schrieb: >> Und das Eingänge und Resets einsynchronisiert werden müssen, sollte eh >> klar sein, nicht wahr? :D > Genau deshalb habe ich das ja angeführt :-) Damit hat man streng > genommen keinen Mealy Automaten mehr. Das kann man zwar so sagen, aber es ist nicht besonders hilfreich. Ein Mealy-Automat, den man mit einsynchronisierten Eingangssignalen betreibt, liefert die Ausgangssignale trotzdem einen Takt früher, als ein vergleichbarer Moore-Automat es täte und er braucht, je nach Design, trotzdem weniger Zustände. Genau das sind die Schlüsseleigenschaften vom Mealy, und die bleiben erhalten. Dass man das in einem FPGA aus Routing- und Logikgründen möglicherweise nicht möchte, ist eine ganz andere Thematik. Und dass ein Mealy extrem streng genommen unsynchronisiert betrieben werden müsste, d.h. zwingend glitchende Ausgänge haben müsste, kann man zwar formal behaupten, aber es bringt einen in der Implementation auch nicht weiter. Jürgen S. schrieb: > Wenn man es pragmatisch sieht, ist Software mit seinen getakteten > Funktionen auch eine Art von "Einsynchronisation" und damit eine > Repräsentation eines synchronen Designs. Wenn du das so sehen willst, dann ist jede Form von Software synchron, nämlich zumindest mit der Taktfrequenz der CPU. Ich halte diese Form der Betrachtung aber nicht für zielführend, denn eine CPU glitcht prinzipbedingt nicht. Wenn du nämlich behauptest, dass es asynchrone Software eigentlich nicht geben kann, dann nimmst du denen, die mit mehreren Threads in Software arbeiten, deine Erfahrung und deine Lösungen zu genau den gleichen Problemen weg. Denn die gesamte Asynchronizitiätskacke taucht da wieder auf. Jürgen S. schrieb: > Die Thematik macht eigentlich nur bei echten Bausteinen mit fixem > Verhalten Sinn Einspruch. Die M&M-Thematik besteht aus der Frage "hängen die Ausgangssignale direkt von den Eingangssignalen ab oder nicht", mehr nicht. Das hat nichts mit der Technologie zu tun, in der der Automat realisiert ist und auch nichts von der Zeitskala, in der er betrieben wird. Es spielt keine Rolle, ob der Automat von einem Oszillator oder einem Stück Code getaktet wird. Das Prinzip ist in beiden Fällen das gleiche.
S. R. schrieb: > Na und? Die Unterscheidung ist nach wie vor sinnvoll, und zwar > mindestens in unterschiedlichen Bereichen. Ich hatte die Unterscheidung nicht als "nicht sinnvoll" bezeichnet, sondern nur ausgeführt, dass es bei FPGAs keinen effektiv großen Unterschied gibt. Diesen gibt es zwar in der Formulierung, führt aber bis auf die erwähnten Ausnahmen nicht zu einem wirklichen Gewinn von Geschwindigkeit oder Reaktionsfähigkeit des Designs: > Das kann man zwar so sagen, aber es ist nicht besonders hilfreich. Doch, das kann und muss man IMO auch so sagen, weil es hilfreich für das Verständnis ist, denn: > Ein Mealy-Automat, den man mit einsynchronisierten Eingangssignalen > betreibt, liefert die Ausgangssignale trotzdem einen Takt früher Das tut er in Betrachtung der Zeitebene auf die man die FSM formuliert, ja. Aber da in einem FPGA die Kombinatorik das Langsame ist und zudem die Designs heute sehr hoch getaktet werden, ist der Vorteil minimal, weil letztlich das kombinatorische Budget das Timing bestimmt - insbesondere in breiten FSMs - überproportional. Dieses Verständnis ist schon wichtig. Sieh den parallelen thread zum schnellen auslesen des BRAMs. > Dass man das in einem FPGA aus Routing- und Logikgründen möglicherweise > nicht möchte, ist eine ganz andere Thematik. Das ist aber genau die Thematik, die hier angefragt ist: Mealy Moore in FPGAs :-) Dass Du das Thema Microprozessor parallel eingeführt hast und es da Unterschiede in der Interpretation gibt, ist unbenommen. > streng genommen unsynchronisiert betrieben werden müsste, d.h. zwingend > glitchende Ausgänge haben müsste, kann man zwar formal behaupten, aber > es bringt einen in der Implementation auch nicht weiter. Doch, denn das ist der Punkt: Die FSM in einem FPGA darf nicht isoliert als ein Block gesehen werden, sondern deren Funktion wird infolge jeglicher heute applizierter Optimierungen in das Design, die Terme und die LUTs hinein verteilt, es sei denn man formuliert ausdrücklich failsave modi und Redundanzen. In diesen beiden Fällen wären die Fälle der FSM real(er) exisistent, gekapselt und observierbar, da sie ausdrücklich gerettet werden müssen und damit wäre ein M<->M theoretisch unterscheidbar, aber dann verbieten sich Mealies um so mehr, weil dann die Funktion des Observierens und Rettens nicht mehr gegeben ist. Ich habe den Einwurf nicht ohne Grund gemacht. Man muss sogar im Hinblick auf sicherer FSMs auf die Formulierung von Mealy verzichten, weil diese nicht gut schützbar sind und erst umgebaut werden müssen (wasim Übrigen passiert!) > Wenn du das so sehen willst, dann ist jede Form von Software synchron, > nämlich zumindest mit der Taktfrequenz der CPU. Ich halte diese Form der > Betrachtung aber nicht für zielführend, denn eine CPU glitcht > prinzipbedingt nicht. Richtig SW glitchet nicht und deshalb gibt es das Problem auf Taktebene (und das ist die Betrachtungsebene des M&M) nicht. Das war meine Aussage. Daher ist Dein Beispiel kein Gegenargument. Dein neues Beispiel ist wiederum deshalb keines, weil Multitasking-Themen auf einer Datentaktebene höher laufen und damit in einer anderen Zeitebene: > dann nimmst du denen, die mit mehreren Threads in Software > arbeiten, deine Erfahrung und deine Lösungen zu genau den gleichen > Problemen weg. Nein, die Lösungen der MT-Probleme sind anderer Natur, da auch das Problem anderer Natur ist. Es ist nämlich ein Problem der Quasi-Gleichzeitigkeit, die man in der SW real nicht hat und die eine händische Synchronisation auf Datentaktebene nach sich ziehen muss. Das ist nebenbei ein Problem, dass man im FPGA auf Systemtaktebene durchaus nicht, wohl aber auch auf Datentaktebene, wenn sich Schaltungsteile mit einander unterhalten. Mein Postulat, dass es in SW das Problem nicht gibt, impliziert also nicht, daß es damit keine Multitaskingprobleme gibt und die Softwareentwickler hier keine Aufgaben hätten. > die gesamte Asynchronizitiätskacke taucht da wieder auf. Interessanter Begriff. Wie im Satz obendrüber verdeutlicht, muss man Datentaktung von Systemtaktung trennen, die nicht notwendigerweise identisch sind. In einem MT-System hat man - wenn man nichts gesondert unternimmt - einen nicht vorhersagbaren Datentakt, bis hin zu einem gänzlichen Verdrängen unter Verlangsamung eines Prozesses - mit den entsprechenden Problem. Das ist schon ein anderes Thema. > Einspruch. Die M&M-Thematik besteht aus der Frage "hängen die > Ausgangssignale direkt von den Eingangssignalen ab oder nicht", mehr > nicht. Das hat nichts mit der Technologie zu tun Selbstverständlich hat das mit der Technologie und Umsetzung zu tun, denn wie ja die Diskussion zeit, hat das gleiche Prinzip zweier Methoden in unterschiedlichen Bereichen völlig unterschiedliche Ausprägungen. Meine Aussage war, dass Mealy/Moore bei Automaten in FPGAs eine gänzlich untergeordnete Rolle spielen. Die Ausnahme sind sehr langsam getaktete FPGAs im Bezug auf die Signaländerungen an den Eingängen und deren Budget. Die Bussignale eines schnellen Prozessors, der selber in der Größenordnung des FPGA-Takts arbeitet, sind solche Signale. Innen drin, konnte man nur früher noch was rauskitzeln, wenn man Signale stark kombinatorisch verdrahte hat und schneller FSMs bauen. Ab einer gewissen Größe geht das bei heutigen Taktraten so rasch in die Knie, dass es zum Aufrechterhalt designweit Extra-FFs benötigt werden. Diese lassen sich aber mit extremer Mealy-Verdrahtung nicht einfügen, oder werden dank Resynthe austomatisch von anderswo beigezogen. Die Response des Designs ist dann nicht besser. Das hängt auch damit zusammen, dass heute FPGAs kaum noch rein kombinatorische Elemente haben. In den Slices sitzen immer FFs drin und die sind nicht ohne Grund dort implementiert worden. Ich bevorzuge immer Moore-Formulierungen mit eindeutigem Bezug auf den state. Das vereinfacht auch die Verifikation.
Irgendwie scheint das Thema einen viralen Punkt getroffen und eine "Glaubensdiskussion" ausgelöst zu haben. Zurück zum TO: Warum 2 Prozesse? Manche Probleme Abläufe Sequenzen lassen sich leichter (ggf. sogar nur) als Mealy-Automaten beschreiben. Jürgen S. schrieb: > Ich bevorzuge immer Moore-Formulierungen mit eindeutigem Bezug auf den > state. Das vereinfacht auch die Verifikation. Die bevorzuge ich auch und nutze sie, wo und wenn möglich. Jedoch haben beide Formulierungen ihre individuellen Vor- und Nachteile, so dass ich in der Praxis doch überwiegend bei Mealy-Automaten lande. Dabei ist mein Blickwinkel auf die FSM eher lokal auf das Modul beschränkt (welche jedoch synchrone Signale von anderen Modulen bekommen). Global gesehen, also den gesamten FPGA betrachtend, ist das natürlich ein großer Moore-Automat. Als einer der Gründe, warum bei mir immer wieder Mealy daraus wird, ist die Latenz. Beim Moore habe ich immer mind. einen Takt Latenz, bei Mealy geht es auch ohne. Das kann bei Ready/Valid Interfaces relevant sein, da es oft den Durchsatz bestimmt. Mealy-Automaten haben m.M.n. einen zu Unrecht schlechten Ruf. Ja, sie bergen vor allem für Anfängern viele Fettnäpfchen (kombinatorische Schleifen, unerkannte asynchrone Eingangssignale, doppelte State-Schreibweise, schlechteres Timing, etc), sind aber mit ein wenig Übung und Verifikation handhabbar. Manchmal empfinde ich die Schreibeweise aber auch als die Kürzere (Thema K.I.S.S.), da ich oft weniger States benötige (wie bereits erwähnt). Damit sind dann oft auch die State-Übergänge einfacher und es entfällt ggf. nötige "LookAhead"-Logik, der nötig wäre, um den Moore auf trap zu bringen. Daher würde ich sagen, jeder sollte den Weg nehmen, der für ihn angenehm ist. Manchmal ist die Entscheidung klar, aber meistens ist sie doch eher subjektiv und geschmackssache.
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.