Ich habe eine statemachine
Irgendwie springt diese nach "debug" in "startup" dann aber wieder in
"debug".
Kann mir jemand erklären, warum dies so ist / wo mein Fehler liegt?
Ich habe ein MachXO2 Board von lattice.
eingefügt.
Hiermit läuft es.
Was mache ich bei dem Aufzählungstyp falsch? Es scheint mir ein wenig,
als wenn dieser nur mit einem Bit erstellt werden würde...
Wenn ich im Startup starte geht er in das rnning (mit Aufzählungstyp)
aber nicht wenn ich mit debugstate starte.
S. R. schrieb:> hast keinen neuen Zustand vorgegeben, wenn die jeweiligen Bedingungen> erfüllt sind
Das ist ja auch nicht nötig weil der state sowieso schon so ist, also
durch deine Anweisung nicht verändert wird. Und er fängt sich durch die
fehlende Anweisung auch kein FlipFlop Register ein weil state sowieso
ein Register sein soll.
statemachine schrieb:> Irgendwie springt diese nach "debug" in "startup" dann aber wieder in> "debug".
Es gibt gar keinen Zustand "debug"...
S. R. schrieb:> Schreib das mal dazu: when debugstate =>
Der Synthesizer meint lakonisch:
1
------------------------
2
State|Encoding
3
------------------------
4
debugstate|unreached
5
startup|0
6
running|1
7
------------------------
Und auch der Simulator sieht das so. Denn mit dem Code oben passiert
genau das, was zu erwarten ist: anfangs "startup", nach 1 Sekunde
"running". Das Problem liegt also nicht im geposteten Code. Mach doch
mal einen "Dreizeiler", der in 1 Datei genau das beanstandete Verhalten
zeigt.
EDIT:
> Wenn ich im Startup starte geht er in das rnning (mit Aufzählungstyp)> aber nicht wenn ich mit debugstate starte.
Doch, das geht auch (zweites Bild)...
Und dann macht auch der Synthesizer einen State daraus:
Bei mir ja gerade irgendwie nicht ....
Was ich soebend heraus gefunden habe: Wenn ich den Reset weg lassen,
dann geht das alles...
Der vollständigkeit halber einfach mal das gesamte Programm.
An debug sind die LEDs des Boards, welche auf '0' Leuchten.
Am Reset ist eine Leitung direkt auf GND. Wenn ich diese auf High setze
bleiben die LED's wie gewünscht im Zustand, welchen Sie haben.
So wie das Programm hier jetzt steht leuchten nacheinander eine LED und
dann zwei, bevor sich das ganze wiederholt und nur eine leuchtet.
Ich nutze das Lattice Diamond (64-bit) 3.8.0.115.3
Ich werde mich heute Abend mal mit dem Simulator dieses Programms
auseinander setzen und wie ich eine Testbench zu erstellen habe.
Warum verursacht dieses (eigentlich nicht betretene) Reset dieses
Verhalten aus?
statemachine schrieb:> Irgendwie springt diese nach "debug" in "startup" dann aber wieder in> "debug".
Wohl nicht.
Er SOLL zwar in debugstate starten, aber er startet in:
signal state: state_t := startup;
Also wird debugstate nie erreicht, er wechselt nur von startup in
running, das sind die 2 Zustände, nicht debugstate und startup.
MaWin schrieb:> Wohl nicht.> Er SOLL zwar in debugstate starten, aber er startet in:
Du meinst wohl dieses hier:
1
signalstate:state_t:=startup;
Hier muss ich mich entschuldigen, da ich nebenbei auch weiter versuche
war hier schon wieder etwas anderes eingetragen.
Wenn ich also
1
signalstate:state_t:=debugstate;
schreibe geht er vom debugstate in den startup und wieder zurück.
Wenn ich
1
signalstate:state_t:=startup;
schreibe geht er vom Startup in den running und bleibt da.
Ich habe hier:
Beitrag "Re: Statemachine springt in falsche "states" warum?" noch
mal mein gesamtes Programm angehängt (so wie es aktuell bei mir
ausschaut).
Noch einmal sorry, daher dass ich nebenbei selber weiter versuche habe
ich hier aus versehen einmal "startup" geschrieben als ich "debugstate"
meinte und ganz am Anfang geht soll er natürlich nicht in "debug" gehen
(gibt es ja nicht) sondern in "debugstate".
Debugstate hieß in einer älteren Version noch "debug" bis ich die Pins
"debug" hin zu gefügt habe und es in "debugstate" umbenannt habe.
statemachine schrieb:> Wenn ich ( reset = '1' ) durch rising_edge(reset) ersetze bringt das> keine besserung.
Sowas gibts auch gar nicht:
ein Flipflop, dessen Reset-Eingang flankensensitiv wäre.
statemachine schrieb:> noch mal mein gesamtes Programm angehängt
Sicher?
> component osch
Was ist osch?
statemachine schrieb:> Wenn ich den Reset weg lassen, dann geht das alles...
Was tut denn der Reset?
Wie seith deine Testbench aus?
Lothar M. schrieb:>> noch mal mein gesamtes Programm angehängt> Sicher?
Jupp, ich habe "nur" eine einzelne VHDL Datei erstellt und das hier
gezeigte ist alles, was darin steht. (Bild)
Lothar M. schrieb:>> component osch> Was ist osch?
Diesen Teil habe ich kopiert.
Diese Componente scheint von Lattice vorgegeben zu sein und den internen
RC Oszillator zu steuern. (In diesem Fall 17.73MHz).
.pdf Seite 29 unten
1
COMPONENTOSCH
2
-- synthesis translate_off
3
GENERIC(NOM_FREQ:string:="2.56");
4
-- synthesis translate_on
5
PORT(STDBY:INstd_logic;
6
OSC:OUTstd_logic;
7
SEDSTDBY:OUTstd_logic);
und .pdf Seite 30 oben
1
OSCInst0:OSCH
2
-- synthesis translate_off
3
GENERICMAP(NOM_FREQ=>"2.56")
4
-- synthesis translate_on
5
PORTMAP(STDBY=>stdby,
6
OSC=>osc_int,
7
SEDSTDBY=>stdby_sed
8
);
Die genaue Quelle kann ich nicht mehr nennen, ich habe mir leider
einfach nur kopiert gehabt um erstmal irgendwas zum laufen zu bekommen.
(Vor Jahren mal kopiert, vor einer Woche wieder rausgekramt).
Lothar M. schrieb:> Was tut denn der Reset?
Aktuell soll der Reset nichts machen. Er soll später den "Grundzustand"
herstellen.
Lothar M. schrieb:> Wie seith deine Testbench aus?
Aktuell schaut meine Testbench so aus (Foto).
Simulation habe ich bisher noch nicht gemacht, verspreche ich aber mich
ein zu arbeiten. Nur nicht mehr heute da zu viel um die Ohren.
statemachine schrieb:> Lothar M. schrieb:>> Was tut denn der Reset?> Aktuell soll der Reset nichts machen. Er soll später den "Grundzustand"> herstellen.
Dann ist er unnötig, denn ein FPGA hat nach dem Einschalten und Laden
der Konfiguration schon einen immer gleichen Grundzustand.
>> Wie seith deine Testbench aus?> Aktuell schaut meine Testbench so aus (Foto).
Der Simulator ist der Debugger für FPGA Designs. Mal sehen, ob ich
morgen in der Pause mal 5 Minuten finde...
Bist du sicher, dass der Oszillator sauber läuft? Wird evtl. das FPGA
laufend neu geladen?
Noch ein Wort zum hier unnötigen "when others":
http://www.lothar-miller.de/s9y/archives/30-when-others.html
Lothar M. schrieb:> Dann ist er unnötig, denn ein FPGA hat nach dem Einschalten und Laden> der Konfiguration schon einen immer gleichen Grundzustand.
Ich wollte die möglichkeit haben, diesen später auch "während des
laufens" zurück setzen zu können
Ich habe mich gerade mal mit dem Simulator auseinander gesetzt ohne
Eingangssignale, da das Reset in diesem Fall wieso immer auf "Low" ist.
In allen Fällen zeigt die Simulation das gewünschte verhalten (Ich habe
die Zählkonstante verringert damit die Simulation schneller geht).
Ich habe auch das Programm, welches ich Simuliert habe noch mal 1:1 auf
den FGPA gespielt und es zeigt genau das gleiche verhalten.
Wenn ich die Bedingung für den "Reset" unmöglich mache läuft das
Programm normal. (Ich denke mal dann wird dieser Teil einfach
wegoptimiert.
Zudem habe ich versucht das eintreten des Reset zu ermöglichen, aber
unwarscheinlicher zu machen (abhängig von mehreren Pins in AND), was
aber auch nichts besser macht.
Ist mein FPGA kaputt?
Gib doch mal den Takt an einem Pin aus und überprüfe, ob der stabil ist.
Wenn du nichts hast, um diesen zu messen, lass wahlweise eine LED
blinken.
Wenn du dann sicher bist, dass das OSCH-Modul macht was es soll, geht es
weiter :)
Gruß
derLars
Warum hat eigentlich noch keiner gefragt wo das Reset herkommt?
Für mich hört sich das so an als wenn dein Design durch Störungen am
Resetpin dieses "merkwürdige" Verhalten zeigt.
Gruß
Stefan
statemachine schrieb:> Wenn ich die Bedingung für den "Reset" unmöglich mache läuft das> Programm normal. (Ich denke mal dann wird dieser Teil einfach> wegoptimiert.
So ist es.
> Zudem habe ich versucht das eintreten des Reset zu ermöglichen, aber> unwarscheinlicher zu machen (abhängig von mehreren Pins in AND), was> aber auch nichts besser macht.
Was tut da ein AND? Kommt der Reset aus irgendwelcher Kombinatorik (z.B.
Vergleicher oder sonst was)? Oder ist das ein FPGA-Pin der an einen
Taster angeschlossen ist?
statemachine schrieb:> Ich wollte die möglichkeit haben, diesen später auch "während des> laufens" zurück setzen zu können
Im Ernst: das deutet auf einen Designfehler hin...
statemachine schrieb:> Wenn ich die Bedingung für den "Reset" unmöglich mache läuft das> Programm normal. (Ich denke mal dann wird dieser Teil einfach> wegoptimiert.>> Zudem habe ich versucht das eintreten des Reset zu ermöglichen, aber> unwarscheinlicher zu machen (abhängig von mehreren Pins in AND), was> aber auch nichts besser macht.
Wenn dein Reset asynchron zum Clock zurückgenommen wird kann es Dir
passieren das deine FF bereits den Reset hinter sich haben, das ein-
oder andere diesen aber noch sieht...
Falls Du also tatsächlich einen externen Reset nutzen willst, solltest
Du:
1) Sicherstellen das keine (kurzen) Störungen einen Reset (ggfs. auch
nur auf einzelne FFs) auslösen können. In (d)einem fliegenden Aufbau
könnte auch gffs. eine Pulsformung (Reset nur wenn er min. 2 Takte lang
ansteht) und eine Synchronisation auf deinen Clock sinnvoll sein...
Ansonsten kannst Du Dir die Fehler einholen wie mit jedem asynchronen
Signal in einer FSM !
Gruß
DivisionByZero
DivisionByZero schrieb:> Ansonsten kannst Du Dir die Fehler einholen wie mit jedem asynchronen> Signal in einer FSM !
Siehe
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
Dort im Besonderen die letzten paar Zeilen.
Ganz übel ist ein kombinatorischer Reset, der z.B. aus einer logischen
Verknüpfung oder einen Vergleich zurück gesetzt wird. Stichwort dazu:
"Glitch". Ein solcher Glitch kann dann je nach Dauer mehr oder weniger
Flipflops in den Reset versetzen. Und so beliebiges Fehlverhalten
hervorrufen...
derLars schrieb:> Gib doch mal den Takt an einem Pin aus und überprüfe, ob der stabil ist.
Ich habe den Takt ausgegeben per
1
clkout:outstd_logic;
2
.
3
.
4
.
5
clkout<=clk;
0.1us/DIV bei 1V/DIV, mehr macht mein Oszilloskop nicht mit.
Wenn ich 9Perioden über 5DIV zähle komme ich auf 18MHz, was nahe genug
an 17.73MHz wäre und stabil ist das Bild auch.
Stefan schrieb:> Warum hat eigentlich noch keiner gefragt wo das Reset herkommt?
Der Reset kommt von extern
1
reset:instd_logic:='0';
und ist über ein kurzes Kabel fest auf Masse gelegt.
Ich habe auf diese Frage hin den Reset mal als Konstante erstellt
1
--reset: in std_logic := '0';
2
constantreset:std_logic:=0;
und aus der Sensivitätsliste entfernt.
Wenn Reset nun diese "constant" ist .. läuft das Programm. Daher, dass
ich den Reset auch aus der Sensivitätsliste entfernt hatte habe ich das
gleiche noch mal mit dem input Pin versucht und hier lief es wieder
nicht.
Ich denke aber, dass hier wieder wegoptimiert worden sein könnte.
Als nächstes habe ich den Reset so gemacht, dass hier alle Debug LEDs
eingeschaltet werden sollten, was aber auch nicht passiert (also Reset
wird nicht betreten)
DivisionByZero schrieb:> Wenn dein Reset asynchron zum Clock zurückgenommen wird
Auch wenn in dem "Reset" bisher noch nichts passiert habe ich dieses mal
in die
1
ifrising_edge(clk)then
reingenommen.
Um das hier alles nicht zuu lang zu machen, habe ich diesesmal das .vhd
File angehängt.
Lothar M. schrieb:> Ganz übel ist ein kombinatorischer Reset
Okay, ich habe den aus unwissenheit "kombinatorisch" gemacht, um zu
verhindern, dass er auf einem Fehler auf einem der Pins (wodurch dieser
ggf. High erkannt werden könnte) auslöst.
Ich weiß nicht wie interessant das hier gerade ist ... aber aktuell
passiert in meinem "Reset" absolut überhauptnichts. Es testweise nichts
auf irgendeiner Weise zurück gesetzt.
Ich habe jetzt testweise gemacht, dass im Reset "alles so bleibt" aber
dies bringt auch keine Besserung.
Das einzige, was hier (für mich unverständlicherweise) eine Änderung
bringt ist das Umsortieren der Zusände im type state_t.
Und: irgendwie läuft es richtig in der Simulation aber nicht auf der
Hardware.
Ich habe falls es hilf noch mal das "Overview Datenblatt" zum Board,
welches ich nutze hochgeladen. Meines hat den 1200ZE drauf.
Vielen Dank für die ganze Hilfe, ich hoffe ich nerve nicht zu viel. Ich
versuche wirklich all euren Hinweisen zu folgen.
derLars schrieb:> Wenn du dann sicher bist, dass das OSCH-Modul macht was es soll, geht es> weiter :)
Das OSC(H)-Modul ist ein "nobrainer". Per Generic die gewünschte
Frequenz einstellen (Möglichkeiten siehe Datenblatt), STDBY auf '0'
setzen und an OSC hat man seinen Systemtakt.
Der wird im MachXO2 intern erzeugt und ist nicht so super stabil und
genau wie ein Quarz, aber für ein Blinky und eine langsame UART reicht
es.
Was ich sagen will: Am OSCH liegt es sicher nicht.
Duke
statemachine schrieb:> aus der Sensivitätsliste entfernt
Das juckt den Synthesizer natürlich überhaupt nichts. Die Sensitivliste
ist nur und ausschließlich für die Simulation interessant....
Eine unvollständige Sensitivliste sorgt nur dafür, dass die Simulation
falsch ist und nicht zur erzeugten Hardware passt.
statemachine schrieb:> Der Reset kommt von externreset: in std_logic := '0'; und ist über ein> kurzes Kabel fest auf Masse gelegt.>> Ich habe auf diese Frage hin den Reset mal als Konstante> erstellt--reset: in std_logic := '0';> constant reset : std_logic := 0;> und aus der Sensivitätsliste entfernt.>> Wenn Reset nun diese "constant" ist .. läuft das Programm. Daher, dass> ich den Reset auch aus der Sensivitätsliste entfernt hatte habe ich das> gleiche noch mal mit dem input Pin versucht und hier lief es wieder> nicht.
Wie Lothar schon schrieb, die Sensitivliste wird von der Synthese
schlicht ignoriert.
Wenn aber das Ändern eines NICHT aktivierten Externen Resets in einen
nicht aktiven intern Reset eine Änderung deines Designs bringt, dann
würde ich als Fehlerquelle die Hardware/Verdrahtung in den Fokus
setzen...
Was versteht Du unter kurzem Draht? Ich kann da Elektrotechniker bei
denen ist alles unter 2m kurz...
Ist die Masse welche auf den Eingang setzt (im Bezug auf den FPGA)
tatsächlich eine?
Mutmaßlich koppelst Du dir auf dem Pin eine Störung ein.
Lass dein externes Reset Signal mal durch 3 FFs (Schieberegister) laufen
und nur wenn das Letzte und vorletzte FF (in der Kette) den von Dir
gewünschten (Reset-) Pegel "sehen" dann lasse dies dein interner Reset
sein...
dann solltest Du Dir erst einmal sicher sein können, dass Du Dir über
den Pin (deines Versuchaufbaus) keine Fehler einfängst...
DivisionByZero schrieb:> Was versteht Du unter kurzem Draht?
Ein Draht ist in diesem Falle ein 5cm langes Kabel, welches vom GND auf
dem FPGA Board an den entsprechenden Pin geht.
Die "state" Wechsel kommen regelmäßig in den "richtigen" Zeitabständen,
nur dass er anstelle nach "running" wieder zurück nach "debugstate"
springt.
DivisionByZero schrieb:> Lass dein externes Reset Signal mal durch 3 FFs (Schieberegister) laufen> und nur wenn das Letzte und vorletzte FF (in der Kette) den von Dir> gewünschten (Reset-) Pegel "sehen" dann lasse dies dein interner Reset> sein...>> dann solltest Du Dir erst einmal sicher sein können, dass Du Dir über> den Pin (deines Versuchaufbaus) keine Fehler einfängst...
Werde ich nach Weihnachten mal machen, da ich aktuell keinen Zugriff auf
die Hardware habe.
Etwas ähnliches habe ich vorher ausprobieren wollen durch die
AND-Verknüpung mehrer Eingänge.
*Eigentlich sollte doch *auch wenn ein "Reset"* kommt nichts passieren,
da hier nichts geändert wird. Ich könnte den Namen ja noch einmal
umändern ;).
statemachine schrieb:> *Eigentlich sollte doch *auch wenn ein "Reset"* kommt nichts passieren,> da hier nichts geändert wird. Ich könnte den Namen ja noch einmal> umändern ;).
Du must Dir vor Augen halten das im FPGA zwischen jedem Flipflop und
jedem Logikelement (jede Verknüpfung wird in Lookup Tables mit maximal
sechs Eingangssignalen heruntergebrochen) Laufzeiten durch Verbindungen
und Switchmatrixen sind.
Das ist mit einer (idealen) Simulation nicht zu vergleichen, wenn Du nun
also der pegel eines externen Signal kurz vor knapp (steigende Flanke
deines Taktes) ändert dann kann es eben sein, dass ein FF dies
mitbekommt ein weiteres in der Nähe liegendes dies nicht mehr sieht
(korrekt - siehe auch Setup/Hold Problematiken) ...
Die Effekte welche sich daraus ergeben haben nun schon Generationen von
Ingenieuren die Langeweile verkuerzt ...
Du kannst ja aus Spass einmal die vom Diamond synthetisierte Schaltung
posten (ggfs. das EDIF dass das embedded Synplify generiert), dann
können wir den heissen Pfad mal genauer untersuchen...
Gruß
DivisionByZero
DivisionByZero schrieb:> Du kannst ja aus Spass einmal die vom Diamond synthetisierte Schaltung> posten (ggfs. das EDIF dass das embedded Synplify generiert), dann> können wir den heissen Pfad mal genauer untersuchen...
Ich habe im Lattice Diamond unter [Tools] den "Symplify Pro for Lattice"
ausgeführt. Hier habe ich dann auf "Run" geklickt und unter anderen die
Meldung erhalten, dass die impl1.edi erstellt wurde, welche ich hier
angehängt habe.