Hallo zusamen, Ich versuche ein FIFO mit zwei Frequenz zu betrieben, irgendwie passiert beim lesen Seite der FiFo dass manchemal gleiche Daten zwei mal gelesen wird. was könnte die Ursachen sein? ist die Asynchronität das Problem? wenn ja, wie komme ich durch? PS: Die Daten werden kontinuerliche geschrieben, aber gelesen nicht weil Eingang Clock viel langsam als Ausgang Clock. ich steuer die Ausgang mit prog_empty flag. Viele danke für eure Hilfe
Antwort: 42 Oder etwas ausfuehrlicher: Beschreib dein Problem mal mit etwas mehr Informationen: - Hast Du den FIFO selbst beschrieben oder einen fertigen Core genutzt. - Wenn selbstgeschrieben, Source anfuegen - Wenn fertiger Core: - Welche Software ? Hersteller - Xilinx ISE Coregenerator - Altera - Genaue Version, FWFT ( First Word Fall Through )? Ggffls. auch der Code wo Du das FIFO mit dem Rest deiner Beschreibung verbindest. Dann kann Dir auch jemand weiterhelfen. Gruss Busy
Ich habe das gleiche Problem. Ich verwende einen Spartan XC4S400A. Ich habe mit dem IP-Core Wizard (ISE Version 11.4) einen FIFO erstellt. Der FIFO hat einen 16Bit breiten Eingangsdatenbus und einen 8Bit breiten Ausgangsdatenbus. Die Daten werden mit 2MHz (16Bit) in den FIFO geschrieben und mit 8MHz (8Bit Datenbusbreite) aus dem FIFO gelesen und übertragen. Ich verwende das "EMPTY-FLAG" vom FIFO. Sobald Daten im FIFO vorhanden sind, sollen diese ausgelesen werden und übertragen werden. Ich habe eine Simukation erstellt. Hier ist mir schon aufgefallen, das es mit dem EMPTY-FLAG beim FIFO erhebliche Probleme gibt. Das EMPTY-FLAG wird erst gesetzt wenn ich 5 Bytes reingeschrieben habe. Eigentlich sollte es sofort gesetzt werden, sobald das 1. Byte reingeschrieben wurden. Dann habe ich auch das Problem das ich 1 Byte immer dopplert auslese, das das EMPTY-FLAG zu lange gesetzt bleibt. Ich schreibe ja mit dem WRITE_CLK 16Bit rein und lese 2x mit dem READ_CLK 8 Bit aus. Die Empty-Leitung bleibt jedoch für 3 CLK-Zyklen auf 0, somit wird das LOW-Byte und 2x das HIGH-Byte ausgelesen.
Angehängte Dateien:
-
FIFO.png
5 KB
Ich habe mal einen Screenshot von der Simulation beigefügt. Es wird ein 16Bit Wert in den FIFO geschrieben. Der Datenausgang ist 8 Bit. Demnach muss ich wenn ich 1x16 Bit in den FIFO schreibe, 2x8 Bit aus dem FIFO auslesen. In der Simulation ist jedoch zu erkennen, das das EMPTY-FLAG zu lage auf '0' ist und ich somit 3 mal Daten auslese. Somit lese ich das LOW-Byte und 2. das HIGH-Byte aus.
Ist das ein FWFT FIFO oder ein Standard FIFO? Und kannst du mal das VALID Flag mit anschauen? Ich benutze immer die FWFT Fifos aus dem CoreGen und solche Probleme hatte ich noch nie. Wenn das schon in der Simulation so ist, ist da vermutlich ein Verständnis- oder Doku-Fehler, oder? Das mit den 5 Takten Verzögerung ist normal. Daher auch die Warnung von Modelsim, dass das Modell nicht cycle-accurate ist.
Ich habe den FIRST-WORD FALL-THROUGH FIFO verwendet. Es ist leider nicht nur in der Simulation so. Auch die Daten die ich am PC empfange haben das Verhalten. Wenn jetzt z.B. mehrere 100Bytes im FIFO sind dann wird aus dem FIFO immer zuerst das LOW-Byte und dann 2x das HIGH-Byte ausgelesen. Natürlich könnte ich jetzt immer das 3. Byte verwerfen, jedoch sollte doch der FIFO auch richtig funktionieren. Ich weiß nicht ob dies nur ein Fehler ist wenn man den SPARTAN3 verwendet und dieser Fehler bei einem Virtex 5 oder Spartan 6 nicht mehr auftritt.
Angehängte Dateien:
-
FIFO_1.png
986 Bytes
So ich habe mal das Data Valid Flag für das Auslesen der Daten hinzugefügt. Im Schreenshot ist zu sehen das das DATA-VLID-FLAG zu spät kommt. Der FIFO gibt somit mit dem EMPTY-FLAG an das ich momentan DATEN im FIFO habe. Gebe ich jetzt den 1. LESEPULS drauf (RD_EN) das wird das LOW-Byte ausgegeben, die VALID Leitung geht jedoch 1 Takt zu spät an.
Das Datenblatt von dem FIFO WIZARD ist auch alles andere als gut. Dort sind keine Beispielansteuerungen dargestellt.
Angehängte Dateien:
-
FIFO.png
4 KB
ACHTUNG das FIFO_1.png ist im FIFO Standard MODUS. Wenn ich den FIFO auf FIRST-WORD FALL-THROUGH umstelle sieht es wie folgt aus. Das EMPTY-FLAG und das VALID-FLAG sind von der Zeit her IDENTISCH.
Das könnte dann wirklich ein Bug sein. Welche Version des Fifo Generators verwendest du? Die aktuelle? Hast du mal die Release-Notes angeschaut? Ich hab solche Probleme noch nie damit gehabt, auch am Spartan 3e nicht. Auf den Unterschied zwischen Standard und FWFT wollte ich hinaus, aber wenn das beim FWFT auch so dämlich ist....hmm...komische Sache. Standard Modus ist ja demnach korrekt, da muss man 1 Takt Latenz einrechnen und am besten das VALID Flag beachten.
Ich verwende die Version 5.3 vom ISE 11.4. Ich wollte jetzt eigentlich nicht auf eine neue Version updaten. Wo finde ich denn die Relaseinformationen? ` Es gibt ja inzwischen die Version 6.2 im ISE 12.2 jedoch kann ich nicht finden ob dort dieser Bug behoben ist. Welche Version verwendest Du denn?
Die Infos findest du im Ordner: C:\Xilinx\12\ISE_DS\ISE\coregen\ip\xilinx\primary\com\xilinx\ip\fifo_gen erator_v6_2\doc ggf. den Installationspfad und Versionsnummer anpassen. Ich hatte 4.4 5.1 5.3 6.1 und 6.2 und bei keiner der Versionen hatte ich sowas. Aktuell ein Projekt auf einem Spartan 3e, mit FWFT FIFO, auch 16 Bit rein, 8 Bit raus....macht genau, was er soll.
Da kann ich doch eigentlich nicht viel falsch machen. Ich schreibe nur 1 Datenwert ins FIFO (16Bit) und das EMPTY-FLAG ist für 3 READPULSE gesetzt. Ich habe noch mal ins Datenblatt geschaut. Dort ist beschrieben das das EMPTY-FLAG auch nur 2 Pulse gesetzt sein darf. Ich werde jetzt aus mal die Version 12.2 Herunterladen. Vielleicht geht es ja damit. Kannst Du nicht vielleicht ein kleines Projekt erstellen wo mit jedem WR_CLK 16 Bit reingeschrieben werden und 8 Bit Datenausgang. Bitte dann nur 1 Wert in den FIFO schreiben und dann schauen was die Simulation macht. Kann es sein das vielleicht nur die Simulation falsch ist?
Angehängte Dateien:
-
FIFO.png
4,6 KB
So, schneller Test: ISE 12.2, Spartan 3e, FWFT BlockRAM FIFO, Read Clock schneller als Write Clock. Fifo Generator 6.1, ModelSim XE 6.5.c: Alles OK. Edit: Das gleiche Ergebnis mit Core Generator 5.3 und auch mit ISim. Also da muss bei dir was schief sein....
Genau so muss es ausehen. Vielen Dank für den Screenshot. Nur leider weiß ich jetzt immer noch nicht warum bei mir die FIFO-EMPTY Leitung 3 Takte auf '0' unten ist. Bei Dir ist die EMPTY-Leitung ja nur 2 TAKTE auf '0' (so wie es sein soll) Ich werde mein Design noch mal überprüfen. (gleichzeitig lade ich gerade die 12.2 Version herunter)
Was passiert denn eigentlich wenn ich 2 extern vollkommen unabhängige CLOCKS verwende. Ich habe einen AD-Wandler der erzeugt z.B. mit 6MHz Daten. Hier verwende ich einen externen Qaurz, der an den AD-Wandler angeschlossen ist und auch direkt an den FPGA angeschlossen ist. Außerdem verwende ich den FTDI Chip (FT2232H --> erreicht 45MByte Datentransferrate pro Sekunde) Dieser erzeugt einen 60MHz Takt der auch an den FPGA angeschlossen ist. Diese beiden Takte laufen jetzt vollkommen unabhängig voneinander. Jetzt könnte doch im WORST-CASE-FALL die Taktflanke vom 60MHz Takt so dicht an der Flanke vom 6MHz Takt liegen, das die Setup and Hold Time nicht mehr eingehalten werden kann. Dies würde dann Fehler erzeugen. Es wäre sicherlich besser gewesen den 60MHz Takt durch ein DCM auf 6MHz zu reduzieren und dann auf den AD-Wandler zu geben. In der Simulation ist die Phasenlage der beiden Clocks jedoch konstant zueinander, so das dies keine negativen Einflüsse auf die Simulation hat.
Um die Synchronisation des Schreib- mit dem Lesetaktes kümmert sich der FIFO schon, wenn du "Independent Clocks" eingestellt hast. Das klappt immer, man hat dann höchstens mal einen Takt mehr oder weniger Latenz zwischen Schreiben und dem Valid am Ausgang.
Das wäre ja super wenn der FIFO die beiden unabhängigen Takte
miteinander syncronisiert.
Mir ist aufgefallen das Du sofort das RD_EN-Signal setzt sobald der FIFO
Daten besitzt. Demnach hast Du das EMPTY-FLAG mit einen INVERTER direkt
auf den RD_EN gegeben. Dadruch verrzögert sich der RD_EN-Pulse um einen
Takt. Dies ist ja auch kein Problem, jedoch darf der RD_EN Pulse nur 2
Takte lang sein. Bei mir ist er 3 Takte lang und das ist der FEHLER. Ich
werde noch mal eine Nacht drüber schlafen und morgen noch mal in Ruhe
drüber schauen.
Bei mir ist es so, das ich schauen ist mein Empfänger bereit.
process(FT2232H_CLK)
begin
if(FT2232H_CLK'event and FT2232H_CLK='1')then
if(GLOBAL_RESET = '1') then
FT2232H_WR <= '1';
READ_FIFO_DATA <= '0';
elsif(FT2232H_TXE = '0' and FIFO_IS_EMPTY = '0') then
FT2232H_WR <= '0';
READ_FIFO_DATA <= '1';
else
FT2232H_WR <= '1';
READ_FIFO_DATA <= '0';
end if;
end if;
end process;
Für den Test hab ich das Empty einfach invertiert und auf rd_en gegeben, richtig. Wieso soll sich da was verzögern? Das ist reine Kombinatorik. Kein FlipFlop dazwischen. Mit der nächsten Flanke wird der Wert aus dem FIFO dann in das nächste Register oder was auch immer übernommen. Völlig normales synchrones Design. Der rd_en Puls wird weder verzögert, noch verlängert. Wenn Empty 2 Takte lang low ist, dann ist rd_en auch 2 Takte lang High. Wenn du das wie oben beschrieben in einen getakteten Prozess packst, musst du natürlich auch beachten, dass die Daten ebenfalls verzögert werden müssen. Sonst passt das Empty (was ja gültige Daten signalisiert) nicht mehr zum Datenwort am FIFO. Ich würde das nicht so machen, sondern kombinatorisch.
Wenn ich deinen Screenshot von 12:00 (FIFO.png) richtig interpretiere (ich erkenne die Beschriftung nicht 100% richtig) ist zwar das "empty" Signal 3 Takte lang 0, aber dein read Signal "rd" wird erst einen Takt später 1. Ich denke, solange der Inhalt des Fifos nicht gelesen wird (rd=1), solange bleiben die letzten Daten am Ausgang des Fifos stehen.
1 | ausgang_vaild <= '1' when (empty='0') AND (rd='1') ELSE '0'; |
Hm stimmt, mit etwas Fantasie ist die Beschriftung rd_en. Na dann ist ja alles völlig planmäßig. Solange kein rd_en zur steigenden Flanke aktiv war, ändert sich natürlich weder etwas an den Flags noch an den Daten am FIFO Ausgang. Das EMPTY ist dann noch 2 Takte Low bei aktivem rd_en, was 2 gültigen Bytes entspricht. Also alles planmäßig. Wie ich oben schon vermutet habe, ein Verständnisfehler.
Ich bin heute krank und werde mich ins Bett legen und mich die nächsten Tage noch mal mit dem Problem befassen. Schon mal vielen Dank für Deine Hilfe Christian R.
Hallo Leute, Ich bin nicht auf mein Beitrag zuruck gewesen, weil ich die Lösung mein Problem gefunden hatte. eigentlich war ein inkompatibilität mit Fifo Version und ISE version. Ich habe einfach der alte Fifo gelöscht und neue erzeugt und mein problem war weg. Viele dank noch ein mal.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.