Hallo, ich habe eine Frage zu State Machines. Ist es möglich mehr als eine State Machine in einer Architecture und/oder Process zu haben. Also im Prinzip so was: architecture... process() begin case state1 is when x => when y => end case case state2 is when u => when v => end case; end process; process() begin case state3 is when p => when r => end case; end process; end architecture; Kann man das so verstehen was ich meine?
ja prinzipiell ist es möglich mehr als eine FSM in einer architecture zu verfassen. Jedoch kann dadurch die gesamte architecture unübersichtlich werden da du ja noch die Ausgänge irgendwo berechnen musst und das würde ich dann in einer architecture kapseln und die zweite FSM in einer anderen Datei mit einer neuen architecture verfassen. Ich frage mich, was denn gegen zwei getrente architectures spricht? Der Codeschnipsel ansich naja - so wirklich hilft dieser nicht weiter um die Frage zu verstehen. Im Gegenteil, der Codeschnipsel verwirrt mich eher - da ich mich derzeit frage, was du mir damit sagen möchtest. ;) mfG Björn
Hallo, erst mal dane für die schnelle Antwort. Das Problem auf das ich hinaus wollte ist, dass ich die vorkommenden States vorher definieren muss. Also sowas: Type State_type is (x,y,u,v,p,r); signal state1, state2, state3: State_type; Aber nun weiss ja z.B. state1 nicht, dass er u,v,p,r nicht annehmen kann/soll sondern nur x oder y. Das heisst in den case- Anweisungen muss doch jeweils auch ein leeres "other" vorkommen, da sonst nicht alle möglichen cases abgedeckt sind wie es Vorschrift ist. Also so was: process begin ... case state1 is when x => Anweisung_was_auch_immer: state1 <= y; when y => Anweisung_was_auch_immer_2; when others => end case Das gleiche gilt auch für die anderen States. Nun wollte ich wissen ob die leeren "öthers" ein Problem erzeugen können?
leere others ? Was soll das sein? VHDL oder die Synthese macht nur das was du ihm sagst. Sprich wenn state1 = nur X,Y,Z annehmen darf dann kannst du mittels others ein Latch vermeiden. Jedoch die Tatsache dass du mehrere States hast, die du pro Signal nicht benötigst macht mich Stutzig, weil du dadurch mehr Register benötigst. Dies liegt daran, dass du mehr Bits benötigst um die States im Signal abzubilden.
Ich hab mir überlegt, mit einer State Machine einen Zähler mit einem counter_out Ausgang zu generieren, den ich dann dann in anderen State Machines verwenden wollte um Abhängig davon andere Anweisungen und States zu steuern. Aber ich bin mir eben nicht sicher ob das eine gute Idee ist. Oder ob ich versuchen sollte alles in eine State Machine zu packen.
Andreas schrieb: > Ich hab mir überlegt, mit einer State Machine einen Zähler mit einem > counter_out Ausgang zu generieren, Jeder Zähler an sich ist eine FSM, die einfach immer in den nächsten zustand weiterschaltet... > den ich dann dann in anderen State Machines verwenden wollte um > Abhängig davon andere Anweisungen und States zu steuern. Das hört sich an, wie wenn du irgendwas ganz Normales entweder nur umständlich machen willst oder noch nicht ganz verstanden hast... Denn diese Aussage ist so global, unbestimmt und theoretisch, dass alle Antworten von gut bis schlecht, top bis flop, üblich bis hirnrissig ohne Einschränkung möglich sind. Kurz: was willst du denn da tatsächlich machen?
Bitte 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.