mikrocontroller.net

Forum: FPGA, VHDL & Co. asynchrones FIFO macht murks in modelsim


Autor: Marcus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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_doc...

Hab die Testbench, die ins FIFO schreibt mal angehangen, vielleicht 
überseh ich ja was einfaches :)

gruß Marcus

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach, der Fifo benötigt die...

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Marcus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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.