Hallo Zusammen, ich stehe gerade vor der Aufgabe, eine konfigurierbare Anzahl von Videoframes (2-10) mit 2 ppc und 8bit pro Farbe und konfigurierbarer Auflösung in externem RAM mit AXI4 Interface abzulegen und wieder auszulesen. Nun grüble ich darüber, wie ich das am Besten angehe - da ich hier gerade keinen Sparringspartner habe, wollte ich euch fragen ;) Zuerst geht's darum, in den RAM zu schreiben. Da der RAM da ist und zzt für nichts anderes gebraucht wird, muss die Umsetzung nicht 100% Effizient sein, aber "sinnvoll" sollte es schon sein. Im Moment gehen meine Überlegungen dahin, einen double-buffer im BRAM zu bauen, der die 48Bit+TLAST mit der Tiefe von einem AXI4 Burst (bspw. 128) speichert und dann mit einem Schwung in den externen RAM schreibt. Das würde so lange passieren, bis das nächste SOF mit TUSER kommt, um dann auf die nächste Startadresse zu wechseln. Wenn der Burst während eines Wechsels zum nächste Frame kommt, könnte Null-Bytes geschrieben werden. Ich habe nicht viel Erfahrung mit AXI4, von daher: klingt das für euch sinnvoll? Würdet Ihr da ggf. anders herangehen? Ich wäre für jeden Hinweis dankbar! Viele Grüße Achim
Welchen FPGA magst du verwenden? Falls du im Xilinx Oekosystem unterwegs bist, dann ist der Xilinx VDMA das was du suchst: https://www.xilinx.com/products/intellectual-property/axi_video_dma.html
Alternativ auch die Video Frame Buffer: https://www.xilinx.com/products/intellectual-property/v-frmbuf.html Oder wenn du nur einnen großen FIFO brauchst und die Bilder nur zwischenspeichern willst, vllt auch den Virtual FIFO: https://www.xilinx.com/products/intellectual-property/axi_virtual_fifo_controller.html
Danke für euer Feedback! Meßprofi schrieb: > Solche Lösungen gibt es einige. Klingt nach UHD 4K? Ich wäre erstmal mit Full-HD zufrieden. Tobias B. schrieb: > Xilinx VDMA Samuel C. schrieb: > Video Frame Buffer Danke - ja, es wird eine Xilinx-Plattform. Die hauseigenen Lösungen mit FB-Write und VDMA kenne ich gut auch im praktischen Einsatz. Bei der neuen Aufgabe soll aber u.a. ein ROI "ausgeschnitten" werden und ggf. einzelne Pixel aus dem Bild gelesen und in der PL weiter verarbeitet werden. Das Auslesen wird in jedem Fall mit einer HDL-Lösung laufen, insofern macht es auch Sinn auf dem Weg die Daten wegzuschreiben. Ich habe habe nochmal nachgedacht - das TLAST/EOL mit zu speichern ist Unsinn. Bis Full-HD komme ich mit 6 BRAMs aus, wenn jeweils eine komplette Zeile gepuffert und anschließend per State Machine in den externen RAM wandert. Klingt das für euch sinnvoll? Viele Grüße Achim
Achim schrieb: > Klingt das für euch sinnvoll? Das kann man weder mit Ja noch mit Nein beantworten (zumindest ich nicht), da brauchts dann doch etwas mehr Infos was du genau machen moechtest, vll. mit einem kleinem Blockdiagramm deiner Processing Kette.
Achim schrieb: > Bis Full-HD komme ich mit 6 BRAMs aus, wenn jeweils eine > komplette Zeile gepuffert und anschließend per State Machine in den > externen RAM wandert. Klingt das für euch sinnvoll? Eigentlich macht man das bei Video möglichst on-the-fly, also alles in Echtzeit. Die Ausleitung in einen VDMA ist da allerdings problematisch, weil man nicht weiß, ob und wann der Ready ist, weil er auch von anderen, nicht näher bekannten Komponenten mitbenutzt werden kann ... ... was zur Folge hat, dass man buffer benötigt, um Totzeiten zu überwinden, die ausreichend tief sein müssen, um in beide Richtungen "pumpen" zu können... .. was wiederum zur Folge hat, dass man sie deutlich schneller lesen (können) muss, als sie beschrieben werden, um sie nicht überbordend groß werden zu lassen, ... ... was seinerseits wiederum zur Folge hat, dass das AXI-Zwischensystem immer mit erheblich höherer Bandbreite arbeiten muss, als der Videotakt ... ... was wiederum zur Folge hat, dass man auch auf der Video-Eingangsseite einen buffer braucht, sowie eine Taktrekonstruktion auf der Ausgangsseite, da der Eingangstakt verloren geht ... ... was wiederum zur Folge hat, dass die beiden buffer eine zusätzliche Latenz aufwerfen, alles zusammen mehr Platz und Kombinatorik zur Steuerung und Generation brauchen und insgesamt viel mehr Strom wegfressen ... ... was wiederum zur Folge hat, dass das System teuer, langsamer und größer wird. Bei Video sollte man auf AXI möglichst verzichten, Dynamik aus dem System herausnehmen und den Systemtakt auf den Datentakt abgleichen. Die Datenspeicherung - insbesondere bei gemeinsam genutzten Resourcen - sollte mit massivem timing erfolgen und die Zuleitung zu verarbeitenden Komponenten ereignisgesteuert erfolgen, sodass die eingehenden Daten den Takt vorgeben und nicht das verarbeitende System. Damit dies möglich ist, muss ein Ablaufsystem mit Prozessoren mindestens die doppelte dynamische Bandbreite haben, wie das liefernde System. Damit ergibt sich ein natürliches Limit für die Verarbeitung in asynchron laufenden Prozessorsystemen und die Lösung, manche Aufgaben besser direkt im FPGA zu machen. ... was wiederum zur Folge hat, dass man Leute, die mit AXI-Baukastensystemen und Prozessorsystemen groß geworden sind, erst einmal überzeugen muss, dass ihr Lösungsansatz unnötig umständlich ist, obwohl sie der Ansicht sind, dass in C alles einfacher ist ... ... was wiederum zur Folge hat, dass man die Systempartitionierung immer Ingenieuren überlassen muss und nicht Softwareentwicklern :-)
Jürgen S. schrieb: > Bei Video sollte man auf AXI möglichst verzichten Prinzipiell schreibst Du ja richtige Sachen, ich wollte nur mal nachfragen, ob Du den Unterschied zwischen AXI4, AXI4-Lite und AXI4-Stream kennst? Duke
Ja sicher und beim beim Video bezog ich mich auch durchaus auf Streaming. Vom Prinzip nach ist das zunächst kein Problem, wenn man das Protokoll mit dem Videotakt fährt, insbesondere, wenn man Cores einsetzt, die ein entsprechendes Interface vorgeben. Die Sache wird aber dann interessant, wenn Komponenten ins Spiel kommen, die nur deshalb als AXI ausgelegt wurden, weil sie für Multi-Access, z.B. CPUs vorgesehen sind, die nicht als streaming arbeiten sondern gepulst rechnen, also in strukturellen und zeitlichen Blöcken. Bei Video-Bearbeitung hat man das recht oft, um Kompatibilität zu Mehrkernsystemen im FPGA zu schaffen, oder weil die Art der Bearbeitung per Filter das nahelegt. Das impliziert in jedem Fall, dass alle Interfaces so ausgeführt sind, daß sie ausreichend Universalität für unterschiedliche timing- und Betriebsfälle mitbringen, die sich nicht beliebig downstrippen lässt. Selbst ausdrücklich als Streaming ausgelegte IFs kommen mit mehr overhead. Da sind mindestens zusätzliche FIFOs implementiert, um asynchrones Einschreiben auf Datenebene (Pulsbetrieb auf gleichem Takt) oder gar Domainwechsel mit unterschiedlichen Takten zu erlauben und immer hat es ein handshaking, das die Anforderung aufwirft, zusätzliche Protokollstrukturen zu implementieren. Damit bekommt man natürlich die Option, sich weniger um das Systemtiming kümmern zu müssen und man muss auch weniger Annahmen über das lowlevel-Protokoll machen. Praktisch poppen aber andere Probleme und Aufwände auf, die in den Systemen, die eben nicht mit Blockabfertigung arbeiten müss(t)en zu unnötigen Schwierigkeiten führen. Gerade das Involvieren von FIFOs und AXI-Umsetzern, stellt mitunter Timing-Limits in den Weg, über die man nicht mehr drüber kommt, es sei denn mit einem schnelleren Chip. Man muss sich also entscheiden, ob man "schnell etwas bauen" oder "etwas Schnelles bauen" will. Im günstigsten Fall bringt AXI kaum overhead, weil es ein reiner voll paralleler Streaming-Core ist, alles auf einem Systemtakt läuft und kein pulsierender Betrieb vorliegt, bzw. es keine unbekannte Zugriffsdynamik mehrerer Beteiligter gibt. Allerdings ließe sich ein solches System dann auch direkt hinschreiben. Im häufigeren Fall hat es aber Zugriffsdynamik und / oder der Core kann alles Mögliche mit allen erdenklichen Betriebsarten. Dann muss man sich entscheiden, ob man den vorgefertigen AXI-Filter-Block reinhaut und Senken und Quellen universell anschließt, dass jeder zu jedem Zeitpunkt beliebig arbeiten kann und die AXI-Struktur das im Betrieb löst, oder ob man solche Themen zur Designzeit abfängt, indem man sich ein kluges Timing des Systems überlegt. Video hat da mit seinen Schwarzphasen ja einige Optionen, die vorgeben, wann man wie und mit welcher Bandbreite die BRAMs aktualisieren kann, um flackerfrei und resourcensparend Graphen darzustellen.
:
Bearbeitet durch User
Jürgen S. schrieb: > Ja sicher und beim beim Video bezog ich mich auch durchaus auf > Streaming. Vom Prinzip nach ist das zunächst kein Problem, wenn man das > Protokoll mit dem Videotakt fährt, insbesondere, wenn man Cores > einsetzt, die ein entsprechendes Interface vorgeben. Genau. > Im günstigsten Fall bringt AXI kaum overhead, weil es ein reiner voll > paralleler Streaming-Core ist, alles auf einem Systemtakt läuft und kein > pulsierender Betrieb vorliegt, bzw. es keine unbekannte Zugriffsdynamik > mehrerer Beteiligter gibt. Darauf wollte ich hinaus. > Man muss sich also entscheiden, ob man "schnell etwas bauen" oder "etwas > Schnelles bauen" will. Solange die Komplexität im Rahmen bleibt (Video in -> Filter 1 -> Filter 2 -> Video out) würde ich AXI-Stream nicht verteufeln... Warum Achim das Bild unbedingt in einem externen RAM zwischenspeichern will, hat er uns (noch) nicht verraten... Duke
Duke Scarring schrieb: > Warum Achim das Bild unbedingt in einem externen RAM zwischenspeichern > will, hat er uns (noch) nicht verraten... In der Regel deshalb weil er mehrfach über das Bild drübergehen möchte, um es zu analysieren? Z.B. eine Helligkeitsanpassung, eine Farbkorrektur oder er sucht etwas im Bild. Da kommt man um eine Speicherung kaum herum. Oder kennt jemand einen FPGA, in den vollständige Bilder passen?
Messtechniker schrieb: > Oder kennt jemand einen FPGA, in den vollständige Bilder passen? Es gibt Xilinx FPGAs mit UltraRAM. Das sind "abgespeckte" BRAMs mit 288Kb Groesse. Wenn man ein paar nimmt und die Bilder klein genug sind, passen sie rein. ;-) https://www.xilinx.com/products/technology/memory.html#internalMemory Und es gibt mittlerweile auch Xilinx FPGAs mit HBM. Das ist praktisch externer DDR SDRAM im Chip (wenn ichs richtig verstanden habe). Sind allerdings den Virtex Ultrascale+ FPGA vorenthalten, also eher nix fuer den kleinen Geldbeutel: https://www.xilinx.com/products/silicon-devices/fpga/virtex-ultrascale-plus-hbm.html
Tobias B. schrieb: > Und es gibt mittlerweile auch Xilinx FPGAs mit HBM. Das ist praktisch > externer DDR SDRAM im Chip (wenn ichs richtig verstanden habe). In der Tat, die gibt es minimal mit 4GB. Da sollte über 1sec unkomprimiertes HD-Video 1080p60 reinpassen, wenn ich es richtig überschlagen habe. Von der realen Speicherbandbreite her (alle DDR4-Effekte und Beschränkungen der AXI-Matrix berücksichtig) könnte man gleichzeitig alle aktuellen RGB-Bildpunkte in 25 parallele RAM-Bereiche wegschreiben und gleichzeitig parallel mit 25 Verarbeitern wiederholen können, die Einzelpixel suchen und korrigieren. Alternativ könnte man sie zweimal gleichzeitig wegspeichern und parallel mit 2 Matchern jeweils 2 beliebige 5x5 Pixelgruppen aus irgendwelchen Bildern holen, um sie zu verarbeiten. Damit könnte man 4D-Matching betreiben. Mit Bezug zu dem Beitrag oben: Beitrag "Re: AXI4-Stream Video Framebuffer" kann man das DDR komplett weglassen, wenn man es on the fly macht - dann auch in einem ARTIX7. Übrigens kann auch der genug Videobandbreite, hat eben nur kein ausreichendes RAM. Da passen nur einige hundert Zeilen rein.
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.