Mehr als eine State Machine pro process/architecture

[Andreas (Gast)]

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?

[Björn C. (bjoernc)]

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

[Andreas (Gast)]

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?

[Björn C. (bjoernc)]

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.

[Andreas (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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?