mikrocontroller.net

Forum: FPGA, VHDL & Co. FIFO mit zwei Tack


Autor: leblanc (Gast)
Datum:

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

Autor: Busy (Gast)
Datum:

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

Autor: Johann (Gast)
Datum:

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

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

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Johann (Gast)
Datum:

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

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

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

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Datenblatt von dem FIFO WIZARD ist auch alles andere als gut. Dort 
sind keine Beispielansteuerungen dargestellt.

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

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Johann (Gast)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Johann (Gast)
Datum:

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

Autor: Christian R. (supachris)
Datum:
Angehängte Dateien:

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

Autor: Johann (Gast)
Datum:

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

Autor: Johann (Gast)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Johann (Gast)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: bko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
ausgang_vaild <= '1' when (empty='0') AND (rd='1') ELSE '0';

Autor: Christian R. (supachris)
Datum:

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

Autor: Martin (Gast)
Datum:

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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh das war der flasche Thread

Autor: leblanc (Gast)
Datum:

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

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.