mikrocontroller.net

Forum: FPGA, VHDL & Co. Seltsames FPGA Verhalten beim Systemstart


Autor: Andreas M. (hansblafoo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo miteinander!

Mit VHDL kenne ich mich mittlerweile schon etwas aus, aber jetzt stehe 
ich vor einem gewaltigen Problem. Es geht um folgende Praktikumsaufgabe, 
bei der auch mein Betreuer auf die Schnelle noch keine Lösung gefunden 
hat.

Zur Umgebung: Wir nutzen Xilinx Spartan 3 FPGAs und programmieren mit 
dem Xilinx ISE WebPack 10.1 SP 3.

Der Code stellt den so genannten Geld-Decoder einer Autowaschanlage dar. 
Der Nutzer kann über Tastendrücke verschiedene Geldbeträge (50 ct, 1 € 
und 2 €) einwerfen, die direkt in die entsprechende Waschzeit 
umgerechnet werden. Maximal kann der Nutzer 9 € einwerfen, bzw. 90 mal 
10 ct. (Daher der Check auf 90, da keine einstelligen Cent-Beträge 
möglich sind und ich deshalb die Beträge direkt durch 10 dividiert 
annehme )
Versucht er dagegen mehr Geld einzuwerfen, soll das Display flackern, 
was über die Shake-Leitung signalisiert wird.

Das Problem ist nun, dass beim Systemstart, selbst ohne Tastendrücke 
(!), ein Flackern ausgelöst wird, also eine logische 1 auf dem 
Shake-Port liegt. Klapprige Tasten kann man ausschließen, da ich diese 
entprelle und durch meine Tests schon herausgefunden habe, dass es daran 
nicht liegt. Genauso wenig sind Hardwareprobleme Schuld. Das Problem 
tritt auch bei anderen FPGAs derselben Reihe auf. Im Simulator von ISE 
läuft es ohne Probleme und wenn ich zudem mindestens eine dieser 
Überprüfungen auf Tastendrücke herausnehme, so tritt das Problem auch 
beim FPGA nicht auf!

Ehrlich gesagt, bin ich da mit meinem Latein am Ende. Ich programmiere 
nicht erst seit gestern, habe den Code zig Mal gesehen und durchdacht, 
aber so etwas ist mir noch nie passiert. Wo ist da das Problem? Ich 
vermute mittlerweile, dass die VHDL-Synthese irgendwie schief geht.


Hat da irgendjemand eine Idee was da falsch ist?

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

Bewertung
0 lesenswert
nicht lesenswert
> Das Problem ist nun, dass beim Systemstart...
Ich habe den Code noch nicht angeschaut, aber ich tippe jetzt mal 
zuallererst auf einen asynchronen Reset...
:
: Schaut sich den Code an...
:
Ja, das sieht nicht schlecht aus für mich und mein Gefühl:
Der Reset ist nicht einsynchronisiert. Und auch keines der anderen 
Signale ist einsynchronisiert. Er ist zwar synchron beschrieben, aber 
hier passiert mit ziemlicher Sicherheit sowas:
http://www.lothar-miller.de/s9y/archives/64-State-...

Mach mal die Einsynchronisierung mit jedem Signal, das von aussen kommt, 
und dein Design wird eher das tun, was die Simulation sagt.

Allerdings ist die unnötige Verwendung von Variablen noch überaus sehr, 
sehr fragwürdig...  :-/

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, dein Link öffnet sich bei mir leider irgendwie nicht so recht. 
Deine Domain scheint schlecht erreichbar zu sein.

Was meinst du mit einsynchronisiert? Sämtliche Ports dieser Entity sind 
an andere Komponenten angebunden, die ihrerseits auf die gleiche Weise 
synchronisiert sind. Wie können die Signale dann also asynchron 
vorliegen?

Welche Variablen sind denn unnötig bzw. wie könnte ich es vereinfachen?

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

Bewertung
0 lesenswert
nicht lesenswert
> Hmm, dein Link öffnet sich bei mir leider irgendwie nicht so recht.
Echt zäh. Sch... Strat.. :-/
Probiers nochmal...

> Was meinst du mit einsynchronisiert?
Signale die von der Aussenwelt kommen haben die Tendenz, asynchron zum 
FPGA-Takt zu sein...
Deshalb müssen sie über 2 FFs eingetaktet werden. Stichworte u.a. 
Metastabilität und Laufzeit:
http://www.lothar-miller.de/s9y/categories/35-Eins...

> Welche Variablen sind denn unnötig bzw. wie könnte ich es vereinfachen?
Alle. Nimm stattdessen Signale.
Speichernde Werte in Variablen können dir die ganze Simulation 
zerhageln...
Du kannst sie auch nicht in die Sensitivliste eines anderen Prozesses 
aufnehmen.

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Hmm, dein Link öffnet sich bei mir leider irgendwie nicht so recht.
> Echt zäh. Sch... Strat.. :-/
> Probiers nochmal...
>
Hmm, immer noch träge.

>> Was meinst du mit einsynchronisiert?
> Signale die von der Aussenwelt kommen haben die Tendenz, asynchron zum
> FPGA-Takt zu sein...
> Deshalb müssen sie über 2 FFs eingetaktet werden. Stichworte u.a.
> Metastabilität und Laufzeit:
> http://www.lothar-miller.de/s9y/categories/35-Eins...
>

Okay, ja, das ist mir natürlich bewusst. :) Ich kannte bloß die 
Formulierung "einsynchronisieren" nicht. Aber wie ich schon sagte, 
sämtliche asynchronen Signale habe ich in anderen Komponenten 
synchronisiert. Dieser Geld-decoder erhält dagegen direkt die synchronen 
Ausgaben der anderen Komponenten. (Alle arbeiten auch mit dem selben 
Takt)

>> Welche Variablen sind denn unnötig bzw. wie könnte ich es vereinfachen?
> Alle. Nimm stattdessen Signale.
> Speichernde Werte in Variablen können dir die ganze Simulation
> zerhageln...
> Du kannst sie auch nicht in die Sensitivliste eines anderen Prozesses
> aufnehmen.

Wirklich alle? Hm, okay.

Dazu hätte ich aber gleich mal eine Frage, denn bei den Signalen war ich 
mir bisher unsicher. Verstehe ich folgendes richtig:

Statt der Variablen soll ich jetzt Signale verwenden, deren Werte ja 
erst verzögert feststehen (Variablen werden dagegen "sofort" 
übernommen).

1. Kann ein Prozess jetzt ein Signal an sich selber schicken?

Zum Beispiel summiere ich ja die eingeworfene Geldsumme auf (money_sum). 
Wie kann ich nun wenn der Prozess das nächste Mal aufgerufen wird auf 
diese Geldsumme zugreifen, wenn ich das per Signalen realisiere?

2. Und welcher Wert wird angenommen, wenn ich einem Signal mehrfach 
einen Wert zuweise? Der zuletzt Zugewiesene?

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

Bewertung
0 lesenswert
nicht lesenswert
> Statt der Variablen soll ich jetzt Signale verwenden, deren Werte ja
> erst verzögert feststehen (Variablen werden dagegen "sofort"
> übernommen).
Diese Denkweise ist etwas halbgar. Auch Signale werden sofort z.B. mit 
einem Takt übernommen. Allerdings gilt nur der zuletzt im Prozess 
zugewiesene Wert. Während des gesamten Prozesses behalten die Signale 
ihren Ausgangswert.

Es ist nicht so, dass ein Prozess Schritt für Schritt von oben her 
abgearbeitet wird. In der harten Realität passiert das alles 
gleichzeitig. Der Synthesizer nmuß also deine Variablen-Geschichten 
quasi "vorausschauend" abbilden, dazu ist einiges an Kombinatorik nötig 
(Addierer, Subtrahierer, Multiplexer), das dauert...
Welche Taktfrequenz hast du?
Hast du darauf ein Timing-Constraint gesetzt?

> 1. Kann ein Prozess jetzt ein Signal an sich selber schicken?
Ja, aber das macht nur bei kombinatorischen Prozessen Sinn. Wenn der 
Prozess getaktet ist, dann hast du 1 Takt Latency.

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, danke für die bisherigen Erläuterungen! Ich versuche das mal 
parallel so umzusetzen, wie du es empfohlen hast.

Der FPGA taktet mit 50 MHz, wird aber intern über einen Taktteiler schon 
auf 10 MHz runtergeteilt. Das sollte also kein Problem sein.

Dazu gleich mal noch eine Frage: Spricht eigentlich, wenn man eine 
bestimmte Zeit abwarten möchte (z.B. beim Entprellen von Tasten) etwas 
gegen das wait for xxx statement? Oder sollte man da stattdessen auf 
Zähler setzen?

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

Bewertung
0 lesenswert
nicht lesenswert
> Der FPGA taktet mit 50 MHz, wird aber intern über einen Taktteiler schon
> auf 10 MHz runtergeteilt.
Wie machst du das? Mit einem DCM?
Oder machst du das "einfach" in VHDL mit einem Zähler?
Falls ja: wie kommst du dann wieder auf ein Taktnetz (nur dort haben 
globale Takte etwas zu suchen, denn sonst hast du 1. eine Warnung und 2. 
einen undefinierbaren Skew auf dem Takt) ?

> Spricht eigentlich, wenn man eine bestimmte Zeit abwarten möchte
> (z.B. beim Entprellen von Tasten) etwas gegen das wait for xxx statement?
Gegen "wait for 1ms" spricht nur, dass es nicht in Hardware umsetzbar 
ist. Simulieren kannst du das schon... :-/

Autor: IsKlar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich programmiere nicht erst seit gestern

Ja nee, is klar ;O)

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Der FPGA taktet mit 50 MHz, wird aber intern über einen Taktteiler schon
>> auf 10 MHz runtergeteilt.
> Wie machst du das? Mit einem DCM?
> Oder machst du das "einfach" in VHDL mit einem Zähler?
> Falls ja: wie kommst du dann wieder auf ein Taktnetz (nur dort haben
> globale Takte etwas zu suchen, denn sonst hast du 1. eine Warnung und 2.
> einen undefinierbaren Skew auf dem Takt) ?

Japp, über einen DCM geht das.

>
>> Spricht eigentlich, wenn man eine bestimmte Zeit abwarten möchte
>> (z.B. beim Entprellen von Tasten) etwas gegen das wait for xxx statement?
> Gegen "wait for 1ms" spricht nur, dass es nicht in Hardware umsetzbar
> ist. Simulieren kannst du das schon... :-/

Ah, okay, irgend soetwas dachte ich mir schon.

Autor: Archie F..... (archie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe ein typisches DCM Problem. Führe einen DCM Reset aus getaktet 
auf deinen Eingangstakt z.b nach Zählen der X Flanken,Beobachte mit 
diesem Taks den Lock Zustand der DCM, erst nach einem ordentlichen DCM 
Reset (Zeit beachten, am besten 1ms) und dem Lock Zustand sollte deine 
Sparbuchse oder was auch immer du programmierst anspringen.

PULLDOWN im ucf file für deine reset Leitung wäre auch nicht schlecht.

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Archie F..... schrieb:
> Ich sehe ein typisches DCM Problem. Führe einen DCM Reset aus getaktet
> auf deinen Eingangstakt z.b nach Zählen der X Flanken,Beobachte mit
> diesem Taks den Lock Zustand der DCM, erst nach einem ordentlichen DCM
> Reset (Zeit beachten, am besten 1ms) und dem Lock Zustand sollte deine
> Sparbuchse oder was auch immer du programmierst anspringen.
>
> PULLDOWN im ucf file für deine reset Leitung wäre auch nicht schlecht.


Sorry, ich hab leider nichts verstanden. Kannst du es mal anderes 
erklären?
Die Reset-Leitung ist keine physische Leitung auf dem Board, sondern 
dient bloß der Kommunikation zwischen einer anderen Komponente und dem 
Geld_decoder.

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

Bewertung
0 lesenswert
nicht lesenswert
> Die Reset-Leitung ist keine physische Leitung auf dem Board, sondern
> dient bloß der Kommunikation zwischen einer anderen Komponente und dem
> Geld_decoder.
Kannst du nicht einfach mal das Drumrum auch posten?

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, schwierig, da das eine Mischung aus Schaltungsentwurf und VHDL ist, 
sodass das einige Komponenten plus Schaltungen sind.

Ich habe aber herausgefunden, dass es eben definitiv am Geld_Decoder 
liegen muss. Ich werde die Variablen mal durch Signale ersetzen 
(natürlich das es auch funktioniert ;) ) und dann mal schauen.

Kann da irgendetwas bei der Synthese schief gelaufen sein? Wie gesagt, 
der Rest funktioniert einwandfrei, ich habe alles streng synchron 
implementiert, asynchrone Eingangssignale werden synchronisiert und das 
Verhalten ist einfach nur beim Start seltsam.

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

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe aber herausgefunden, dass es eben definitiv am Geld_Decoder
> liegen muss.
Wenn du ein Design hast, das knapp an der Grenze läuft, dann kannst du 
irgendwo was ändern und irgendetwas Anderes wird ein wenig anders 
verdrahtet und schon läuft das Ding nicht mehr richtig.

> Kann da irgendetwas bei der Synthese schief gelaufen sein?
Es kann natürlich schon so sein, man hat schon Pferde kotzen sehen. Du 
hast auf jeden Fall einen Mordskoffer an Kombinatorik beschrieben...

Wobei anzumerken ist, dass die meisten deiner Zählervariablen nicht über 
einen Initwert verfügen (das fiel mir auf jeden Fall auf Anhieb auf)...

BTW:
Die Frage nach dem Timing-Constraint bzw. der maximalen Taktfrequenz ist 
noch unbeantwortet...

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timing Constraints habe ich nicht und als maximale Taktfrequenz spuckt 
er irgendetwas um die 160 MHz aus. Aber wie gesagt, er wird mit 50 MHz 
getaktet.

Die obere gepostete Version ist etwas alt, mittlerweile haben alle 
Variablen einen Initialwert. Hat aber auch nichts gebracht.

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

Bewertung
0 lesenswert
nicht lesenswert
> Timing Constraints habe ich nicht
Mach das besser mal, kost ja nix.
Jedes FPGA-Design sollte mindestens den gewünschten Takt vorgegeben 
haben. Denn wenn du keinen Clock-Constraint angibst, darf der Placer das 
Design legen wie er will. Und glaub mir: der gibt sich dabei keine 
Mühe...
Da ist der Wert, den die Synthese ausgibt, schnell versaut.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Timing Constraints habe ich nicht
> Mach das besser mal, kost ja nix.
> Denn wenn du keine Timing-Constraints angibst, darf der Placer das
> Design legen wie er will. Und glaub mir: der gibt sich dabei keine
> Mühe...
> Da ist der Wert, den die Synthese ausgibt, schnell versaut.

Auch mit Timing Constraints ist der Placer manchmal faul wie ich 
unlängst feststellen durfte :(
Synthese sagt 170 MHz und der Placer schafft nur manchmal knapp die 
geforderten 125MHz

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, mache ich.

Was passiert wenn die Timing Constraints dann nicht eingehalten werden?

Autor: Archie F..... (archie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was passiert wenn die Timing Constraints dann nicht eingehalten werden?
Im besten Fall läuft deine Schaltung langsamer als geplant :)

Was die DCM's angeht:
http://www.xilinx.com/itp/xilinx7/books/data/docs/...

Es ist wichtig die locked Leitung zu beobachten. Erst wenn die DCM 
locked Zustand zeigt, sollte der Takt, der aus der DCM kommt als Takt 
gehandelt werden, alles andere davor ist ein undefiniertes Wackeln der 
CLK Ausgangsleitung. Außerdem sollten die DCM's immer ordentlich resetet 
werden, wenn der FPGA gerade beladen wurde.

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

Bewertung
0 lesenswert
nicht lesenswert
>> Was passiert wenn die Timing Constraints dann nicht eingehalten werden?
Du bekommst eine Fehlermeldung und weißt, woran du bist.  :-o

> DCM
> Es ist wichtig die locked Leitung zu beobachten.
Ja, das ist es, und das steht sogar im Datenblatt...

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Archie F..... schrieb:
> Was die DCM's angeht:
> http://www.xilinx.com/itp/xilinx7/books/data/docs/...
>
> Es ist wichtig die locked Leitung zu beobachten. Erst wenn die DCM
> locked Zustand zeigt, sollte der Takt, der aus der DCM kommt als Takt
> gehandelt werden, alles andere davor ist ein undefiniertes Wackeln der
> CLK Ausgangsleitung. Außerdem sollten die DCM's immer ordentlich resetet
> werden, wenn der FPGA gerade beladen wurde.

Ah, okay, jetzt hab ichs geschnallt! Danke!


Lothar Miller schrieb:
> Du bekommst eine Fehlermeldung und weißt, woran du bist.  :-o
>

Also ich habs mal laufen lassen und bei einer Komponente werden die 
Timing Constraints (10 ns) nicht eingehalten. Was kann das jetzt zur 
Folge haben, außer das es langsamer läuft? Ist damit der beschriebene 
Fehler möglich?

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

Bewertung
0 lesenswert
nicht lesenswert
> Was kann das jetzt zur Folge haben, außer das es langsamer läuft?
Es läuft nicht langsamer! Es läuft genauso schnell, wie du es mit deinem 
Takt willst. Aber es läuft FALSCH...   :-o

> Ist damit der beschriebene Fehler möglich?
Ja.

BTW:
Wie kommst du auf 10ns? Dein externer Takt sind doch 20ns (=50MHz)...

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, okay, ich mach mich dann mal auf die Suche nach dem Fehler bzw. was 
das ganze so verlangsamt.

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

Bewertung
0 lesenswert
nicht lesenswert
Klick mal auf den Prozess "Statische Timing Analyse"
in etwa: static timing analysis/report
Dann wird dir der schlechteste/langsamste Pfad angezeigt.

Aber ich denke, du wirst dein Modul ein wenig pipelinen müssen und die 
Berechnungen auf ein paar Takte verteilen (Stichwort dazu: State 
Machine).

Autor: Andreas M. (hansblafoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist auch ein guter Ratschlag. Danke!

Ich mach das mal, wenn ich nachher dazu komme und dann berichte ich 
weiter.

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.