Hallo Zusammen, darf man zwei Zustandsautomaten in dem selben Process verwenden? Danke im Vorraus ;)
P. K. schrieb: > Feel free! Schön gesagt :-) Wer sollte das auch verbieten (es sei denn man hat firmeninterne Codingrichtlinien).
Mark schrieb: > darf man zwei Zustandsautomaten in dem selben Process verwenden? Ein simpler Zähler ist auch ein Zustandsautomat... Und somit ein klares "Ja!"
Mit Zustandsautomat ist aber eigentlich eher was verzweigtes gemeint und dann auch etwas komplizierter. Unterschiedliche Aufgaben gruppiert man immer in unterschiedlichen Prozessen. Auch der Optimierung der Simulation wegen. Wenn sie aber eng zusammen hängen, fragt man sich wozu 2 FMs gebaut werden und nicht eine?
M. Fritsch schrieb: > Wenn sie aber eng zusammen hängen, fragt man sich wozu 2 FMs gebaut > werden und nicht eine? Siehe z.B. den http://www.lothar-miller.de/s9y/archives/51-Konfigurierbarer-SPI-Master.html Dort sind auch zwei FSM verschachtelt. Das basiert auf dem http://www.lothar-miller.de/s9y/archives/50-Einfacher-SPI-Master-Mode-0.html und dann wird die Erweiterung unmittelbar sichtbar...
Mark schrieb: > Hallo Zusammen, > darf man zwei Zustandsautomaten in dem selben Process verwenden? Man kann sogar das gesamte design in einen einzigen process schreiben (solange man nur einen Takt und evtl. reset hat), das ist aber keine gute Idee. Oft wird sogar schon eine einzelne fsm auf zwei process oder mehrere Processe aufgeteilt. Früher hatten die Synthesetools Probleme bei großen FSM's mit Zählern, da ging ihnen der Arbeitsspeicher beim Optimieren aus. Da hat man wohl versucht alle FF in einem process auf einmal zu optimieren. Mglw. setzt auch der Synthese style guide deines Tools Grenzen. Gegenfrage, was ist der Vorteil mehrere FSM in einem Process zu schreiben? MfG,
Lothar Miller schrieb: > Dort sind auch zwei FSM verschachtelt. Das basiert auf dem Das wäre aus meiner Sicht EINE zusammengehörige FSM und daher noch sinnvollerweise zusammen zu schreiben. So ist es auch nach unseren internen Coding Vorgaben geregelt. Aber Dinge die nichts mit andender direkt zu tun haben gehören auseinander. Die FSM werden bei uns auch in den Dokumenten bezeichnet, nummeriert und beschrieben - samt Ablaufdiagramm
M. Fritsch schrieb: >> Dort sind auch zwei FSM verschachtelt. Das basiert auf dem > > Das wäre aus meiner Sicht EINE zusammengehörige FSM und daher noch > sinnvollerweise zusammen zu schreiben. Ja, so gehen die Ansichten auseinander. Wie ist das dann mit em besagten Zähler, der nach 100 Takten einen Zustand weiterschaltet? Der müsste dann konsequenterweise auch auscodiert werden und die "eine" FSM 100 Zustände mehr bekommen... > So ist es auch nach unseren internen Coding Vorgaben geregelt. Warum? Oder eher: warum schränkt ihr euch so unnötig ein? Solche künstlichen Beschränkungen und enge Coding-Styles verhelfen m.E. VHDL zum Ruf "geschwätzig und umständlich" zu sein...
:
Bearbeitet durch Moderator
Lothar Miller schrieb: > Wie ist das dann mit em besagten Zähler, der nach 100 Takten einen > Zustand weiterschaltet? Der müsste dann konsequenterweise auch > auscodiert werden und die "eine" FSM 100 Zustände mehr bekommen... Kann ich mithalten... Eine Sensornachbildung (Sensor hat natuerlich einen kleinen uC im Package). Die 1. FSM hat jetzt mal ganz grob das Verhalten (auch bei PON) nachgebildet. Dann der Teil wenn das Ding mal laeuft: Die Opcodes. Innerhalb dieser Opcodes dann noch Pipelining... Wenn man sich das dann mal ganz genau ueberlegt, dann strukturiert man das in eine FSM. Und damit haben: * Alle Aktionen eines Opcodes, und * Die Steuerung der FSM jeweils auf eine Bildschirmseite gepasst (es waren eine ganze Menge Opcodes). Haette ich das in getrennte Prozesse ausgelagert, dann haette ich wohl 2x woechentlich die PageUp/Down Tasten auswechseln muessen... Ich denke: Es kommt halt immer darauf an... (was jetzt gerade sinnvoll ist, und ja, manchmal macht dann umschreiben auch Sinn)
Vielen Dank für eine bereitschaft zum Helfen. Ich muss 2 FSMs nehmmen, weil der 1. FSM mit einem Clock-Enable arbeite muss und der andere muss ohne.
Mark schrieb: > Vielen Dank für eine bereitschaft zum Helfen. Ich muss 2 FSMs nehmmen, > weil der 1. FSM mit einem Clock-Enable arbeite muss und der andere muss > ohne. Notiz für nächste Revision Codierstyle: FSM's mit unterschiedlichen CE an State-FF nicht in einem gemeinsamen Prozess kapseln. MfG
Mark schrieb: > kannst du mir sagen, warum darf ich das nicht tun? Du darfst es. Es trifft nur nicht Fpga Kuechles persönlichen Geschmack (und möglicherweise den von anderen auch nicht). Es geht also nur um die Frage, was andere und du selber als übersichtlich und gut lesbar empfindest.
Mark schrieb: > Ich muss 2 FSMs nehmmen, weil der 1. FSM mit einem Clock-Enable > arbeite muss und der andere muss ohne. Wer erzeugt den CE der 1. FSM? Haben die beiden FSM funktionell miteinander zu tun? Oder wie kommt so eine Zusammenfassung zweier FSM zustande?
Olga schrieb: > Mark schrieb: >> kannst du mir sagen, warum darf ich das nicht tun? > > Du darfst es. Es trifft nur nicht Fpga Kuechles persönlichen Geschmack > (und möglicherweise den von anderen auch nicht). Es geht also nur um die > Frage, was andere und du selber als übersichtlich und gut lesbar > empfindest. Moin, mit Empfindung und Geschmack hat das weniger zutun als mit persönlicher Erfahrung. Mit dem richtigen codestyle tretten weniger Fehler auf oder werden schneller gefunden und dritte können sich schneller darin zurechtfinden. Hier konkret: 1) Ein If über ein längliches case construct wird leicht übersehen und hier gibt es ZWEI längliche case: eins mit und eins ohne ce-IF. Da sind Verständnissfehler vorprogrammiert. 2) ce-fsm sind Fehleranfälliger als fsm die jeden Takt weiterschalten: Bei ersten genügt es das das Eingangssignal kürzer als die ce-periode ist um nicht sicher gesehen zu werden -und so verlorengeht. Folglich muss man bei jeden Einganssignal sicherstellen das es lang genug aktiv ist. Einen vollständigen Test darauf erreicht man in dem man diese ce-fsm in eine eigene Entity "kapselt" und deren fsm eingänge (die die die zustandsübergange triggern) per assert überwacht. Bei einer Mischform "verpasst" man schon ein signal das dann ungünstigerweise aus der nicht-ce domain kommt und kürzer als die ce-periode ist. Das führt dann je nach Phasenlage zu Zustandswechsel oder nicht. Kritische Stellen immer vollständig identifizieren und angepasst testen. 3) Die Abfolge der if elsif end if bestimmt bspw. bei Xilinx ob das FF otpimal genutzt wird, also auch R und S input und nicht nur D u. CE. Bei einer Mischform (die ce-fsm wird aud ce-FF) aufgebaut ist das nicht unbedingt gegeben, die Syntheserealisierung kann also langsamer sein als nötig. Siehe http://www.xilinx.com/support/documentation/white_papers/wp275.pdf Wie olga schon bemerkte, man kann verschiedene FSM in einen process packen, aber nach meiner Erfahrung schiesst man sich dabei selbst ins Knie. MfG,
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.