www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Statemachine hängt sich weg


Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo schon wieder,

bin noch immer bei der Inbetriebnahme meines Design. Habe das Problem,
das mein Zustandsautomat (STATECad) sich ab und an weghängt.
Der Automat besteht aus 12 Zuständen, die ich zwecks Test nach außen
geführt habe (kann dann den jeweiligen  Zustd. mit Scope messen).

Jetzt passiert es, das von einem Zustand in den Ausgangsszustand
gesprungen wird, obwohl dies nach den Transition-Bedingung nicht
möglich ist. Es besteht gar nicht die Möglichkeit von diesem Zustand in
direkt in den Ausgangszustand zu springen.
Danach hängt der Automat. Auch wenn dann die Bedingung erfüllt ist um
jetzt aus dem Ausgangszustand in Zustand 1 zu wechseln, tut sich nix
mehr.

Habe schon alle Bedingungen geprüft und Statecad meckert auch nicht.
Woran kann das liegen? Hat jemand einen Tip?

Grüße Daniel

Autor: Mäxchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, alle Statemachines sind gleich und jede verhält sich genau so,
auch das Einschalten einer Glaskugel kann man als Statemachine sehen.
Allerdings braucht man da nicht 12 States, mehr als 5 States halte ich
schon für ein Abenteuer. Poste doch mal die Diagramme oder den Code,
dann kann Dir vielleicht Rufus T. helfen.

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bist Du sicher, dass nach der Synthese noch eine Statemachine vorhanden
ist? Ist alles synchron?

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ist alles synchron - läuft auch eine gewisse Zeit.
Steigt dann aber willkürlich aus.

Der AUtomat läuft auf jeden Fall mehrmals komplett und richtig durch
bis er dann immer vom gleichen Zustand zurück in den Anfangszustand
kommt, was theoretisch nicht möglich ist.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Codierfehler oder reset wird aktiv, mehr lässt sich ins blaue Hinein
nicht sagen.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reset ist geprüft. Was meinst Du mit Codierfehler?

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mit Codierfehler wird wohl die Zustandcodierung bei der Synthese für
Deine SM gemeint sein. Es gibt mehrere Codierungsmöglichkeiten (Gray,
One-Hot, Sequentiell), die Du im Synthesetool für FSM Encoding
einstellen kannst...

Ich habe auch Probleme mit der Implementierung meines Designs, dass mit
FSMs aufgebaut ist und suche derzeit noch nach einer Lösung.
Irgendwie bekomme ich periodisch Bitfehler eines empfangenen
Datenstroms, die über einen entwickelten VHDL Coder gehen.

Gruß
Tom

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kenne ich...

Frägst Du asynchrone Signale von aussen ab?
D.h. überprüfst Du Signale von aussen um innerhalb deines
Zustandsautomaten den Zustand zu wechseln?

Falls ja, setz mal hinter den betreffenden Eingang ein zusätzliches
Flip-Flop:


signal eingang_reg : std_logic;

process(clk,rst)
begin

  if(rst) then
    eingang_reg <= '0'; -- oder '1', je nachdem
  elsif(rising_edge(clk)) then
    eingang_reg <= eingang;
  end if;

end process;


Anstatt jetzt "eingang" abzufragen, benutzt Du "eingang_reg".

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Xenu:

Jepp, frage die eingesampelten asynchronen, externen Daten in der FSM
ab. Quasi sampel ich die jeweilige Bitclock mit 3 FF ein und frage mit
dem FF 2 und 3 die ansteigenden Flanke ab der Bitclock ab, während ein
Freigabesignal und die Datenbits (serielle), die von der jeweiligen
Bitclock abhängen, auf ein jeweiliges FF gehen.
Nach erkannter ansteigenden Flanke des Bitclock Taktes( 2 oder 3
Systemclocktakte, je nach Entscheidung des ersten FF(Metastabilität))
wird, je nach Bedingung, der jeweilige Zustand der FSMs ausgeführt....

Meine Post-PAR-Simu stürzt nach Stunden ab, die funktionale Simu klappt
astrein.

Ich weiß nicht so recht weiter, da ich periodisch auftretende Fehler
bekomme, die einen Codierfehler eher ausschliessen, da dieser ja
dauerhaft anstehen würde. Irgendwie sieht es nach einem Wandereffekt
aus...

Gruß
Tom

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS.:

Meine FSMs sind Ein-Prozess Darstellungen, d.h. die Übergangszustände,
Ausgangszustände und aktuellen Zustände sind innerhalb eines Prozesses
untergebracht. Somit ist alles, FSM und Einsample-Mechanismus in einem
Prozess untergebracht.

Gruß
Tom

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PSS: quasi ist ein Zustand auch der Coder, der momentan noch mit einer
For-Schleife und Variablen realisiert ist. Ich habe aber auch eine
bedingte Verschachtelung in Petto...
Nunja, in der Simu ist alles astrein, nur haperts noch in der
Implementierung.....!!!

Und die Sanduhr läuft und läuft.... ;-)

Gruß
Thomas

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

mußte gestern mal eher Feierabend machen. Also, ihr scheint euch da ja
um einiges besser auszukennen als ich. Also, ich benutze Xilinx StatCad
um meinen Zustandsautomaten zu erzeugen. Was der daraus in VHDL umsetzt
ist mir erstmal egal.

Um Info über die Zustände zu bekommen, habe ich mir ein Vector gebaut,
der in jedem Schritt umgeschossen wird und nach draußen geführt ist
(Pin)

Der Automat läuft ca. 10-15 mal korrekt durch und hängt sich dann auf.
Der Vektor wird dann 0, was eigentlich meine Ausgangszustand ist. Habe
jetzt aber noch ein zusätzliches Bit, das ich im Ausgangszustand setzt
und in allen andern Zuständen zurücksetzt, was aber im Fehlerfall nicht
gesetzt ist - sprich der Zustandsautomat hängt sich komplett auf und ist
in keinem Zustand mehr.

Die Weiterschaltbedingungnen sind asynchron. Aber das sollte doch nicht
das Problem sein, oder? Sollte ich diese nochmal über ein Flipflop
buffern?

Danke für Tips

Daniel

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist übrigens doch nicht immer der selbe State von dem aus die State
Machine hängt.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vlt. kannst Du ein Bild von StateCAD und/oder den generierten VHDL code
posten?

Wenn er 10-15x durchläuft kann es versch. Ursachen haben, angefangen
von Denkfehlern in der FSM bis hin zum TB, der ja auch nicht zwingend
fehlerfrei sein muss.

Bei meinen FSM habe ich (in VHDL) immer einen error state, der bei
unerwarteten Dingen angefahren wird und auch dort verbleibt.

Viele Grüße
Olaf

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<Die Weiterschaltbedingungnen sind asynchron. Aber das sollte doch
<nicht
<das Problem sein, oder? Sollte ich diese nochmal über ein Flipflop
<buffern?

Doch das kann das Problem sein. deine states werden in FF umgesetzt,
z.B bei einer one hot codierung von 12 states, 12 FF, bei denen immer
eins '1' die anderen Null. bei Verletzung des Timings kann es nun
vorkommen, das bei einem state-Übergang das aktive FF gelöscht wird,
aber bis zum Eintreffen des nächsten Taktes nicht das FF für den
nächsten state gesetzt wird. also alle FF auf '0' stehen -> illegal.

Also alle Eingangssignale die stateübergänge beieinflussen müssen aus
FF kommen, die mit dem selben takt wie die statemachiene laufen.

Eigentlich sollte auch der reset synchron sein, aber das ist seltener
ein problem.

(1) also alle eingangssignale über ff führen.
(2) experiementiere mal mit anderen states encodings, dein synthese
tool (XST?) hat einen schalter dafür (üblich sind one-hot; binary,
auto, gray; manchmal auch andere (Johnson, Nova). Das wird das prioblem
nicht lösen aber vielleicht einkreisen.
(3) Ich setzte den Debugvector meist ausserhalb der state machiene.
Also:

debugvector = "00001" when state_sig = STATE1 else
              "00010" when state_sig = STATE2 else
              .....
              "10000" when state_sig = STATE_LAST;

Abtakten vor Ausgabe nicht vergessen:

process(clk)
Begin
if rising_edge(clk) then
  if reset = '1' then
     debug_output_pins <= (others => '0');
  else
     debug_output_pins <= debugvector;
  end if;
end if;
end process;

Dann läuft der debugausgang zwar einen Takt nach, aber er belügt dich
nicht.

schau dir den vhdlcode an und schiele mal auf die ausgabe vom
synthesetool, da könnten noch hinweise stehen (state never reached oder
so).

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Küchle,
dahin gehend werde ich nochmal alles prüfen.

Ist es denn sinnvoll die Transition Bedingungen mit der negativen
Flanke des Statemachine Clocks zu takten, damit sie bei der nächsten
positiven gültig sind?

Werde jetzt nochmal alle Transitions, die nicht synchron sind über FF
buffern.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Küchle, ich danke Dir!

Es läuft jetzt! Ich glaube ohne Dich wäre ich noch 1 Monat zurück.
(Du hast mir schon einmal mit dem "Schlachtplan" geholfen)

Übrigens, das ganze ist meine Diplomarbeit - wenn Du aus dem Raum NRW
kommst bist Du herzlich zu meiner Diplom-Party eingeladen wenn ich denn
irgendwann mal fertig werde und mein Diplom bekomme ;-)


Danke!

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Och, schade, stecke gerade im Neunfünfland, da komm ich nicht so bald
nach NRW. Kanns aber in der FPGA-Küche einen Zettel mit dem Partytermin
dranpinnen:

  http://wikihost.org/wikis/fpgakueche

Ansonsten, nicht unterkriegen lassen, auch Diplomarbeiten mit FPGA's
kommen zu
einem glücklichen Ende (eigene Erfahrung).

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ FPGAküchele:

....Dein Wort in Gottes Namen.....respektive der DA mit FPGAs... ;-)

Habe immer noch ein kleines Problem mit etwaigen Bitfehlern....

...will morgen mal mit einem Logikanalyzer gegen checken....

Vielleicht wäre es doch ratsamer gewesen, bei einer Datenadaption
zwischen zwei Gegenstellen mittels eines FPGAs einen FIFO mit
einzubinden.

Schaun mer also mal...

Gruß nach Neufundland...was auch immer Du da gerade machst... ;-)
Tom

Autor: Thomas Hertwig (mac4ever)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn der Thread schon ein paar Tage alt ist ... auch mein Dank geht 
an FPGAkuechle.
Hatte gerade das gleiche Problem, was mich an mir zweifeln ließ ^^. 
Lösung: Eingangssignale über FF puffern

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.