Hallo liebe Community, ich habe ein Problem mit einem asynchronen FIFO. Weiß jedoch nicht ob der Fehler beim ISE, bei Modelsim oder bei mir liegt :) Das FIFO hat eine Schreibbreite von 8bit und eine Lesebreite von 16bit. Der Eingang ist mit 27MHz getaktet, der Ausgang mit 80MHz. Wie im Anhang zu sehen ist das FIFO leer, empty ist high. Anschließend schreibe ich was ins FIFO, wr_en geht also high. Ein paar Takte später steht im rd_data_count auf einmal 1025, also totaler Käse. Auffällig sind die beiden Spikes im Diagramm, ich weiß nicht wo die herkommen, kann sich das jemand erklären? Achja, das FIFO ist vom FWFT(first-word-fall-through) Typ. Ich verwende ISE 11.1 und Modelsim XE III 6.4b. FIFO-Generator 5.1 Bin für jeden Tipp dankbar :) Marcus (PS: Versuche gerade das Update auf 11.3, leider bricht es bisher immer ab)
Mit Sicherheit liegt der Fehler bei Dir. Ohne Code, nur anhand von Bildern kann man da nichts sagen. Die Spikes kommen wohl daher, dass Dein Counter asynchron entweder gecleart oder inkrementiert wird -- sowas macht man nicht ;-) Grüße, Kest
Hallo, hast du mal die Beschreibung des FIFOs da? Anhand der dargestellten Signale ist es noch nicht möglich auf das Verhalten zu schliessen. (mir jedenfall nicht) Der Besucher
Das FIFO ist ein Xilinx IP-Core. In Modelsim zu sehen sind alle Signale, die an den FIFO-Core (mmgrff_i) gehen. Der Counter ist auch nicht von mir erstellt, sondern das ist der read_counter vom generierten FIFO. Auszug aus dem Userguide: "For write operations, the write enable signal (WR_EN) and data input (DIN) are synchronous to WR_CLK. For read operations, the read enable (RD_EN) and data output (DOUT) are synchronous to RD_CLK. All status outputs are synchronous to their respective clock domains and can only be used in that clock domain." Hier der Link zum FIFO Generator Userguide: http://www.xilinx.com/support/documentation/ip_documentation/fifo_generator_ug175.pdf Hab die Testbench, die ins FIFO schreibt mal angehangen, vielleicht überseh ich ja was einfaches :) gruß Marcus
Was passiert, wenn Du in das volle Fifo schreibst? Sowas darf nicht passieren. Deshab funktioniert es ja auch wohl nicht. GEnauso, wenn man aus dem leeren FIFO liest. Sowas sollte drin sein WR_EN <= WR_RDY -- oder ähnlich: WR_EN <= not FIFO_FULL (Beispiel) Grüße, Kest
constant clk50_period : time := 10 ns; -- 50 MHz Das passt irgendwie nicht.. Die 50 MHz Clock läuft mit 100 MHz. Wird aber anscheinend auch nicht gebraucht. Mal weiter draufgugn. Der Besucher
@Kest Wo schreibe ich denn ins volle FIFO? Empty ist doch ein paar Takte vorher noch high und full, sowie overflow ist auch auf low. Hab vergessen zu erwähnen: Das FIFO ist 2048 8bit-Wörter tief. Ist ja nur eine Testbench, also alles vorhersagbar. Im späteren Topmodul wird RDY natürlich abgefragt (RDY <= not(FULL)); @Der Besucher Danke, das mit der Clock hat sich wohl irgendwie eingeschlichen. Muss natürlich 20ns heißen. Der FIFO bekommt als RD_CLK die clk80 (wird per dcm aus den 50Mhz Systemtakt generiert) und als WR_CLK die clk27. Habs gleich geändert und neu simuliert, aber Fehler ist trotzdem noch da. Hatte schon gehofft, dass der falsche Clock irgendwie dieses Chaos angerichtet hat :) Inzwischen hab ich das Update zum laufen gebracht, hat sich wohl nicht mit meinem Netzlaufwerk vertragen. Eventuell liegt der Fehler ja doch nicht bei mir.
Ok, vielen vielen dank für eure Mithilfe, auch wenn ich es selbst nicht geglaubt habe, aber es war anscheinend wirklich ein Bug. So wie im Anhang sollte es aussehen und tut es jetzt auch :) Ein Update auf die 11.3 hat es gelöst. (Normalerweise hätte ich das Update ja sofort Installiert, aber das war garnicht so einfach, zuerst musste ich dem Downloadmanager von Xilinx - der nicht durch die Firewall hier durchgekommen ist - den Direktlink rausprügeln, dannach wollte sich das Paket nicht installieren lassen... Ihr glaubt garnicht wie ermürbend das sein kann. Aber ein paar Tassen Kaffee später ist nun alles wunderbar :) ) PS: Ich hab das ganze mit anderen Clocks schonmal erfolgreich simuliert, anscheinend wars die Kombination aus 80MHz und 27MHz, die den Fehler provoziert hat. Also nochmal merci!
Ist es bei Xilinx wirklich so schlimm, dass man für einfache FIFOs einen Update ziehen muss? :-o DAs kann doch nicht wahr sein. Grüße, Kest
Nee, die FIFOs funktionieren in Hardware schon ewig fehlerfrei. Manchmal spinnen die Simulationsmodelle etwas, oder manche Core-Gen Versionen spucken bei der Synthese seltsame Warnungen aus, das wir dann immer mal behoben. Aber gerade die BlockRam FIFOs sind in HW auf dem Chip, die funktionieren.
Ja, bisher hab ich das immer (wegen damals fehlenden Simulationsmodellen) on-chip debugged mit Chipscope. Da hatte ich solche Probleme nie, da sieht man immer die Realität (zumindest fast) :) Achja, nur falls jemand nach mir auf ähnliche Probleme stößt und diesen thread findet: Auch in der 11.3 gibts Probleme bei meinem FIFO. Zwar springt der Counter nichtmehr unvorhersehbar, allerdings zeigt er beim auslesen an, dass noch ein Wort im FIFO ist und empty ist auch low. Immerhin geht Empty in der post-translate Simulation rechtzeitig auf high, obwohl wenn der rd-Counter noch auf 1 steht. Ich hoffe in Hardware zeigt der rd-Counter so wie beschrieben den "worst-case" an, allerdings hab ich grade nicht mehr so viel Motivation da weiter zu testen, denn dieser Bug spielt für mein Projekt gerade keine Rolle. Gruß Marcus
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.