Kann ein Automat "abstürzen" ?

[Hans (Gast)]

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

[Detlef A (Gast)]

Nein, das ist unmöglich.

Cheers
Detlef

[Ronny (Gast)]

@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

[Hans (Gast)]

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;

[Ronny (Gast)]

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.

[T.M. (Gast)]

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.

[Raini (Gast)]

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

[breti (Gast)]

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

[Jürgen Schuhmacher (Gast)]

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!

[Hans (Gast)]

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.

[Xenu (Gast)]

>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.

[Hans (Gast)]

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 ?

[Jürgen Schuhmacher (Gast)]

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.