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?
> 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-Machine-mit-asynchronem-Eingang.html 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... :-/
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?
> 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-Einsynchronisieren > 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.
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-Einsynchronisieren > 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?
> 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.
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?
> 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... :-/
Gast
#1767244
>Ich programmiere nicht erst seit gestern
Ja nee, is klar ;O)
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.
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.
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.
> 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?
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.
> 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...
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.
> 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.
Gast
#1767477
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
Okay, mache ich. Was passiert wenn die Timing Constraints dann nicht eingehalten werden?
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/s3edl/s3edl0021_13.html 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.
>> 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...
Archie F..... schrieb: > Was die DCM's angeht: > http://www.xilinx.com/itp/xilinx7/books/data/docs/s3edl/s3edl0021_13.html > > 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?
> 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)...
Oh, okay, ich mach mich dann mal auf die Suche nach dem Fehler bzw. was das ganze so verlangsamt.
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).
Das ist auch ein guter Ratschlag. Danke! Ich mach das mal, wenn ich nachher dazu komme und dann berichte ich weiter.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.