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!
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
wave.png
(17 KB)
