Queue in VHDL möglich?

[Daniel C. (danny1)]

Hallo liebe mikrocontroller - Community,

Ich hab gerade eine FSM gebaut und möchte bei dieser eine gewisse Anzahl 
von Vorzuständen speichern. Der Hintergedanke dabei wäre, um bei 
Auftreten eines Fehlers den Verlauf zu dem Fehler nachvollziehen zu 
können.

Mein Ansatz wäre bei jeder Transition den neuen Zustand in eine Art 
Queue abzulegen welche eine feste Länge hat.
Darum meine Frage: Kann man in VHDL eine Queue erstellen in der ich 
Signale vom Type Enum ablegen kann?

Meine FSM ist nach einer Mealy State Machine aufgebaut und hat folgende 
Zustände:

architecture behavior of StateMachine is

  type state_type is (idle, q1, q2, q3, q4, q5, error);

  signal currentState : state_type;
  
  signal auxiliarySignal : STD_ULOGIC;
  
  signal counter : integer;

begin

Bei der Suchfunktion bin ich leider nicht fündig geworden.

LG,
Daniel

[Duke Scarring (Gast)]

Daniel C. schrieb:
> Darum meine Frage: Kann man in VHDL eine Queue erstellen in der ich
> Signale vom Type Enum ablegen kann?
Ja, geht. Bau einen FIFO, der Deine Enums speichern kann.
Und überlege Dir noch eine FSM, die die FIFO-Ansteuerung (auslesen, 
rücksetzen) übernimmt.

Duke

[Weltbester FPGA-Pongo (Gast)]

Kann man machen, wäre aber mitunter besser, die FSM direkt zu 
beobachten, also auszugeben, was sie tut, z.B. über eine externe Leitung 
und Logic Analyzer. Ich würde jetzt den ChipScope empfehlen, aber der 
kann ja nur punktuell Daten einsammeln.

[J. S. (engineer)]

Wenn es eine Sicherheitsfunktion werden soll, sind interne RAM-Blöcke 
nicht geeignet, weil man unterstellen muss, dass eine andere FSM, mit 
der man diese Daten mal auslesen will, ebenfalls versagt.

Sowas geht nur über ein EEPROM oder einen externen Datenspeicher. Das 
einfachste ist es, man hat eine CPU auf dem board, die einen 
Fehlervektor ausliest und dann entscheidet, was sie im FPGA einsammeln 
muss.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Daniel C. schrieb:
> type state_type is (idle, q1, q2, q3, q4, q5, error);
Mal angenommen, diese Zustände würden in 3 Bit binär codiert, was wäre 
dann, wenn der 8. Zustand aufträte?
Oder, wenn die 7 Zustände gar OneHot umgesetzt würden, was wäre, wenn 
fehlerhafterweise einer der anderen 121 Zustände aufträte?

Ergo: theoretisch kannst du die Historie der Zustände speichern. Du 
darfst dich auf die gespeicherten Daten nicht absolut verlassen. Denn es 
kann sein, dass nicht an jeder Stelle im FPGA der selbe Fehler gleich 
"gesehen" wird.

Oder andersrum: warum erwartest du eine amoklaufende FSM?

Die allermeisten Probleme machen asynchrone externe Signale:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html

[Vancouver (Gast)]

Man muss nicht unbedingt von einer Fehlfunktion der FSM ausgehen. 
Manchmal will man einfach nur wissen, welche Transitionen die FSM 
durchlaufen hat, um in einem bestimmten Endzustand zu landen. Oder um zu 
sehen, wie oft die FSM im Zustand Sx gelandet ist. So eine Art Logbuch 
oder Statistik. Wenn das dauerhaft und im laufenden Betrieb gemacht 
werden soll, scheiden Chipscope etc aus (wer hat eigentlich gesagt, dass 
es hier um eine Xilinx_FPGA oder überhaupt um einen FPGA geht?), man hat 
später keine Entwicklungsumgebung mehr. Also ist eine FIFO das Mittel 
der Wahl.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Vancouver schrieb:
> Manchmal will man einfach nur wissen, welche Transitionen die FSM
> durchlaufen hat, um in einem bestimmten Endzustand zu landen.
Ich muss mich da ein wenig zwingen, dieses aus der Software durchaus 
bekannte passive (zuweilen hilflose) zeitliche "Zurückschauen" auf 
Hardware zu übertragen...  ;-)

Aber wie auch immer: ich würde im Automaten einen Merker einführen, der 
mir den letzten Zustand speichert. Und bei einer Abweichung zwischen 
aktuellem und letztem Zustand wird dann jeweils ein Eintrag in den Fifo 
in einem RAM gemacht. Dadurch verliert man natürlich zeitliche 
Zusammenhänge und arbeitet rein zustandsbezogen.
Man könnte dann natürlich auch noch einen Zeitstempel mit eintragen oder 
eine Zyklenzahl oder jeden einzelnen Takt einen Eintrag machen. Oder, 
oder, oder.

[Vancouver (Gast)]

"Ich muss mich da ein wenig zwingen, [...]"

Woraus resultiert Dein Unbehagen? Die Transitionsfolge einer FSM kann 
von externen Events bzw. deren logischen Verknüpfungen abhängen. Durch 
das Tracking der Zustandsfolge lässt sich auf einfache Weise 
rekonstruieren, in welcher Reihenfolge was passiert ist.

Den Merker hast Du schon implizit in der FSM. Das Zustandsregister hält 
den aktuellen Zustand (wer hätte das gedacht), und die Übergangsfunktion 
berechnet den Folgezustand. Stimmen sie nicht überein, so gibt es einen 
Zustandswechsel und ein write-event für die Fifo.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Vancouver schrieb:
> Das Zustandsregister hält den aktuellen Zustand (wer hätte das gedacht),
> und die Übergangsfunktion berechnet den Folgezustand. Stimmen sie nicht
> überein, so gibt es einen Zustandswechsel und ein write-event für die Fifo.
Das könnte aber vom Timing her spannend werden, wenn z.B. die Berechnung 
des Folgezustands schon an die Grenzen der Taktfrequenz kommt.
Und es klappt sowieso nicht bei der Ein-Prozess-Schreibweise. Denn dort 
müsste dann bei jeder Transistion explizit auch das Schreiben 
angestoßen werden.

> Woraus resultiert Dein Unbehagen?
Es ist kein Unbehagen, es ist eine andere Sichtweise, weil gefragt wird: 
wie  bin ich hierher gekommen? (Oder: wie hat das passieren können?)
Ich bin da eher vorwärts orientiert: wenn aussen Das oder Jenes 
passiert, dann wird dadurch Folgendes ausgelöst.