www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Signal-Initialisierung funktioniert nicht


Autor: DJ Tobsen (dosmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich (VHDL-Anfänger) hab zu Übungszwecken mal versucht, eine 
Statusmaschine nur mit nebenläufigen Befehlen zu schreiben:

----->8-----------------------------------------

architecture Architektur_main of main is

type statusmaschine_t   is ( STATUS_0, STATUS_1, STATUS_2);
signal sig_Status_x:    statusmaschine_t := STATUS_1;

begin

  -- Statusmaschine
  sig_Status_x  <=  STATUS_1 when ( (sig_Status_x = STATUS_0) and
                                    (in_button0_b = '0')          ) else
                    STATUS_2 when ( (sig_Status_x = STATUS_1) and
                                    (in_button1_b = '0')          ) else
                    STATUS_0 when ( (sig_Status_x = STATUS_2) and
                                    (in_button2_b = '0')          );

  -- Status in der 7-Segmentanzeige anzeigen
  with sig_Status_x select
      out_bcd0_bv8     <=  func_LED7SEG_bv8("0000") when STATUS_0,
                           func_LED7SEG_bv8("0001") when STATUS_1,
                           func_LED7SEG_bv8("0010") when STATUS_2,
                           func_LED7SEG_bv8("1111") when others;

end Architektur_main;

----->8-----------------------------------------


Ich habe den Code mit Xilinx ISE9.2i synthetisiert und lasse ihn auf 
einem XC9500-CPLD laufen. Über eine 7-Segment-Anzeige wird mir der 
Status angezeigt.

Das Problem ist, daß das Signal "sig_Status_x" nicht den Initialzustand 
("STATUS_1") annimmt, den ich bei der Signal-Deklaration angegeben habe.
Tatsächlich nimmt "sig_Status_x" einen Zustand an, der außerhalb des 
Wertebereiches des Typs "statusmaschine_t" liegt (die 7-Segmentanzeige 
zeigt "F" an, also greift der "when others"-Zweig des Selects).
Wenn ich davon ausgehe, daß "sig_Status_x" als 2-Bit-Variable bzw. 
-Latch angelegt wird, scheint diese mit "11" initialisiert zu werden.

Könnt Ihr mir sagen, warum das nicht funktioniert?

PS: Sorry für fehlende Formatierung

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian F. schrieb:
> Wenn ich davon ausgehe, daß "sig_Status_x" als 2-Bit-Variable bzw.
> -Latch angelegt wird

Davon würde ich nicht ausgehen. Schau dir mal die Synthese-Einstellungen 
an. Dort könnte z.B. One-Hot-Coding gewählt sein. Also hast du schon mal 
3 Bit und folglich 8 Zustände von denen nur 3 auskodiert sind.
Aus welchem Grund versuchst du eine FSM so aufzubauen? Wäre ein Prozess 
nicht sinnvoller? Nebenläufige Befehle erzeugen für gewöhnlich keine 
Register oder Latches ... ein Prozess schon. Dann sollte es auch mit der 
Initialisierung klappen.
Schau dir mal das Resultat der Synthese im RTL-Viewer an, vielleicht 
stellst du ja fest, dass überhaupt keine Latches erzeugt werden?!

Autor: DJ Tobsen (dosmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Statusmaschine funktioniert, wenn ich sie erstmal in einen erlaubten 
Zustand gebracht hab (durch Einfügen eines Reset-Signals). Nur das 
Initialisieren funktioniert nicht.

Inzwischen vermute ich, daß das wieder so eine 
Simulation-versus-Synthese-Geschichte ist. Gilt die 
Signal-Initialisierung vielleicht nur für den Simulator?
Ich meine, wenn ich so recht darüber nachdenke, hat es sicher einen 
Grund, daß alle Bausteine einen Reset-Eingang haben...

> Aus welchem Grund versuchst du eine FSM so aufzubauen?
Nur zu Übungszwecken, hat keinen tieferen Sinn.

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian F. schrieb:
> Nur das
> Initialisieren funktioniert nicht.

Du kannst auch nur speichernde Elemente (also z.B. FFs) initialisieren. 
Bei ASICs, die sich selber aus dem Sumpf ziehen muessen, brauchst du 
einen Reset auf '0' oder '1'. Beim FPGA wird beim konfigurieren jedes FF 
auf den gewuenschten Wert initialisiert, wenn du da nix angibst 
ueblicherweise auf '0'.

Was deine Simulation bzw. dein Synthesetool bei einem Latch macht, tja, 
das duerfte hochgradig herstellerabhaengig sein...

Autor: DJ Tobsen (dosmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist interessant:
Wenn ich den Code auf einem FPGA laufen lassen, dann funktoniert die 
Initialisierung. Auf dem CPLD hingegen nicht.

berndl (Gast) schrieb:
>Beim FPGA wird beim konfigurieren jedes FF
>auf den gewuenschten Wert initialisiert, wenn du da nix angibst
>ueblicherweise auf '0'.
D.h. im FPGA hat ein FF zu Beginn einen definierten Zustand.
Beim CPLD hingegen wird der Zustand des FF wohl eher zufällig bzw. von 
der Hardware abhängig sein, daher braucht man da dann auch einen Reset, 
richtig?

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian F. schrieb:
> D.h. im FPGA hat ein FF zu Beginn einen definierten Zustand.
> Beim CPLD hingegen wird der Zustand des FF wohl eher zufällig bzw. von
> der Hardware abhängig sein, daher braucht man da dann auch einen Reset,
> richtig?

Nein.
Auch das CPLD wacht in einem bestimmten Zustand auf.
Schau Dir einmal den Fitter Report an, dort sind die Gleichungen 
aufgelisten, sowie für jedes FF auch der Anfangswert.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorneweg: da ist gar kein FF beschrieben, sondern ein Latch.
Das ist für die weitere Verhaltensanalyse wichtig:
> D.h. im FPGA hat ein FF zu Beginn einen definierten Zustand.
Die FFs im FPGA können in die Betriebsart "Latch" umgeschaltet und 
deshalb mit einem definierten Wert geladen werden.
> Beim CPLD hingegen wird der Zustand des FF wohl eher zufällig
In einem CPLD gibt es aber kein Latch. Solche Konstrukte werden da aus 
Logik zusammengebaut (die getakteten FFs liegen brach). Und Logik lässt 
sich nicht initialisieren...

mac4ever schrieb:
> Nebenläufige Befehle erzeugen für gewöhnlich keine
> Register oder Latches ... ein Prozess schon.
Hmmmmm...:
   latched    <= input when speichern='1';
   registered <= input when rising_edge(speichern);

Autor: Stefan R. (stefripp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich mir den Code anschaue fällt mir als erstes folgendes auf: Kein 
Takt! Und eine State-Machine ohne Takt gibt es nicht!

Und Praktisch: Schau mal die Einstellungen zur State Machine in ISE 
genau durch. Da gibt es Optionen wie "Save State Machine". Da würde ich 
den Fehler suchen (Nachdem ich einen Takt in das Design implementiert 
hätte)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan R. schrieb:
> Und eine State-Machine ohne Takt gibt es nicht!
Da solltest du aber nochmal die Grundlagen ansehen...  :-o
Eine Zustandsmaschine hat prinzipiell keinen Takt. Nur ist eine 
Umsetzung mit Takt durch die auf den Bausteinen vorhandenen 
Speicherelemente einfacher zu realisieren. Denn prinzipiell funktioniert 
die oben beschriebene FSM ja, nur die Initialisierung geht bei CPLDs 
schief.

> Da würde ich den Fehler suchen
Unnötig, der Fehler wurde bereits geklärt.

Autor: Stefan R. (stefripp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin zwar kein Theoretiker, aber Automaten arbeiten Zeitdiskret. Für 
mich als Praktiker heisst das: Zustände ändern sich bei 
steigende/fallende Flanken!

Autor: DJ Tobsen (dosmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> In einem CPLD gibt es aber kein Latch. Solche Konstrukte werden da aus
> Logik zusammengebaut (die getakteten FFs liegen brach). Und Logik lässt
> sich nicht initialisieren...

Das müßte ja das Synthese-Tool erkennen können. Sollte es dann nicht 
einen Fehler oder eine Warnung geben, daß sich die gewünschte 
Initialisierung nicht umsetzen läßt?

Ich finde es reichlich verwirrend, daß bestimmte Befehle bzw. 
Befehlsteile (wie z.B. "after x ns") vom Synthese-Tool (in meinem Fall 
XST) einfach ignoriert werden, ohne daß der Programmier darüber 
informiert wird. Ich meine, wie kann ich denn sicher sein, daß das, was 
ich programmiert habe, auch tatsächlich alles im Chip ankommt? 
Erfahrungssache?

> Vorneweg: da ist gar kein FF beschrieben, sondern ein Latch.
Das ist auch interessant! Ich hab nämlich bemerkt, daß die Maschine auf 
dem FPGA zwar korrekt initialisiert wird, aber dafür regelmäßig 
"abstürzt" (d.h. einen anderen Zustand annimmt, als der Datentyp 
hergibt).
Mit einem Takt und Flankensteuerung war das Problem dann behoben.
Ich vermute, daß die Laufzeitunterschiede im FPGA dazu führen, daß die 
einzelnen Signale der Weiterschaltbedingungslogik Glitches an den 
Zustands-Latch-Eingängen erzeugen und die Zustands-Latches daher 
Kombinsationen annehmen können, die es gar nicht geben dürfte.

Autor: faul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann hast du ja jetzt auf die harte Tour erfahren, was es bedeutet 
ein nicht-synchrones Design zu bauen.

Für Anfänger gilt: Alles synchron! Dann gibt es auch keine Glitches.
Ich für meinen Teil habe Zustandsmaschinen jedenfalls nur mit Takt 
kennengelernt, wie soll ohne einen Takt auch von einem in den nächsten 
Takt umgeschalten werden?

Autor: faul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der letzte Satz sollte heissen: von einem Zustand in den nächsten 
Zustand...

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian F. schrieb:
> Ich finde es reichlich verwirrend, daß bestimmte Befehle bzw.
> Befehlsteile (wie z.B. "after x ns") vom Synthese-Tool (in meinem Fall
> XST) einfach ignoriert werden, ohne daß der Programmier darüber
> informiert wird. Ich meine, wie kann ich denn sicher sein, daß das, was
> ich programmiert habe, auch tatsächlich alles im Chip ankommt?
> Erfahrungssache?

Es gibt einen Standard was ein Synthese-Werkzeug umsetzen muss und was 
nicht: IEEE 1076.6

Zudem musst Du ins Handbuch des Werkzeuges schauen. Und manche Tools 
geben Dir eine Warning oder eine Info mit der Information das etwas 
nicht synthetisierbar ist.

Btw. IEEE 1076.6 lässt keine Initialisierung bei der Deklaration zu. 
Doch viele Tools können das trotzdem. Bei XST ist es wohl standardmäßig 
aktiviert. Bei manch anderem muss man es explizit aktivieren.

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
faul schrieb:
> Na dann hast du ja jetzt auf die harte Tour erfahren, was es bedeutet
> ein nicht-synchrones Design zu bauen.

Das ist übrigens falsch. Das Design an sich ist synchron. Und zwar zum 
Signal in_button0_b.
Allerdings handelt es sich dabei um ein Design aus Latches. Das ist in 
einem FPGA oder CPLD zwar eine Sünde, aber in einem ASIC kann man sowas 
bauen. Allerdings muss ein solches Design umfassender mit Constraints 
versehen werden und die STA muss genauer ausgeführt werden.

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Hmmmmm...:
> latched    <= input when speichern='1';
> registered <= input when rising_edge(speichern);

Ok, so hab ich das noch nie versucht ...

Sebastian F. schrieb:
> Ich finde es reichlich verwirrend, daß bestimmte Befehle bzw.
> Befehlsteile (wie z.B. "after x ns") vom Synthese-Tool (in meinem Fall
> XST) einfach ignoriert werden

Das after x ns nicht synthesefähig ist, wird durchaus in der Literatur 
erwähnt. Die Unterschiede zw. Simulation und Synthese sollte man 
unbedingt kennen und sich nicht auf das Synthesetool verlassen.

Mathi schrieb:
> Das ist übrigens falsch. Das Design an sich ist synchron. Und zwar zum
> Signal in_button0_b.
... und dann noch zu in_button1_b und in_button2_b ...
3 unsynchrone Signale ... sehr synchron

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan R. schrieb:
> Ich bin zwar kein Theoretiker, aber Automaten arbeiten Zeitdiskret.
Nein. Die Übergänge eines Automaten sind idR. komplett zeitunabhängig. 
Z.B. Kaffeeautomat: Irgendwann drückt einer mal die starttates, dann 
wird ein Bescher ausgewrofen, der von der Schwerkraft gezogen beliebig 
langsam in den Halter fällt. Danach wird Wasser eingelsaaen, was druck- 
und kalkabhängig schneller oder langsamer geht. Dann das Aufheizen, 
Abfüllen....
Nirgends in diesem Ablauf ist die Zeit vorrangig nötig.
> Für mich als Praktiker heisst das: Zustände ändern sich bei
> steigende/fallende Flanken!
In der Praxis sind wie gesagt nur die Speicherglieder (hier FFs) 
diejenigen, die einen Takt brauchen...

Autor: Stefan R. (stefripp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Automatentheorie schert sich nicht um Gatterlaufzeiten :-)

Damit kann man sie zwar als graue Theorie abtun, aber alle Algorithmen 
der digitalen Signalverarbeitung basieren nun mal auf diesen Grundlagen. 
Wenn man, wie ich, kein brillianter Mathematiker ist, bleibt einem 
leider nicht anderes übrig, als diese Modelle als gegeben zu 
akzeptieren. Ganz egal wie ich meine Schaltung aufbaue: Sie muss 
möglichst nahe am Ideal der Theorie bleiben und die besagt: zeitdiskrete 
Abstände und abgestufte Werte.

Ich nehme meine Behauptung zurück, wenn ihr mir einen FIR Filter ohne 
Takt und ein halbes Bit zeigt!

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mac4ever schrieb:
> ... und dann noch zu in_button1_b und in_button2_b ...
> 3 unsynchrone Signale ... sehr synchron

Ah, ich hatte übersehen das es drei unterschiedliche in_buttonX_b gibt. 
Sorry!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan R. schrieb:
> Ich nehme meine Behauptung zurück, wenn ihr mir einen FIR Filter ohne
> Takt ... zeigt!
http://de.wikipedia.org/wiki/Akustische_Oberfl%C3%...
:
Der Aufbau bildet einen FIR-Filter.
:

Autor: Stefan R. (stefripp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Stefan R. schrieb:
>> Ich nehme meine Behauptung zurück, wenn ihr mir einen FIR Filter ohne
>> Takt ... zeigt!
> http://de.wikipedia.org/wiki/Akustische_Oberfl%C3%...
>
> :
> Der Aufbau bildet einen FIR-Filter.
> :
> 

Das ERSATZSCHALTBILD eines SAW Filters entspricht dem eines FIR-Filters. 
D.h. nicht, dass es ein FIR Filter und schon gar nicht, dass es eines 
ohne Takt ist.

http://www.axtal.com/data/buch/Kap9.pdf

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan R. schrieb:
> Das ERSATZSCHALTBILD eines SAW Filters entspricht dem eines FIR-Filters.
> D.h. nicht, dass es ein FIR Filter und schon gar nicht, dass es eines
> ohne Takt ist.
Die Implementierung eines Automaten gelingt am zuverlässgsten mit einem 
Takt. Das heißt aber nicht, dass es ohne Takt nicht ginge...

Zur Beruhigung: ich verwende für den Zustandsspeicher meiner Automaten 
auch FFs. Und brauche daher einen Takt. Das ERSATZSCHALTBILD des 
Automaten (die grafische Umsetzung) braucht allerdings keinerlei Takt, 
und der taucht dort auch nirgends auf...

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.