Grosse Statemachine

[Dimi S. (ilovespeccy)]

Hallo,

Gibt es Geschwindigkeits- oder andere Nachteile
bei grossen Statemachinen??? (60 States meinem Fall)

MfG

[fragender (Gast)]

wird ja wohl immer nur ein state behandelt...

[Klaus (Gast)]

Ja, es gibt das Problem, dass es ein write-only-code wird.

Niemand wird den Code nachher noch lesen oder verstehen können. Auch du 
nicht!

[Peter II (Gast)]

Klaus schrieb:
> Ja, es gibt das Problem, dass es ein write-only-code wird.
>
> Niemand wird den Code nachher noch lesen oder verstehen können. Auch du
> nicht!

muss nicht sein.

int state = 1;

while(1) {
   if ( taster == 1 ) {
     state++;
   }

   if ( state == 60 ) {
     state = 0;
   }

   PORTC= state;
}

Das ist eine Statemachine mit 60 zuständen und sie ist wunderbar lesbar.

[Klaus (Gast)]

Peter II schrieb:
> muss nicht sein.
>
> int state = 1;
> while(1) {
>    if ( taster == 1 ) {
>      state++;
>    }
>    if ( state == 60 ) {
>      state = 0;
>    }
>    PORTC= state;
> }
>
> Das ist eine Statemachine mit 60 zuständen und sie ist wunderbar lesbar.

Ich hab so im Urin, dass die Statemachine von Dimi S. anders aussieht 
;-)

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

Dimi S. schrieb:
> Gibt es Geschwindigkeits- oder andere Nachteile
> bei grossen Statemachinen???
Jein. Das kommt drauf an, wie was wann wo warum weitergeschaltet wird.

> (60 States meinem Fall)
Wenn ud diese Frage stellst und eine FSM mit 60 Zuständen hast, dann 
tippe ich auf eine umständliche Codierung. Und das kann dann durchaus 
Ressourcen und Geschwindigkeit kosten...

[(prx) A. K. (prx)]

Wenn die Statemachine nicht wie die Peter'sche Version linear 
fortschaltet, sondern wild zwischen den Zuständen hin und her springt, 
dann leidet nicht so sehr die Lesbarkeit des Codes, als vielmehr die 
Nachvollziehbarkeit des Ablaufs. Bei 60 solchen springenden Zuständen 
blickt rein aus Lektüre des Codes heraus niemand mehr durch, irgendwann 
auch nicht mehr der Urheber. Da muss sauber dokumentiert werden.

[Christian R. (supachris)]

Da kommt dann sowas wie die XAPP424 von Xilinx raus....da kann man sich 
mal angucken, wie man möglichst unübersichtlichen Code schreibt.

[Andi (chefdesigner)]

Na Xilinx bringt doch jede Woche eine App heraus, die zeigt, wie man 
Chaos produziert.

Die 60 states sind im Übrigen nicht viel. Das geht noch schlimmer.

[Dimi S. (ilovespeccy)]

Klaus schrieb:
> Ja, es gibt das Problem, dass es ein write-only-code wird.
>
> Niemand wird den Code nachher noch lesen oder verstehen können. Auch du
> nicht!

Das merke ich jetzt schon.

An sich ist die Statemachine noch zu verstehen. Die liest/schreibt
Speicher und I/O-Ports. Mein Design bestehr aus T80, 3 x i8055, i8059,
i8053 und noch ein Paar andere Dinge.
Ich habe auch versucht es zu teilen, dann verliere ich aber immer Takte,
die ich in meinem Fall brauche.
Ich meine das hier.

process1 : process(clk)
begin
...
case STATE1 is
...
   when WRITE_TO_SRAM =>
      WRSRAM_REQ <= '1';
      STATE1 <= WRITE_TO_SRAM_DONE;

   when WRITE_TO_SRAM_DONE =>
      if WRSRAM_ACK = '1' then
         STATE1 <= IDLE;
      end if;
...
end process;

process2 : process(clk)
begin
...
case STATE2 is
...
   when IDLE =>
      if WRSRA_REQ = '1' then
      ...
      ...
      HIER MEHRERE STATES, ES WIRD INS SRAM GESCHRIEBEN
      ...
      ...
   when XXX =>
      WRSRAM_ACK <= '1';
      STATE2 <= IDLE;
...
end process;

Wenn ich aber beide Statemachines zusammenpacke, spare ich
schon 2 Takte. Ich mene die Anfrage SRAM zu schreiben (WRSRAM_REQ),
und die Fertigmeldung (WRSRAM_ACK). Dann sieht es aber
entsprechend groß aus.

MfG

[Chris D. (myfairtux) (Moderator)]

FSMs designen wir immer per Graph - dafür haben wir passende Programme, 
die das nachher in entsprechenden C-Code gießen.

Da gibt es sicherlich auch etwas für Windows.

Per Hand wird das beliebig fehleranfällig.

Graphen und Zustandsbeschreibungen noch als PDF dazulegen und schon 
versteht jeder, was wo gemacht wurde.

Chris D.

[Matthias (Gast)]

Ich hab da auch schon eine recht umfangreiche, die auch immer wieder 
Erweiterungen bzw Änderungen braucht, weil alles hier ein wenig, naja, 
experimentell ist ;) . Die Semantik ist, dass Kommandos abgearbeitet 
werden, dh kann man immer wieder eine Reihe von States für sich 
abgeschlossen betrachten und mit einem Kommandonamen assoziieren. 
Inzwischen ziehe ich ein einheitliches Namensschema durch, wo jeder 
State "st_cmd_<Kommando_name>_<State_Nummer>" heißt. Damit kriegt man 
zwar immer noch nicht einen kompletten Kommandoablauf auf eine Seite 
aber man weiß wenigstens, wo man den Anfang und das Ende der Aktion zu 
suchen hat und hat eine gewisse Abstraktion, zu welchem Ablauf der State 
gehört.

Damit hab ich ganz gute Übersicht.

[Duke Scarring (Gast)]

Chris D. schrieb:
> Graphen und Zustandsbeschreibungen noch als PDF dazulegen und schon
> versteht jeder, was wo gemacht wurde.
Aha. Du meinst ungefähr sowas, oder?!
http://doc.gold.ac.uk/~ma503am/images/dot/bag.png

Matthias schrieb:
> Die Semantik ist, dass Kommandos abgearbeitet
> werden, dh kann man immer wieder eine Reihe von States für sich
> abgeschlossen betrachten und mit einem Kommandonamen assoziieren.
Vielleicht wollt Ihr das ganze mal in mehrere State-Machines zerlegen? 
Das könnte übersichtlicher werden. Oder Ihr verwendet eine 
programmierbare State-Machine (aka Prozessor)...

Duke

[Matthias (Gast)]

Naja, es ist eigentlich schon die zerlegte Variante ;) . Die zentrale 
State Machine hat zu diversen anderen State Machines auch nur mehr so 
mehr oder weniger Kommandointerfaces mit  Abstraktionen der Art "Lade 
den Datensatz Nummer x vom DDR2 in den Zwischenpuffer" oder "Stelle 
diese Elektrodengruppe mit diesen Parametern nach".

Es geht halt zum einen um die Steuerung einer recht komplexen Maschine 
wo vieles im Experimentalbereich ist und wo man auch viel ausprobieren 
muss. Zum anderen will man dann doch auch mal über einen bestimmten 
Vorgang sehr exakte Kontrolle haben, zb weil man einen bestimmten Fehler 
ausmessen will und dafür den Jitter beim Ansteuern einer Elektrode gegen 
0 bringen möchte (gibt genug andere Effekte, die für Messungen störend 
hineinspielen).

lg
Matthias

[Georg A. (Gast)]

Wäre evtl. Mikroprogrammierung was? Wenn viele Übergänge von denselben 
Bedingungen abhängen und es mehr lineare Abläufe als Verzweigungen gibt, 
hilft diesse Art der Entwicklung ziemlich. Jeder Schritt des Programms 
besteht dann aus den Kommandos an die anderen Einheiten und die 
Fortschaltung bzw. Verzweigung wird über ein Extra-Feld geregelt. Man 
kann das ganze dann zB. als Textfile schreiben (jeder Tabstop ein 
Kommando) und per Mini-C/Perl-Programm in Initdaten für Distributed RAMs 
umwandeln. Dann besteht das ganze Ding im wesentlichen aus RAMs und 
etwas Logik für den Sequencer.

[Chris D. (myfairtux) (Moderator)]

Duke Scarring schrieb:
> Chris D. schrieb:
>> Graphen und Zustandsbeschreibungen noch als PDF dazulegen und schon
>> versteht jeder, was wo gemacht wurde.
> Aha. Du meinst ungefähr sowas, oder?!
> http://doc.gold.ac.uk/~ma503am/images/dot/bag.png

Ja, so ungefähr ;-)

Allerdings mit umgekehrtem Weg: man malt das Programm quasi. Da kann man 
dann natürlich auch vernünftig gruppieren und zurechtschieben, so dass 
der spätere Graph übersichtlich bleibt :-)

Chris D.

[Rene B. (themason)]

Ich weiß zwar nicht ob ich mich nu in die Nesseln setze, aber ich 
versuchs mal :

Wäre es möglich die Statemachine vllt über ein Blockram zu realisieren ?
Ob das machbar ist oder nicht hängt dann davon ab wieviele effektive 
Signale den Zustand ändern können. Man kann es dann evtl auch so machen 
das man nur die Signale durchschaltet die in dem jeweiligen State bzw 
State-Gruppe Zustandswechsel erzeugen können. Damit verringert man dann 
die Anzahl der Eingangsvariablen und auch die Anzahl der benötigten 
Worte.

[zachso (Gast)]

@myfairtux: darf man erfahren was fuer tools ihr da einsetzt? ist ja 
vllt. doch mal interessant fuer den einen oder anderen

[Chris D. (myfairtux) (Moderator)]

zachso schrieb:
> @myfairtux: darf man erfahren was fuer tools ihr da einsetzt? ist ja
> vllt. doch mal interessant fuer den einen oder anderen

Bis zum März hatten wir ein selbstgeschriebenes Tool dafür. Seitdem 
benutzen wir (bzw. mein Mitarbeiter) ein leicht modifiziertes Qfsm. Das 
generiert Ragel-Code, den man dann in die entsprechende Zielsprache 
überführt.

Das Schöne dabei ist, dass man den Programmablauf dann direkt visuell 
hat und eigentlich gar keinen Code mehr schreibt. So etwas reduziert die 
Anfälligkeit für Fehler (zumindest hier).
Außerdem sieht man wortwörtlich, was das Programm macht - so etwas spart 
viel Kommentararbeit.

Es kann natürlich sein, dass die gesamte Maschine dann ausgedruckt gerne 
mal A2 oder A1-Größe hat ;-)

Ich selbst arbeite damit allerdings kaum - das ist einer der Bereiche, 
die mein MA besetzt und besser kann als ich :-)

Chris D.

[Harald F. (hfl)]

Jetzt geb ich doch noch meinen Senf dazu, habs mir ja lange überlegt. 
Zustandsautomaten mit vielen Zuständen sind IMHO nicht mehr oder weniger 
anfällig dafür, unübersichtlich zu werden, also solche mit wenigen 
Zuständen. Ich durfte schonmal einen Automat mit über 200 Zuständen 
modellieren, inklusive Änderungen nach einem halben Jahr. Wenn man das 
anständig hinschreibt und korrekt kommentiert, dann sollte das schon 
gehen. Eine sinnvolle Bezeichnung der Zustände und der E/A-Signale ist 
logischerweise Voraussetzung. Aber genau genommen, war das nicht die 
Frage des Treadstarters.

Dimi S. schrieb:
> Gibt es Geschwindigkeits- oder andere Nachteile
> bei grossen Statemachinen??? (60 States meinem Fall)

Es gibt sehr wohl die Möglichkeit, dass ein Synthesetool das 
Zustandsregister eines solchen Automaten aus 60 Flipflops baut und dann 
für die Berechnung der Gatterschaltung die Eingangssignale und alle 60 
Bits des Zustandsregisters verwendet. Alles schon mal da gewesen. Das 
führt dann zu einer großen und langsamen FSM. Es muss sicher gestellt 
sein, dass das nicht passiert, sonst gibt es die vom TS angefragten 
Geschwindigkeitsnachteile.

Grüße,
Harald

[Dimi S. (ilovespeccy)]

Guten Morgen!

Danke für Eure Hilfe!
Ich habe meine Statemachine ein wenig optimiert und jetzt
sieht die einigermaßen gut aus. Die erledigt 18 einzelne Aufgaben.
Jede Aufgabe besteht aus 1 bis 12 States. Jede Aufgabe hat eigene
Name bekommen. Direkt dahinter steht die State-Nummer.
z.B. Daten zum Interruptcontroller senden besteht aus folgenden
Schritten: PIC_WR_1, PIC_WR_2. u.s.w.

Harald Flügel schrieb:
> Es muss sicher gestellt
>
> sein, dass das nicht passiert, sonst gibt es die vom TS angefragten
>
> Geschwindigkeitsnachteile.

Ich werde heute Abend RTL meines Designs angucken.

MfG aus Westerwald