Forum: FPGA, VHDL & Co. WHEN OTHERS in einer FSM


You were forwarded to this site from EmbDev.net. Back to EmbDev.net
von Thommy (Gast)


Lesenswert?

Hallo,

ich habe bisher meine FSM immer so beschrieben:
1
TYPE state_type IS (STATE1, STATE2, STATE3);
2
SIGNAL state : state_type ;
3
...
4
ELSIF rising_edge(CLK) THEN
5
  CASE state IS
6
    WHEN STATE1 => 
7
    WHEN STATE2 => 
8
    WHEN STATE3 => 
9
    WHEN OTHERS => state <= STATE1 ;
10
  END CASE;

Da der TYPE state_type aber nun keine anderen Zustände als STATE1-3 
kennt, ist der OTHERS Zweig ja ziemlich sinnlos und wird bei der 
Synthese nicht implementiert.

Wenn ich aber nun folgende Beschreibung wähle:
1
CONSTANT STATE1 : std_logic_vector(1 downto 0) := 00;
2
CONSTANT STATE2 : std_logic_vector(1 downto 0) := 01;
3
CONSTANT STATE3 : std_logic_vector(1 downto 0) := 10;
4
SIGNAL   state  : std_logic_vector(1 downto 0);
5
...
6
ELSIF rising_edge(CLK) THEN
7
  CASE state IS
8
    WHEN STATE1 => ... 
9
    WHEN STATE2 => ... 
10
    WHEN STATE3 => ... 
11
    WHEN OTHERS  => s_state <= STATE1 ;
12
  END CASE;

Hier wird der OTHERS Zeig implementiert und alles ist schön bzw. 
abgesichert gegen ungewollte Zustände...

ABER!!!!
In der Simulation des ersten Falles wird mir für state immer schön 
STATE1-3 angezeigt. Die states werden also auch in der Simulation in 
"Klartext" sichtbar gemacht.

In der Simulation des zweiten Falles wird mir nur die binäre Codierung 
des states angezeigt. Ich habe also statt STATE1 die 00 dastehen usw. , 
was das Lesen der Simulation etwas erschwert.

Kann ich den zweiten Fall beschreiben und dennoch die Klartextausgabe in 
der Simulation nutzen?
Ich dächte ich habe das schon einmal in einem Bsp. probiert und gemacht, 
aber ich finde die .vhd leider nicht mehr. Da es damals copy&paste war, 
kann ich mich auch nicht mehr daran erinnern :)

Vielen Dank!

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Thommy schrieb:
> Hier wird der OTHERS Zeig implementiert und alles ist schön
> bzw. abgesichert gegen ungewollte Zustände...
Und was wäre der Vorteil davon? Wie sollten denn diese ungewollten 
Zustände auftreten?

Diese manuelle Statevergabe hindert den Synthesizer daran, ein optimales 
Design zu erzeugen:
http://www.lothar-miller.de/s9y/categories/25-when-others

: Bearbeitet durch Moderator
von Fpgakuechle K. (Gast)


Lesenswert?

Lothar Miller schrieb:
> Thommy schrieb:
>> Hier wird der OTHERS Zeig implementiert und alles ist schön
>> bzw. abgesichert gegen ungewollte Zustände...
> Und was wäre der Vorteil davon?

Die FSM ist robust und bleibt nie in einem illegalen State hängen.

> Wie sollten denn diese ungewollten
> Zustände auftreten?

Shit happens. Beispielsweise durch sychronisierversagen, oder bit-Kipper
durch enrgetische Strahlung (Single Event Upset), race conditions bei 
asynchronen reset, schluckauf des OSC, etc..

Solch komplettes Ausdecodieren ist reine Vorsichtsmassnahme: Auch wenn 
der Fall höchst unwahrscheinlich, wenn doch behält man immer noch die 
Kontrolle. in manchen bereichen (Avionik, Space, medizin) besteht man 
darauf.

MfG

von Christian R. (supachris)


Lesenswert?

Du kannst die FSM doch nach Variante 1 beschreiben und dem Synthesizer 
sagen, wie er das umsetzen soll. Je nachdem, ob dann das Others 
gebraucht wird, oder nicht, gibts eine Info: "Case statement is 
complete. others clause is never selected". (Bei xst).

von Christoph Z. (christophz)


Lesenswert?

Fpga Kuechle schrieb:
> Solch komplettes Ausdecodieren ist reine Vorsichtsmassnahme: Auch wenn
> der Fall höchst unwahrscheinlich, wenn doch behält man immer noch die
> Kontrolle.

Richtig, das Ziel ist, dass wenn irgendwas 
unvorhergesehenes/unwahrscheinliches passiert, dass kein Dead-Lock 
entsteht.

Das Problem bei der urprünglichen Frage ist, dass es egal ist, wie die 
VHDL Beschreibung aussieht. Es kommt darauf an was der Synthesizer damit 
anstellt.

Bei VHDL für FPGAs gibt es keinen mir bekannten Grund eine FSM anders 
als mit einem Enumerationstyp zu beschreiben. Wie richtig geschrieben, 
macht es alles übersichtlicher und die Simulation angenehmer.

Klassisches Verilog kennt keinen Enumerationstyp, daher sind die 
Synthesizer darauf trainiert, eine FSM Beschreibung zu erkennen und 
diese auch so zu behandeln. Bei mir im Synplify Pro geht das soweit, 
dass ich mir ein graphisches State-Event Diagramm ansehen kann von 
meiner in VHDL beschriebenen FSM (z. B. um zu prüfen ob ich 
Zustandsübergange falsch beschrieben habe).

Und was macht der Synthesizer daraus? Er baut eine optimale FSM Logik 
auf mit einer frei gewählten Codierung (One-Hot, Gray, Bin,...) mit 
möglichst wenig Logik. (Hatten wir vor kurzem hier Diskutiert: 
Beitrag "Re: State_Maschine; Ausgang abhängig vom vorderen State")
Bei dieser Implementierung ist es in Extremfällen möglich, dass 
Dead-Locks auftreten könnten.

Wenn man aus Safety Gründen eine sichere FSM braucht, dann muss man das 
dem Synthesizer auch mitteilen. Beim Symplify Pro z. B. durch dieses 
VHDL Argument (Erzwingt eine sichere FSM mit Gray Codierung):
1
signal CurrentState, NextState : States;
2
3
attribute syn_encoding : string;
4
attribute syn_encoding of CurrentState : signal is "safe,gray";

von Holzer (Gast)


Lesenswert?

>eine sichere FSM braucht

Was bedeutet "sicher" ?   Können dann keine Deadlocks entstehen?

von Christoph Z. (christophz)


Lesenswert?

Ja, alle nicht verwendeten Zustände werden in die FSM Logik mit 
aufgenommen um immer in einen gültigen Zustand zu wechseln.

Zitat aus dem Synplifiy Handbuch:
"safe
This implements the state machine in the default encoding and adds reset 
logic to force the state machine to a known state if it reaches an 
invalid state. This value can be used in combination with any of the 
other encoding styles described above. You specify safe before the 
encoding style. The safe value is only valid for a state register, in 
conjunction with an encoding style specification.
For example, if the default encoding is onehot and the state machine 
reaches a state where all the bits are 0, which is an invalid state, the 
safe value ensures that the state machine is reset to a valid state.
If recovery from an invalid state is a concern, it may be appropriate to 
use this encoding style, in conjunction with onehot, sequential or gray, 
in order to force the state machine to reset. When you specify safe, the 
state machine can be reset from an unknown state to its reset state."

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Christoph Z. schrieb:
> Ja, alle nicht verwendeten Zustände werden in die FSM Logik mit
> aufgenommen um immer in einen gültigen Zustand zu wechseln.
Allerdings kann es durchaus einen undefinierten Übergang geben. Und ich 
bin mir sehr sicher, dass ich sogar so eine "sichere" FSM mit einem 
asynchronen Eingang einen Takt lang in die Ecke (also einen 
undefinierten Zustand) fahren kann...

von Holzer (Gast)


Lesenswert?

>und ich bin mir sehr sicher, dass ich sogar so eine "sichere" FSM mit einem
>asynchronen Eingang einen Takt lang in die Ecke (also einen
>undefinierten Zustand) fahren kann...


Wie fährst du sie denn in die Ecke trotz Abfangmechanismus?

von Holzer (Gast)


Lesenswert?

Oder anders formuliert: Was ist deiner Meinung nach die Schwachstelle 
der
Abfanglogik?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Holzer schrieb:
> Wie fährst du sie denn in die Ecke trotz Abfangmechanismus?
Wenn in der oben beschriebenen FSM mit ungültigem Zustand "11" vom 
Übergang z.B. von 00 nach 01 genau rechtzeitig mit der Flanke so etwas 
passiert:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
Da hilft die ganze eingebaute Verriegelungskombinatorik nichts, denn das 
andere Flipflop bekommt diese Pegeländerung einfach nicht mit --> es 
wird ein ungültiger Zustand aufgerufen.
Allerdings greift die Safe Implementation dann wie gesagt einen Takt 
später und springt einen gültigen Zustand an. Welcher das allerdings 
ist, das steht auf einem anderen Blatt...

> Oder anders formuliert: Was ist deiner Meinung nach die Schwachstelle
> der Abfanglogik?
Dass die FSM trotzdem nicht sicher richtig auf die Reihe kommt. Und dass 
die sichere Implementierung unglaublich/unnötig viel Ressourcen braucht, 
und dadurch auch das Design langsamer wird...

: Bearbeitet durch Moderator
von Holzer (Gast)


Lesenswert?

>Welcher das allerdings ist, das steht auf einem anderen Blatt...

Behauptet die "Synplify FSM Compiler"-Doku nicht, dass in den 
Reset-Zustand gesprungen wird?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Holzer schrieb:
> Behauptet die "Synplify FSM Compiler"-Doku nicht, dass in den
> Reset-Zustand gesprungen wird?
Ja, weiß das die Hardware?
In der realen Hardware gibt es nur LUTs und Flipflops. Eine FSM ist 
nichts Geheimnisvolles, sondern nur ein paar FLipflops und die 
zugehörige Logik. Und wenn die Logik nunmal unterschiedliche Laufzeiten 
hat, dann wird genau das passieren, was ich verlinkt habe. Es kann sein, 
dass die Wahrscheinlichkeit für einen Fehler durch so ein fehlerhaftes 
Design (ein asynchroner Eingang ist ein Fehler) reduziert wird, aber es 
wird sicher passieren können.

> Behauptet die "Synplify FSM Compiler"-Doku nicht, dass in den
> Reset-Zustand gesprungen wird?
Nur, wenn ein ungültiger Zustand erreicht wird. Wenn durch den 
asynchronen Eingang eine ungültige Transistion auf einen gültigen 
Zustand ausgelöst wird, dann läuft der Automat trotzdem Amok...

: Bearbeitet durch Moderator
von bko (Gast)


Lesenswert?

Also bleibt doch noch dieser Fall:

Fpga Kuechle schrieb:
> (...) bit-Kipper
> durch enrgetische Strahlung (Single Event Upset), race conditions bei
> asynchronen reset, schluckauf des OSC, etc..
>
> Solch komplettes Ausdecodieren ist reine Vorsichtsmassnahme: Auch wenn
> der Fall höchst unwahrscheinlich, wenn doch behält man immer noch die
> Kontrolle. in manchen bereichen (Avionik, Space, medizin) besteht man
> darauf.
>

Hier könnte eine "eine sichere FSM" im Sinne von
Beitrag "Re: WHEN OTHERS in einer FSM"
durchaus helfen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

bko schrieb:
> Hier könnte eine "eine sichere FSM" im Sinne von Beitrag "Re: WHEN
> OTHERS in einer FSM" durchaus helfen.
Und ab hier wirds dann eine Endlosschleife, denn auch diese sichere FSM 
ist wie erläutert nicht sicher im Sinne eines "sicheren Ablaufs", 
sondern nur im Sinne von "kommt bei einem ungültigen Zustand nach 1 Takt 
in den Default-Pfad".

von bko (Gast)


Lesenswert?

Lothar Miller schrieb:
> bko schrieb:
>> Hier könnte eine "eine sichere FSM" im Sinne von Beitrag "Re: WHEN
>> OTHERS in einer FSM" durchaus helfen.
> Und ab hier wirds dann eine Endlosschleife, denn auch diese sichere FSM
> ist wie erläutert nicht sicher im Sinne eines "sicheren Ablaufs",
> sondern nur im Sinne von "kommt bei einem ungültigen Zustand nach 1 Takt
> in den Default-Pfad".

Nö, denn was genau passiert in einem nicht codierten State?

Die Zahl der möglichen States ist halt immer modulo 2, also
codiere  ich z.B. 5 States, bekomme ich mindestens 3 Flipflops,
also mindestens 8 mögliche Zustände usw. 16, 32 ... .

Was nun wenn z.B. durch Strahlung (Single Event Upset) die FFs in der SM
den "6,7 oder 8" State springen (hatte ich schon)?
Wie stelle ich sicher das die SM dann nicht immer in den ungewollten
States bleibt?

Der Synthese sind diese Zustände erst einmal egal, nur wenn
explizit (durch Commandos an das Synthese-tool oder Codierung)
sage "Springe aus unbenutzten States in einen der 5 codierten", stelle
ich sicher das sie SM nicht in den unbenutzten States hängen bleiben
kann auch wenn es mehr Logic wird.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

bko schrieb:
> stelle ich sicher das sie SM nicht in den unbenutzten States
> hängen bleiben kann
Aber das ist doch gar nicht das von mir beschriebene Problem. Es geht 
darum, dass die FSM durch einen Fehler auch in einen gültigen aber 
trotzdem falschen Zustand springen kann. Das bringt u.U. dann trotzdem 
mein ganzes System durcheinander.

BTW: mir ist und wäre der zusätzliche Aufwand und die 
Geschwindigkeitsreduzierung für die "Safe Implementation" zu wenig 
Gewinn. Und nur die allerwenigsten Anwendungen sind tatsächlich von 
radioaktiver Strahlung betroffen. Ich habe zigtausend "unsichere" FSM 
weltweit laufen und mir sind keine Probleme damit bekannt.

von Christoph Z. (christophz)


Lesenswert?

Lothar Miller schrieb:
> Nur, wenn ein ungültiger Zustand erreicht wird. Wenn durch den
> asynchronen Eingang eine ungültige Transistion auf einen gültigen
> Zustand ausgelöst wird, dann läuft der Automat trotzdem Amok...

Das ist eine wichtige Anmerkung von dir.

Lothar Miller schrieb:
> Wenn in der oben beschriebenen FSM mit ungültigem Zustand "11" vom
> Übergang z.B. von 00 nach 01 genau rechtzeitig mit der Flanke so etwas
> passiert:
> 
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
> Da hilft die ganze eingebaute Verriegelungskombinatorik nichts, denn das
> andere Flipflop bekommt diese Pegeländerung einfach nicht mit --> es
> wird ein ungültiger Zustand aufgerufen.

Genau darum habe ich im gezeigten Beispiel dem Synthesizer gesagt, er 
soll eine Grey Codierung für die Zustände nehmen, da die 
Wahrscheinlichkeit für solche ungültigen Transitionen kleiner ist.

Lothar Miller schrieb:
> BTW: mir ist und wäre der zusätzliche Aufwand und die
> Geschwindigkeitsreduzierung für die "Safe Implementation" zu wenig
> Gewinn. Und nur die allerwenigsten Anwendungen sind tatsächlich von
> radioaktiver Strahlung betroffen. Ich habe zigtausend "unsichere" FSM
> weltweit laufen und mir sind keine Probleme damit bekannt.


Ich setze das hier aus Vorsicht im Bereich Leistungselektronik ein. 
Keine Ahnung was Schaltflanken von 800 V im 80 kHz Rhytmus mit meinem 
1,2 V FPGA anstellen... Bis jetzt läuft alles gut. Dieser FPGA stellt 
sicher, dass keine illegalen Schaltzustände gemacht werden können. Wenn 
das nicht klappt, dann fliegen uns die 8 Module à je 4 IGBTs (600 V, 300 
A) um die Ohren.
Da ist mir ein bisschen zusätzliche Logik egal :-)

von Hoecker (Gast)


Lesenswert?

Bezogen auf das Eingangsposting:

irgendein Zustand hat ja vermutlich den Folgezustand STATE_1. Spricht 
etwas dagegen, den case wegzulassen und durch OTHERS abzudecken?
Dann folgen sowohl auf diesen STATE_X und einen fehlerhaften 
undefinierten Zustand STATE_1.

von Christoph Z. (christophz)


Lesenswert?

Spricht dagegen:
- Synpflify Pro ignoriert bei einer FSM den OTHERS Zweig.
- Ich finde solche Konstrukte schlecht lesbar (entsprechend braucht es 
mehr Zeit bei der Fehlersuche)

von Hoecker (Gast)


Lesenswert?

War ja auch nur eine spontane Idee.

Punkt 1 ist aber ja schon ein ko Argument. Punkt 2 ist natürlich nicht 
von der Hand zu weisen, aber durch gute Dokumentation wenigstens zu 
entschärfen. Aber (1) sticht sowiso.

von Holzer (Gast)


Lesenswert?

Zusammenfassung: Der Synplify FSM Compiler verhindert Deadlocks. Alles 
andere liegt in der eigenen Hand.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Christoph Z. schrieb:
> Da ist mir ein bisschen zusätzliche Logik egal :-)
Es ist (m)ein Mantra: die zusätzliche Logik hilft dir nicht, wenn 
fehlerhafterweise ein falscher, aber gültiger Zustand angesprungen wird. 
Bei einem Zähler (der einfachsten FSM) mit einem "range 0 to 3000" 
könnte es also problemlos sein, dass gleich nach dem Wert 15 der Wert 
1040 kommt.

Christoph Z. schrieb:
> Spricht dagegen:
> - Synpflify Pro ignoriert bei einer FSM den OTHERS Zweig.
Wenn (mindestens) ein Zustand nicht explizit aucodiert wird, dann muss 
jeder Synthesizer den "others" Fall berücksichtigen, denn dort ist dann 
ja sicher ein Zustand enthalten. Allerdings wird dadurch auch keine 
zusätzliche Logik eingebaut, die von einem ungültigen Zustand zwingend 
wieder in (irgend)einen gültigen zurückführt. Sondern es wird eben nur 
genau dieser verbleibende und nicht berücksichtigte Zustand mit 
einberechnet.

Christoph Z. schrieb:
> Keine Ahnung was Schaltflanken von 800 V im 80 kHz Rhytmus mit meinem
> 1,2 V FPGA anstellen...
Mit dem FPGA intern gar nichts. Die Frequenzen sind viel zu niedrig, sie 
können mit den Strukturbreiten des FPGAs nichts anfangen. Und so kann es 
nur sein, was von aussen über die Leiterbahnen eingekoppelt wird. Mit 
einem halbwegs brauchbaren Layout ist das aber auch kein Problem...
> Bis jetzt läuft alles gut.
Ich drück dir die Daumen...  ;-)

von Christoph Z. (christophz)


Lesenswert?

Lothar Miller schrieb:
> Christoph Z. schrieb:
>> Spricht dagegen:
>> - Synpflify Pro ignoriert bei einer FSM den OTHERS Zweig.
> Wenn (mindestens) ein Zustand nicht explizit aucodiert wird, dann muss
> jeder Synthesizer den "others" Fall berücksichtigen, denn dort ist dann
> ja sicher ein Zustand enthalten.

Wenn du mir das so an den Kopf wirfst, tönt das sehr vernünftig und 
logisch. Wieso mein Kopf sowas nicht auch ausspucken kann...

Dann ist die Synplify "Warning", OTHERS Case Ignored, ja eher als "Lob" 
zu verstehen, dass ich alle States auscodiert habe. Auch gut zu wissen 
:-)

von Klaus F. (kfalser)


Lesenswert?

Thommy schrieb:
> In der Simulation des zweiten Falles wird mir nur die binäre Codierung
> des states angezeigt. Ich habe also statt STATE1 die 00 dastehen usw. ,
> was das Lesen der Simulation etwas erschwert.

Was auch noch niemand erwähnt hat, ist, dass es für den Simulator noch 
"others" Zustände gibt auch wenn "00", "01", "10", "11" angegeben sind, 
weil std_logic nicht nur '0' und '1' als Werte bietet, sondern 'Z', 'L', 
'X' usw.
Lässt man others weg, wird der Simulator meckern, dass nicht alle 
Zustände abgedeckt sind.
Bei der Synthese, gibt es nur 4 Fälle.

: Bearbeitet durch User
von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Klaus Falser schrieb:
> Was auch noch niemand erwähnt hat, ist, dass es für den Simulator noch
> "others" Zustände gibt
Naja, implizit habe ich das ganz oben mit dem Link auf meine HP schon 
getan. Mit 2 std_logic Bits ergeben sich 81 Möglichkeiten. 00 01 10 und 
11 sind nur 4 Kombinationen, so verbleiben für den Simulator noch 79 
"others"...

: Bearbeitet durch Moderator
von Schlumpf (Gast)


Lesenswert?

Unabhängig von der Sinnhaftigkeit, alle Zustände beschreiben zu wollen:
Wenn du wirklich die volle Kontrolle über jede erdenkliche 
Bitkombination deines Zustandscounters haben willst, dann wäre es 
vielleicht möglich  wenn du auch JEDEN Zustand codierst.
z.B. bei 5 "benutzen" Zuständen bleiben 3 "übrig". Die nennst du dann 
NOP1, NOP2, NOP3 und beschreibst sie in deiner FSM separat.

Oder in deinem Beispiel
1
CONSTANT STATE1 : std_logic_vector(1 downto 0) := 00;
2
CONSTANT STATE2 : std_logic_vector(1 downto 0) := 01;
3
CONSTANT STATE3 : std_logic_vector(1 downto 0) := 10;
4
CONSTANT NOP1   : std_logic_vector(1 downto 0) := 11;
5
SIGNAL   state  : std_logic_vector(1 downto 0);
6
...
7
ELSIF rising_edge(CLK) THEN
8
  CASE state IS
9
    WHEN STATE1 => ... 
10
    WHEN STATE2 => ... 
11
    WHEN STATE3 => ... 
12
    WHEN NOP1   => s_state <= STATE1 ;
13
  END CASE;

Fraglich ist nur, ob der Synthesizer erkennt, dass NOP1 nie angesprungen 
wird und damit die Logik dahinter wegoptimiert.. vermutlich schon.
Eventuell kann man dann noch mit einem "KEEP" Attribut ein Wegoptimieren 
verhindern. Aber da müsste man mal ein wenig rumspielen.

Meines Erachtens ist es aber in einem sauberen und synchronen Design 
völlig unnötig, alle Kombinationen auszucodieren.
Ich schließe mich da Lothar an.
Von mir sind auch tausende von FSMs im Feld am Laufen (industriellers 
Umfeld) und noch nie trat das Problem auf, dass sich eine verrannt 
hatte. Jedenfalls kam mir das noch nie zu Gehör. Aber bei mir platzen 
auch deswegen keine IGBTs :-)

von Lober (Gast)


Lesenswert?

>Von mir sind auch tausende von FSMs im Feld am Laufen

Soviele habe ich fast schon in einem einzigen FPGA ;-)

von Schlumpf (Gast)


Lesenswert?

Lober schrieb:
> Soviele habe ich fast schon in einem einzigen FPGA ;-)

Na dann solltest du ja auch imstande sein, deine Erfahrungen zum Thema 
mitzuteilen, denn bei einer so hohen Dichte an FSMs ist die 
Wahrscheinlichkeit eines Fehlereintritts natürlich auch entsprechend 
größer.
Wie codierst du? Mit "OTHERS" oder ohne? Und warum?
Oder klickst du nur die IP-Cores anderer Leute zusammen? ;-)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Schlumpf schrieb:
> Wie codierst du? Mit "OTHERS" oder ohne?
Ich verwende soweit sinnvoll eigens definierte Typen für FSM (wie im 
ersten Beispiel am Threadanfang). Da bleibt üblicherweise kein others 
übrig...

> Und warum?
Weil alle Probleme bisher nachweisbar von nicht einsynchronisierten 
Signalen oder einem unsauberen Reset kamen. Eine "sichere" FSM war nach 
Beheben dieser Fehler nie nötig. Allerdings habe ich auch nichts mit 
Raumfahrt am Hut und die nächsten 800V vom Zwischenkreis sind gute 20cm 
weit weg... ;-)

: Bearbeitet durch Moderator
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
Noch kein Account? Hier anmelden.