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
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.
Bist Du sicher, dass nach der Synthese noch eine Statemachine vorhanden ist? Ist alles synchron?
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.
Codierfehler oder reset wird aktiv, mehr lässt sich ins blaue Hinein nicht sagen.
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
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".
@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
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
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
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
Es ist übrigens doch nicht immer der selbe State von dem aus die State Machine hängt.
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
<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).
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.
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!
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).
@ 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
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.