www.mikrocontroller.net

Forum: FPGA, VHDL & Co. state machine


Autor: Sebastian J. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wäre ein übergeordneter Prozess eine variante oder kann ich aus einem
anderem prozess den zustand erst recht nicht beeinflussen?

Autor: Ssss Ssssss (sssssss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würds so machen:
if reset = '1' then
  state = 0;
else if rising_edge(clk) then
  statemachine
end if;

Bzw je nachdem wie du reset definiert hast ;)
Also den reset asyncron und die statemachine dahinter synchron.

Bye, Simon

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Egal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einem synchronenn Reset?

if rising_edge(clk) then
   if reset='0' then

Autor: Andreas Pi (andreas_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ssss Ssssss (sssssss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ssss Ssssss (sssssss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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 ...

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh, das << and >> zwischen rising_edge und run vergessen ...

Autor: Ssss Ssssss (sssssss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andere Version von dir:
Du kannst ein Signal nicht aus zwei unterschiedlichen processes ändern
;)

Bye, Simon

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...stimmt :o(

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Asynchroner Reset verbraucht definitiv weniger Resourcen. Weil alle
FilpFlops nach einer LUT asynchron sind.

Sebastian

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Andreas Pi (andreas_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Egal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LUT = Look Up Table

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Chris V (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr schöner Artikel zum Thema Synchroner Reset und überhaupt über
"Designrules".

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp...

Wollt ich euch nicht vorenthalten,
Gruß Chris

Autor: smay4finger. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.