mikrocontroller.net

Forum: FPGA, VHDL & Co. FIFO erst vollschreiben dann auslesen?


Autor: FPGA_Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
zur Taktsynchronisation benutze ich ein FIFO, generiert mit 
fifo_generator_v3.3 von Xilinx. Es steht im Userguide :

Important: FIFO Full and Empty flags must be used to guarantee proper 
behavior.

Ist es so zu verstehen, dass das FIFO erst vollgeschrieben werden muss 
und dann leer ausgelesen wird?

Danke für eure Antwort

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, du musst mit Schreiben bzw. Lesen aufhören, wenn entsprechende 
Flags gesetzt worden sind.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, man muss nicht aufhören, aber beim weiterlesen bekommt man dann 
immer das gleiche Datenwort, beim Schreiben gehn Worte verloren.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man dort kein half buffer filled ableiten ?
Ansonsten pointer selber überwachen und passend reagieren.

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist es so zu verstehen, dass das FIFO erst vollgeschrieben werden muss
und dann leer ausgelesen wird?

Macht nicht wirklich Sinn, oder?

Wenn's voll ist, passt nix mehr rein. Wenn's leer ist, ist halt nix mehr 
da zum lesen.

Beim Autotank oder beim Bierglas ist's auch nicht anders, zwischen voll 
und leer ist alles paletti ......

Autor: FPGA_Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das FIFO ist zur Taktsynchronisation da. Und wenn der Read-Takt 
schneller ist als der Write-Takt, dann muss ich doch das FIFO 
vollschreiben. Und dann erst auslesen, oder? Sonst verlange ich mehr 
Daten als das FIFO hergibt.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst das Leer-Flag eher andersrum betrachten. Du kannst immer dann 
Daten lesen, wenn der FIFO nicht leer ist. Ob er voll, halbvoll, 
viertelvoll oder sonstwas ist, ist egal. Hauptsache er ist nicht leer.

Autor: .Franky. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn die beiden Takte konstant sind (Read und Write) eignet sich ein 
FIFO nicht, weil

a) entweder die beiden Takte die selbe Frequenz haben und daher ein 
einfaches FlipFlop zur Synchronisation ausreichend ist

b) oder einer der Takte dauerhaft schneller ist, als der andere, was 
zwangsläufig zu einem Pufferüberlauf-(Puffer ist voll und du willst 
weitere Daten reinschreiben - FIFO Full) oder Pufferleerlauf (der Puffer 
ist leer und du willst weitere Daten lesen - FIFO Empty) führt. Im 
zweiten Fall würde wieder ein FlipFlop reichen.

Ein FIFO empfielt sich, wenn du auf einen Schlag eine gewisse begrenzte 
Menge an Daten mit einem schnellen Write Takt bekommst, die du so 
schnell nicht weiterverarneiten kannst, dann aber einige Zeit nichts auf 
der Write Leitung daherkommt. Dise Daten kannst du dann in aller Ruhe 
mit dem langsameren Lesetakt weiterverarbeiten, bis alle Daten 
verarbeitet sind und daher keine Daten mehr im Puffer sind und daher das 
Empty Flag gesetzt wird. Versuchst du trotzdem weiter zu lesen, liest du 
falsche Daten (ggf. den letzten Wert immer wieder).

Du musst dir für deine Applikation also überlegen : Was mache ich, wenn 
im Moment keine weiteren Daten zum Lesen da sind ? (z.B. 0llen lesen, 
oder die Verarbeitung aussetzen, bis weitere Daten da sind...)

Auf der anderen Seite kann es auch passieren, das du die Daten nicht 
schnell genug auslesen kannst, und es kommt schon der nächste Datenblock 
in den Puffer. Ist die Puffergröße gut gewählt, kann der Puffer den 
neuen Datenblock trotzdem aufnehmen. Ist der Puffer bereits voll, dann 
reagiert er mit dem FIFO-full flag, das dir sagt, daß du wenn du weitere 
Daten in den Puffer schreibst diese Daten verlierst. Der Read Takt muss 
daher im Mittel (also über einen längeren Zeitraum) mindestens so 
schnell sein wie der Write Takt.

Du musst dir also zusätzlich für deine Applikation überlegen : Kann/darf 
es vorkommen, das Daten verloren gehen, wenn sie schneller ankommen als 
ich sie verarbeiten kann ? Wie groß muss der Puffer sein, damit ich ein 
derartiges Szenario möglichst vermeide ? Was mache ich, wenn ich 
draufkomme, dass Daten doch verloren gegangen sind ? (Schreiben in den 
Puffer mit gesetztem Full-Flag)

....Meine gute Tat für heute...

Liebe Grüße : .Franky.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo kommen denn die Daten auf der Schreib-Seite her und wo gehen die 
Daten auf der Lese-Seite hin?

Autor: FPGA_Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erst mal, vielen Dank für eure Antwort.

Es gilt bei mir folgende Situation: Ein Sensor liefert Daten und diese 
Daten sollen in einem DDR2-SDRAM zwischengespeichert werden.

- Daten vom Sensor : 10 Ausgänge, je 8 Bit. Sensor arbeitet mit 66 MHz.
- DDR2-SDRAM 16 Bit Eingang, 133 MHz.
  --> logischerweise DDR2-Controller: 32 Bit Eingang, 133 MHz.

Von den 80 Bits, kommend vom Sensor, muss ich irgendwie schon aufteilen 
damit 32 Bit in den Controller gelangen. Oder? Daher denke ich, FIFO 
(oder mehrere FIFOs) ist eine Lösung.

Autor: .Franky. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist immer noch nicht klar, wieviele Daten der Sensor liefert. 
Nachdem was oben steht schafft er 80 Bit in 1/66MHz = 15us ? --> Also 
alle Daten paralell ??

Oder liefert der Sensor die Daten seriell ? (Auf einer Leitung alle 
Ausgänge-alle 8 Bit hintereinander)

Oder er liefert sie auf einem 8-Bit Bus ? (Alle Daten hintereinander - 
immer 8 Bit auf einmal - Also Alle Ausgänge hintereinander)

Oder er liefert sie auf einem 10-Bit Bus - Für jeden Ausgang eine eigene 
Leitung - Dort jeweils alle 8 Bit hintereinander

...

Im ersten Fall, wo du wirklich 80 Bit im 66MHz Takt bekommst, kannst du 
nicht alle Daten weiterverarbeiten. Wenn ich mich nicht verrechnet habe, 
kannst du z.B. 2 Bit/Ausgang oder 2 Ausgänge weglassen. Aber ich denke 
nicht, dass dein Sensor wirklich alles Paralell liefert.

Für den seriellen, und den 8-Bit seriellen Fall würde sich ein 
Schieberegister anbieten, dass du seriell, bzw 8-Bit paralell 
beschreibst, und 32Bit paralell wieder ausliest, wenn es voll ist. (Also 
nach 32 Takten im seriellen Fall und nach 4 Takten im 8-Bit seriellen 
Fall). Du musst nur darauf achten, dass du während du ausliest nicht 
schon neue Daten hineinschreibst. (Vielleicht nimmt man 2 Register und 
schaltet immer von einem zum anderen - bzw. während du eines liest 
schreibst du inzwischen ins andere und umgekehrt).

Im 10 Bit Fall brauchst du dann ein (bzw im Wechselfall 2) 160 Bit 
breite/s Register (kgV von 10 und 32), die du dann 10 Bit parallel 
kammartig beschreibst (das erste Bit für jeden Ausgang) und 32 Bit 
parallel ausliest.

Mit nem FIFO Puffer ist die Sache natürlich auch möglich, wenn dein FIFO 
Generator unterschiedliche Breiten für Ein- und Ausgang hinbekommt. 
Vielleicht ists mit dieser Art zirkulärem Buffer sogar eleganter. (man 
erspaar sich damit das 2te Register) Das EMPTY flag muss dann eben immer 
gesetzt sein, wenn weniger als 32 Bit im Puffer sind. Und wenn weniger 
als 32 Bit im Puffer sind, wartest du mit dem Auslesen und Abspeichern 
der nächsten 32 Bit bis >= 32 Bit vorhanden sind. Im 10 Bit Fall wird 
die Sache dann wieder etwas umständlicher - aber ich denke sowieso 
nicht, dass der Sensor die Daten auf diese Weise hergibt. Meine 
Glaskugel prophezeit eine 8 Bit parallele Ausgabe - möglicher Weise auch 
eine rein serielle Ausgabe vom Sensor.

Liebe grüße : .Franky.

Autor: FPGA_Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi .Franky.,
mein Sensor liefert Daten parallel, also 8 bit (in Wirklichkeit 10 bit, 
zur Vereinfachung 8 Bit) pro Ausgang pro Takt. Denn er ist ein High 
Speed Bildsensor von der Firma Micron. 500 fps schafft er.

Autor: .Franky. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also in dem Fall bekommst du die Daten schneller, als du sie abspeichern 
kannst.

Die Daten kommen mit 66MHz * 80 Bit = 5,28 GBit/s
Die Speicherrate ist 133MHz * 32 Bit = 4,256 GBit/s

Abgesehen mal davon... Du hast in einer Sekunde dann 660MB an Daten... 
Dein Speicher ist je nach Größe in wenigen Sekunden voll. Aber ok, für 
eine kurze Aufnahme reichts vielleicht...

Um auf max. 4,256GBit/s zu kommen, musst du entweder auf 2 Kanäle 
verzichten :
66MHz * 64 Bit = 4,224GBit/s

oder auf 2 Bit / Kanal verzichten :
66MHz * 60 Bit = 3,96GBit/s

Die andere Möglichkeit ist, dass du dir einen zweiten DDR2 Controller 
mit entsprechendem Speicher dran nimmst, der z.B. 5 von den 10 Kanälen 
übernimmt.

Anders gehts wohl nicht, weil der FPGA nicht genug Kapazität hat, um 
derartige Datenmengen zu puffern.

Ich denke 2 Controller, einer für 4 und einer für 6 Kanäle und 
entsprechende zirkuläre Puffer - wie oben beschrieben - für jeden 
sollten das Problem lösen.

Liebe Grüße : .Franky.

Autor: FPGA_Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi .Franky.,
dann kann ich den Sensor wohl nicht in seinem Grenzbereich, also mit 
einem Takt von 66 MHz betreiben. Ursrpünglich liefert er 10 bit/Ausgang, 
wurde aber auf 8Bit/Ausgang reduziert. Jetzt nochmal reduzieren? Lieber 
nicht, oder? :-)

Danke .Franky.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was soll denn nachher mit den Daten passieren? Nur einfach eine gewisse 
Zeit in den SDRAM speichern und später bearbeiten? Oder müssen die 
irgendwie live weggestreamt werden? Letzteres dürfte ja keum möglich 
sein. Bei ersterem würde ich die Daten so wie sie kommen in mehrere 
RAM-Chips schießen, ohne FIFO oder sonstwas dazwischen. Da musst du halt 
mehrere DDR-Controller mit mehreren Chips nehmen. Wie Franky schon 
schrieb. Anders bekommst du die Datenmenge nicht weg. Hat denn der 
Sensor 80 wirklich parallele Ausgänge, oder wie ist das zu verstehen? 
Wenn du 64 davon benutzt, kommst du mit den 66MHz x 64 Bit am Sensor 
genau auf deine 133Mhz x 32 Bit am Speicher-Controller. Musst halt dann 
immer die Daten umschalten. Aber du hast dann allerdings eben nur ein 
Viertel der Auflösung dann. Vielleicht verschwinden ja die unteren 2 Bit 
eh im Rauschen, dann gehts :)

Autor: FPGA_Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Daten werden erst in SDRAM gespeichert. Und irgendwann (ich weiss 
noch nicht wann :-) bevor der Speicher voll ist, müssen die Daten 
wegspeichert werden, in meinem Fall in den PC. Der Sensor liefert Daten 
wirklich parallel (laut Datenblatt 10bit/Ausgang/Takt, 10 Ausgänge hat 
er).

Autor: .Franky. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um welchen Sensortyp handelt es sich genau ? Hast du vielleicht ein 
Datenblatt ? Du schreibst du willst die Daten irgentwann mal auf den PC 
spielen... Der interne Speicher ist aber bereits nach wenigen Sekunden 
erschöpft, und in Echtzeit lassen sich die Daten auch nicht so einfach 
auf den PC übertragen. Welche Applikation hast du denn genau ins Auge 
gefasst - sprich was genau hast du vor ?

Liebe Grüße : .Franky.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, eine Live-Anwendung geht ja sowieso nicht, so schnell bekommst du 
die Daten auf keinen Fall in den PC. Du müsstest für eine sichere 
Datenübertragung mit etwas Protokoll mindestens 1,5 besser 2 mal so 
schnell sein, wie die Abtastung. Dazu kommt noch, dass du nicht 
gleichzeitig lesend und schreibend auf den SDRAM zugreifen kannst. 
Vielleicht solltest du dann doch riesige FIFO-Speicher verwenden, die du 
vom Sensor aus vollschreibst und auf der anderen Seite per USB, 
FireWire, GBitEthernet usw ausliest. Das Schreiben wird halt immer dann 
freigegeben, wenn der FIFO nicht voll ist, dann verlierst du zwar jede 
Menge Frames, weil du ja nicht so schnell auslesen kannst, aber damit 
kannst du einen konstanten Datenstrom mit der Geschwindigkeit des 
PC-Interfaces erzeugen.
Oder geht es darum, ein paar Sekunden aufzunehmen, dann an den PC 
übertragen und dann wieder ein paar Sekunden aufzunehmen? Für 
Live-Übertragung ist der Sensor mit der Geschwindigkeit ja eh nicht 
geeignet. Da bräuchte man ja einen 10 Gibt/s Uplink zum PC.

Autor: Andreas Fischer (chefdesigner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du müsstest für eine sichere Datenübertragung mit etwas Protokoll
>mindestens 1,5 besser 2 mal so schnell sein, wie die Abtastung.

Wer sagt denn sowas? Gerade ein Streaming von und zu einem DDR2 kommt 
mit sehr wenig overhead aus. Zudem ist das nur Latenz. Mit einem 
stinkigen PCI66 kann man typische Grafikbilder in Echtzeit 
transporiteren und einschreibeiben.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, mit PCI oder einem anderen internen Interface geht das sicherlich 
ohne viel Overhead. Ich war jetzt erst mal von einem externen Interface 
wie FireWire USB oder Ethernet ausgegangen.

@ FPGA_Neuling: Wie ist denn der geplante Anwendungszweck? Streaming 
oder immer eine "Messung" machen und dann übertragen, dann die nächste 
"Messung"?

Autor: FPGA_Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist so geplant, dass die Aufnahmedauer nur 1 Sek. beträgt.Die in 
SDRAM gespeicherten Daten werden über Ethernet-Schnittstelle in den PC 
übertragen. Es wird also nicht live übertragen. :-)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, na dann ist die Sache einfach.

Autor: FPGA_Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfacher würde ich sagen. Einfach ist die Sache für mich nicht :-)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, naja, Ahnung von Schaltungsdesign und FPGA-Beschreibung sollte man 
schon haben. Aber das Problem ist überschaubar. Wie oben geschrieben 
kannst du, wenn du jeden Kanal auf die oberen 8 Bit reduzierst, die 
Daten direkt in den SDRAM schreiben. Musst bloß bei jedem Takt die 
Datenquelle umschalten, weil der Sensor ja mit 66MHz läuft, der 
Speicher-Controller mit 133. Ist aber in VHDL kaum der Rede wert.

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.