AXI4-Stream Video Framebuffer

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

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

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.

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.