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