mikrocontroller.net

Forum: FPGA, VHDL & Co. Kann ein Automat "abstürzen" ?


Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

In einem VHDL Design verwende ich einen Automaten. Da es Probleme gibt,
hab ich zum Debuggen Folgendes gemacht:

Jedem Zustand im Automat wird eine LED zugeordnet, die dann leuchtet
wenn er sich in dem jeweiligen Zustand befindet.

Manchmal kommt es aber nun vor, dass auf einmal gar keine LED mehr
leuchtet. (alle LEDS intakt, die Zuweisung zu den Zuständen klappt
auch)
So ein Automat muss doch eigentlich immer in einem definierten Zustand
sein, oder ? Das heißt eine LED müsste immer an sein.

Mittlerweile glaube ich auch an einen Hardwaredefekt im FPGA.
Ist das möglich?

THX

Autor: Detlef A (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, das ist unmöglich.

Cheers
Detlef

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Detlef:

Es müsste heissen: Nein,das ist extrem unwahrscheinlich.

Ich tippe mal auf eine Fehler im Automaten.Hast du dir einen
Zustandsgraphen gezeichnet?Interne Zustände,Folgezustände....etc

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das geht ja richtig schnell hier :)

Ich frage mich nur, was man beim Automaten falsch machen kann?

Im Prinzip sieht der bei mir so aus: (alles Unnötige weggelassen)

process (Takt)
begin
 if Takt = '1' and Takt'event then
  case zustand is
   when a =>
  blabla
  leds <= "001";
        if irgendwas then
   zustand <= b;
  end if;
   when b =>
  blabla
        leds <= "010";
        if irgendwas then
   zustand <= c;
  end if;
   when c =>
  blabla
        leds <= "100";
  if irgendwas then
   zustand <= a;
  end if;
  end case;
 end if;
end process;

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm....ein Automat wertet interne Zustände aus und wechselt aufgrund
externer Ereignisse in Abhängigkeit der internen Zustände in den
nächsten.Da ist es schon relevant,was du in dem Zustand machst.

Male dir einen Graphen auf,dann wird es allen klarer,was das Ziel ist.

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn die Zustandswechsel von externen asynchronen Signalen abhängen,
kann es bei Verletzung der Setup/Hold-Zeiten der Register schon zu
nicht vorgesehenen Zustandswechseln kommen. Ob du solche Signale
benutzt, lässt sich aber leider nicht aus dem Schnipsel erkennen, wenn
ja, sollte man die Signale vorher durch FFs einsynchronisieren.


T.M.

Autor: Raini (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bleibt dein Automat beim Anschalten aus oder mitten während des
Betriebs?
Du hast One-Hot kodiert. Dass heisst es gibt noch Zustände deines
Zustandsvectors, die in deinem Automaten nicht näher definiert sind.
Evtl. hiflt ein synchroner Reset.

G
Raini

Autor: breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein kleiner Tip:

Das "if irgendwas" kannst du mit in die Case Anweisung reinpacken -
dann hast du auf jeden Fall alle möglichen Zustände abgedeckt:

case bla is
  when a =>
  when b =>
  when c =>
  when others =>
end case;

Gruß,
Thomas

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde mal die LEDs einzeln kombinatorisch steuern, da siehst Du
nämlich die realen Zustände. So, wie Du es machst, siehst Du nur den
vorherigen Zustand!

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Hab das Problem gelöst, indem ich alle externen asynchronen Signale
synchronisiert hab.

Danke !

P.S: Eine Verringerung der Taktrate hätte das Problem auch behoben -
habs ausprobiert.

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>P.S: Eine Verringerung der Taktrate hätte das Problem auch behoben -
>habs ausprobiert.

Fragt sich nur wie lange.
Du musst von aussen kommende asynchrone Signale immer über Flip-Flops
einlesen, evtl. sogar über zwei oder noch mehr.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal

Angenommen ich synchronisiere die Signale, die von außen kommen, mit
dem Takt des Automaten.  Dann würde doch das Signal genau in dem Moment
übernommen, in dem der Automat seinen Zustand wechselt?

Führt das nicht eher zu Instabilität ?

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn dies passiert, gelangt das Signal NICHT an den Automaten, da das
Eingangs-FF nicht transparant ist, bzw der sich infolge des dort gerade
aktiven Taktes nach hinten durchsetzende Eingangszustand nicht schnell
genug an folgezellen fortpflanzen kann, um dort noch eine Flanke zu
sehen: er packt die dortige Setup-Zeit nicht!

Dies genau ist ja die Grundfunktion der gesamten synchronen Taktung!

Der Sinn der Einsynchronisierens ist damit genau der, einen solchen
Zustandswechsel kurz vor einer Flanke zu unterbinden. Ein statistisch
unsicheres Ausgangssignal hat man also nur nach dem ersten FF - der
zweite Ausgang kann nicht mehr zum Zeitpunkt der Taktflanke wackeln.

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.