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

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

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

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

> 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 ......

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.

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.

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.

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

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.

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.

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.

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.

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.

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 :)

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).

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.

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.

>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.

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"?

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. :-)

Achso, na dann ist die Sache einfach.

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

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.