Hallo,
ich habe bisher meine FSM immer so beschrieben:
1
TYPEstate_typeIS(STATE1,STATE2,STATE3);
2
SIGNALstate:state_type;
3
...
4
ELSIFrising_edge(CLK)THEN
5
CASEstateIS
6
WHENSTATE1=>
7
WHENSTATE2=>
8
WHENSTATE3=>
9
WHENOTHERS=>state<=STATE1;
10
ENDCASE;
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
CONSTANTSTATE1:std_logic_vector(1downto0):=”00”;
2
CONSTANTSTATE2:std_logic_vector(1downto0):=”01”;
3
CONSTANTSTATE3:std_logic_vector(1downto0):=”10”;
4
SIGNALstate:std_logic_vector(1downto0);
5
...
6
ELSIFrising_edge(CLK)THEN
7
CASEstateIS
8
WHENSTATE1=>...
9
WHENSTATE2=>...
10
WHENSTATE3=>...
11
WHENOTHERS=>s_state<=STATE1;
12
ENDCASE;
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!
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
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
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).
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):
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."
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...
>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?
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...
>Welcher das allerdings ist, das steht auf einem anderen Blatt...
Behauptet die "Synplify FSM Compiler"-Doku nicht, dass in den
Reset-Zustand gesprungen wird?
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...
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.
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".
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.
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.
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 :-)
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.
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)
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.
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... ;-)
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
:-)
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.
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"...
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
CONSTANTSTATE1:std_logic_vector(1downto0):=”00”;
2
CONSTANTSTATE2:std_logic_vector(1downto0):=”01”;
3
CONSTANTSTATE3:std_logic_vector(1downto0):=”10”;
4
CONSTANTNOP1:std_logic_vector(1downto0):=”11”;
5
SIGNALstate:std_logic_vector(1downto0);
6
...
7
ELSIFrising_edge(CLK)THEN
8
CASEstateIS
9
WHENSTATE1=>...
10
WHENSTATE2=>...
11
WHENSTATE3=>...
12
WHENNOP1=>s_state<=STATE1;
13
ENDCASE;
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 :-)
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? ;-)
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... ;-)