Hallo, kann mal bitte jemand ein Auge auf den angehängten Codeausschnitt werfen? Ich bin auf der Suche nach einer Möglichkeit, den Zustand der state machine ganz am Anfag auf Null zu setzen. Allerdings bin ich mir nicht sicher, ob es funktioniert, außerhalb der state machine deren Zustand zu beeinflussen bzw. hatte ich schon mal eine Varinate programmiert, die aber nicht funktioniert hat. Falls jemand nen Denkanstoß für mich hat oder auch nen konkreten Vorschlag, wäre ich sehr dankbar. Gruß Sebastian
wäre ein übergeordneter Prozess eine variante oder kann ich aus einem anderem prozess den zustand erst recht nicht beeinflussen?
ich würds so machen:
1 | if reset = '1' then |
2 | state = 0; |
3 | else if rising_edge(clk) then |
4 | statemachine
|
5 | end if; |
Bzw je nachdem wie du reset definiert hast ;) Also den reset asyncron und die statemachine dahinter synchron. Bye, Simon
@simon: ...ähm, nein, wenn reset_in='0' springt die state machine in irgend einen beliebigen zustand bzw. vermute ich, sie bleibt einfach in dem gerade erreichten stehen. ich denke, auch hier kommt genau das problem zum tragen, dass der zustand außerhalb der state machine beeinflusst wird, oder?
Wie wäre es mit einem synchronenn Reset? if rising_edge(clk) then if reset='0' then
Ich bin auch für einen synchronen Reset! Bei Xilinx FPGAs gibt es in den FF nur synchrones oder asynchrones Setzen und Laden. Wenn man asynchron resettet verbraucht man bei Zahlern und statemachines deutlich mehr Resourcen. Da ein Laden der Zähler jetzt mit logik erzeugt werden muß. Die Syntesesoftware kann die Zeiten von syncronen resets nur überprüfen alles andere ist reines Glücksspiel und man verbringt hinterher Stunden um das rauszufinden.
Hi! Echt, nimmt man synchrone resets ? Ich hab bis jetzt überall immer nur die asynchrone version gesehen... Wobei ich reset auch wirklich nur als power on reset und reset per button benutze ... Aber das mit Xilinx hört sich interessant an, muss ich mal testen obs mit synchronem reset kleiner wird :) >ich denke, auch hier kommt genau das >problem zum tragen, dass der zustand außerhalb der state machine >beeinflusst wird, oder? Wie meinst du das ? Du musst bei reset_in=0 oder =1 je nachdem ob active low/high halt den zustand initialisieren. Dann startet sie auch immer da wo du willst. Bye, Simon
@simon: ich dachte halt, dass die initialisierung nicht greift, da es bisher nicht funktioniert hat, egal welche variante ich verwendet habe. werd jetzt mal den synchronen reset testen und dann mal schauen, wie es aussieht. ich werde bericht erstatten ... so far
if rising_edge(clock) then
if reset_in='0' then
state_ADC <= 0;
systemzeit <=0;
else
case state_ADC is
--Anfangszustand
when 0 => Zustand <= "0000";
convst <= '0';
rd <= '0';
cs <= '0';
switch <= '0';
state_ADC <= 1;
...
... so sieht es jetzt aus. allerdings bleibt die stm. immer noch
einfach nur in ihrem gerade erreichten zustand stehen.
ah jetzt versteh ich was du meinst!
du willst dass beim drücken von reset an den io pins bzw wo auch immer
dasselbe anliegt wie beim init ?
Probier mal:
if reset_in='0' then
state_ADC <= 0;
systemzeit <=0;
Zustand <= "0000";
convst <= '0';
rd <= '0';
cs <= '0';
switch <= '0';
else
denn deine statemachine läuft ja erst wieder los wenn der reset weg ist
;)
so wolltest du das doch, oder ?
Bye, Simon
...ja, für die state machine wollte ich das so. ich denke, dass wird auch funktionieren. ich hatte es schon mal in dieser art und weise, aber da hat auch irgend etwas nicht hin gehauen bzw. war es halt asynchron ... process (reset_in) is if reset_in='0' then run <= 1; else run <= 0; state_ADC<=0; systemzeit<=0; end if; end process ... und dann z.b. im nächsten process: if rising_edge(clock) run='1' then case state ... etc. mal schauen, ich werd noch einmal bißchen in mich gehen ...
Andere Version von dir: Du kannst ein Signal nicht aus zwei unterschiedlichen processes ändern ;) Bye, Simon
Asynchroner Reset verbraucht definitiv weniger Resourcen. Weil alle FilpFlops nach einer LUT asynchron sind. Sebastian
@sebastian: tja, ich denke, es haben beide ihre berechtigung. woran macht man fest, ob der eine oder der andere besser ist? hat man noch resourcen, kann man sie nutzen. wird es eng, muss man optimieren, klar. aber was ist besser? asynchron oder synchron zu reseten?
kleines Beispiel ein 32 bit Zahler mit load und clear benötigt mit asynchronen Reset Number of Slices 32 out of 768 4% und mit synchron reset Number of Slices 18 out of 768 2% also fast die hälfte weniger an Resorcen. Es gibt keinen Grund Asyncrone Resets zu verwenden. Man handelt sich nur probleme mit der setup time nach dem Reset und zum setzen des FF durch den CLK und D ein. Man sitzt wirklich Stunden davor um solche fehler zu finden warum das FPGA mal geht und mal nicht. Und es läuft auch noch besser oder schlechter je nach Synthese durchlauf. in Buchern und VHDL Anleitungen findt man oft solche asynchronen Beispiele. Sebastian > Asynchroner Reset verbraucht definitiv weniger Resourcen. Weil alle > FilpFlops nach einer LUT asynchron sind. das verstehe ich nicht (eine LUT?). Andreas
Ich arbeite nun mit einem synchronen Reset und stelle fest, dass gewisse Unregelmäßigkeiten nicht mehr auftreten ... hat also aif jeden Fall etwas für sich´. Einen Vergleich der benötigten Resourcen habe ich ncoh nicht gemacht ...
Ich gebe zu ich programmiere (Hobbyniveau) meinen Spartan 3 auch immer nur mit synchronen Resets. Kommt mir vom Gefühl her stabiler vor. So jetzt habe ich mal im DS099.pdf recherchiert. Ziemlich interessant: The storage element, which is programmable as either a D-type flip-flop or a level-sensitive latch, provides a means for synchronizing data to a clock signal, among other uses. The storage elements in the upper and lower portions of the slice are called FFY and FFX, respectively. Seite 10/11. Wenn SR Synchroner Reset bedeutet. Dann stimmt meine obige Aussage nicht. Und die Bestimmung der Anzahl von Slices von Andreas Pi macht vollkommen Sinn.
DS099.pdf ist eine Spartan3 spezifische Doku? Kann ich leider nichts mit anfangen. Aber OK, es zeichnet sich doch zweifelsohne ab, dass der sysnchrone Reset von Vorteil ist, was auch rein logisch gedacht Sinn hat :o)
Sehr schöner Artikel zum Thema Synchroner Reset und überhaupt über "Designrules". http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=kc_priorities Wollt ich euch nicht vorenthalten, Gruß Chris
Ich frage mich, warum der OP die State-Machine in einen einzigen Prozess
packt. Sieht für mich nach Software-Entwickler aus, der seinen Quellcode
in Hardware umsetzen will. :-)
Ich würde das so machen:
type STATE_TYPE is (Start, State1, State2);
signal STATE, STATE_NEXT: STATE_TYPE;
begin
-- state register
process(CLK, RESET) is
begin
if CLK = '1' and CLK'event then
if RESET = '1' then
STATE <= Start;
else
STATE <= STATE_NEXT;
end if;
end if;
end process;
-- state next decoder
process(STATE, inputs...) is
begin
STATE_NEXT <= STATE;
case STATE is
when Start =>
if input = '1' then
STATE_NEXT <= State1;
end if;
when State1 =>
.....
end case;
end process;
-- state output decoder
process(STATE, inputs...) is
begin
case STATE is
...
end case;
end process;
Man kann den State Output Decoder und den State Next Decoder auch in
einem Prozess zusammenfassen. In der Literatur findet man diesen
Baustein als Two Process State Machine und als Three Process State
Machine.
mfg, Stefan.
Oder Multi-Process FSM - finde ich auch sehr schön übersichtlich: in einem Prozess nur der Zustandspeicher, in einem anderen nur die Eingabelogik und im anderen nur die Ausgabelogik.
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.