Hallo! Vorab: ich habe noch keinerlei praktische Erfahrung mit FPGA-Entwicklung. Aber ich habe ein Problem, das möglicherweise nicht anders zu lösen ist. Es geht um Echtzeit-Videoverarbeitung. Prinzipiell müssen für jedes Pixel eines hereinkommenden Videostroms mehrere Speicherzugriffe erfolgen (Größenordnung ~10 Zugriffe, die mehr oder weniger zufällig über den Adressraum verteilt sind, wobei jeweils 24 oder 32 Bits gelesen werden). Bei hohen Auflösungen und Bildraten (z.B. Full HD mit 50 Hz) ist das, so wie ich das sehe, mit einem einzigen Speichermodul nicht machbar, weil es die Daten nicht schnell genug lesen könnte. Also habe ich mir überlegt, mehrere Speichermodule parallel zu betreiben, die jeweils denselben Inhalt haben. Alle 10 Speicherzugriffe könnten dann parallel erfolgen. Klingt das sinnvoll/machbar? Gibt es Alternativen? Worauf muss man achten, wenn man ein FPGA auswählt, damit so etwas möglich ist? Vielen Dank für Eure Ratschläge! Arnold
Bevor du dir solch einen Krampf mit mehrern Speichermodulen machst die dasselbe beinhalten würde ich mich nach schnelleren Speichermodulen umsehen. Du könntest bsw. zu beginn von einem Flash Speicher in einen DDR-RAM kopieren und dann auf dem DDR-RAM arbeiten. Der dürfte schnell genug sein.
Also ich komme da auf ca. 4 GB pro Sekunde ... könnte mit DDR2/DDR3 machbar sein. Aber schaffe ich es überhaupt, ein FPGA mit so hohem Takt zu betreiben?
Der Takt des FPGA muss gar nicht so hoch sein, die meisten Leistungsstärkeren FPGA besitzen spezielle Transceiver Blöcke um DDR-RAMS auszulesen. Da gehen bsi zu 25Gbit/s (bsw. Virtex 7 von Xilinx). Musst du in den Datenblättern des FPGA nachsehen. Wird aber aller wahrscheinlichkeit nach nur in den Devices der Mid-range Klasse (bei Altera bsw. der Arria V (GX and GT) und Kintex-7 bei Xilinx) oder sogar nur in der High-End Klasse (bei Altera Stratix II/III/IV/V und Virtex-7 bei Xilinx)
Die von mir gennanten FPGA's sollen nur als Beispiele dienen. Gibt bestimmt auch kleinere FPGA's die Transceiver Blöcke mit der benötigten Geschwindigkeit aufweisen. muss man sich halt mal bei Altera/Xilinx/Lattice umsehen, dann wird man bestimmt fündig.
du hast nen bandbreitenbedarf von 40Gbit/s, bei einem 64bittigen interface sind das dann ca 500MHz, dazu brauchst du aber keine 25Gbit/s transreceiver, sondern nur ein normales ddr2/3 interface
Wie wärs erstmal das Problem anzugehen? >> Prinzipiell >> müssen für jedes Pixel eines hereinkommenden Videostroms mehrere >> Speicherzugriffe erfolgen Das macht schon rein logisch keinen Sinn. Warum sollte das zwingend nötig sein? Selbst wenn du mehrere Postprocessing Stufen hast ist das mit 95%iger Warscheinlichkeit nicht nötig. Denk drüber nach wie du lokale Blöcke bearbeiten kannst und gut. 32 GBIT für 50 HZ Full HD ist ja wohl Overkill. Vor allem weil der Speicherbedarf wohl nur bei 8Mbyte(event. Double Buffered bei 16 Mbyte) liegt. Ich sehe da eher Latenzprobleme beim DDR... denk auch mal über ZBT SRAM nach. Mit 64(72)Bit * 300 MHz sollte man da ggf besser hinkommen.
hallo, am besten du gehst mal zu einem distributor und erzählst ihm mal was du machen willst und der kann dir dann vlt. weiter helfen
Überlege dir ob du den wahlfreien Zugriff auf einzelne Pixel des Bildes wirklich benötigst. Denn falls ja wird das wirklich nicht einfach auch nicht mit DDR2/3 SDRAM, bzw. besonders nicht mit diesem RAM Typ. Denn DDR SDRAM ist nur schnell wenn du ganze Datenblöcke liest und scheibst. Je weiterentwickelter der DDR SDRAM ist, also DDR -> DDR2 -> DDR3, desto größer muß das Ratio der Datenblock Länge zu Datenblockanzahl werden. In meinem LED Wand Projekt (HDMI 4096×2160p24) mussten die Pixel des Streams um 90 Grad rotiert werden. Dh. aus einem Zeilenweisen Bild muß die LED Wand als spaltenweises Bild rausgesendet werden und das noch in Pixel-Kacheln a 8x16 Pixel umgruppiert werden. Ich habe das mit einem FIFO gleich am DVI/HDMI Eingangscore erschlagen. Diesen benötigst du sowieso um die Taktdomaine des DVI/HDMI Signales mit der Taktdomaine des internen Controllers (auch Speichercontrollers, läuft nur mit 166Mhz) anzupassen. Dieser FIFO ist als langes RAM-Shiftregister mit Taps aufbebaut. Somit habe ich das Pixelprozessing pipelined und sequentiell direkt im Eingangsstream eingebaut. Dieses "FIFO" arbeitet Zeilenweise am Input und gruppiert jeden 8'ten Pixel so um das wir 8 Pixel pro Gruppe am Ausgang haben. Ich habe also am Ausgang 8 Pixel die später auf der LED Wand senkrecht untereinander stehen und somit sequentiell aus dem SDRAM gelsen werden können (als Blöcke). Defakto also eine 90 Grad Rotation des Bildes aber in kleinere Segemente zerteilt. Im externen DDR2 SDRAM liegen dann die Pixel des Bildes schon in Blöcke zerlegt an festen Adressen. Also intern wird das Eingangsbild immer auf virtuelle 4096×2160 umgerechnet (fehlende Pixel sind schwarz). Der Speichercontroller benutzt dabei ein Tripple Buffering, dh. ein Speicherbereich wird durch den DVI/HDMI Eingangscontroller geschrieben, ein weiterer Buffer wird für die Ausgabe gelesen und ein dritter Buffer steht als nächster freier Buffer zur Verfügung. Mit dieser Methode baust du die sogenannte Frameraten Anpassung vom DVI Eingang zum Ausgang bei mir die LED Wand. Parallel zu den zu lesenden Pixeln kann im SDRAM eine Tabelle für die Helligkeitskorrektur jedes Pixel in RGB hinterlegt werden (Dotcorrection 48Bit). Werden die Pixel ausgegeben so stehen sie im 24Bit RGB Format zur Verfügung. Sie werden dann erstmal über einen FIFO an die Taktdomain von 166MHz intern aus X MHz extern für den LED Wand Controller zwischengespeichert. Danach mit Hilfe von drei Gammatabellen (RGB) von 24 Bit nach 48 Bit gewandelt (die LED Wand hat 48Bit Farbtiefe mit einem Set von 24Bit gleichzeitig darstellbaren Farben). Nach dieser Wandlung erfolgt noch die Dotkorrection. Dazu wie gesagt wird für jeden Pixel ebenfalls aus dem SDRAM drei 16 Bit Werte geladen und mit dem 48Bit multipliziert. Erst danach wird ein Bitparelleler Datenstrom aus den LED Pixel erzeugt der mit 96 internen SerDes Cores mit max. 860MBit/sec pro SerDes rausgesendet werden. Nun lange Rede: ich behaupte das es sehr schwierig für dich als FPGA Anfänger wird nur annähernd an das ran zu kommen was du möchtest. Ich könnte es derzeit nicht, wenn du wirklich pro Pixel mehrfachen wahlfreien Zugriff benötigst und das alles innerhalb eines Frames, sprich als Echtzeit-Video-Prozessing. In meinem Projekt kommen wir pro Pixel auf 1 Schreib + 1 Lese + 2 Lese für Dotcorrection. Und das mit 166MHz = 333MHz DDR2 SDRAM. Dabei musste ich dem internen Speichercontroller sowohl für das Schreiben und Lesen mit FIFO Buffern arbeiten um die Daten in möglichst großen Blöcken zum DDR2 Controller schicken zu können. Das System ist bei 4096×2160p24 an seiner Grenze, ganz ohne weiteres Pixelprozessing. Mit DDR-SDRAM auf einzelne Pixel wahlfrei zugreifen zu wollen ist sinnfrei und geht auch garnicht so einfach. Man muß dann zB. das Maskregister benutzen und liest denoch für einen Pixdel quasi X Pixel Daten umsonst. Schau, wir haben einen externen 48Bit breiten DDR2-SDRAM angeschlossen. Daraus werden bei DDR2 also 96Bit und der Altera DDR2 Controller macht daraus 192Bit interne Datenbusbreite. 192Bit/24Bit=8. Wir schreiben/lesen in diesem Fall also immer 8 Pixel auf einmal, egal ob wir davon nur 1 Pixel real benötigen. Dein wahlfreier Pixelzugriff würde in dieser Konfiguration also 8 mal mehr lesen und schreiben müssen als du eigentlich benötigst. Du bist 8 mal langsammer durch die DDR2 Technologie. Mal noch nicht die Latenzen des SDRAM Controlelrs in den Speicherchips mit eingerechnet, denn das umswitchen von Commando zu Commando benötigt nochmals Zeit ebenso muß der SDRAM auch regelmäßig aufgfrischt werden (refresh), was ebenfalls Latenzen hat. Du solltest also deine Videobearbeitungsfunktionen alle so aufbauen das sie mit dem sequentiellen Stream arbeiten können. Deren Output in interne FIFOs schreiben und diese dann Blockweise zum DDR2 Controller Core senden/lesen. Ich habe auf einem Altera CycloneIII(120) entwickelt. Gruß Hagen
Hagen Re schrieb: > Du solltest also deine Videobearbeitungsfunktionen alle so aufbauen das > sie mit dem sequentiellen Stream arbeiten können. Vergessen: das oben gesagte ist die eigentliche Herausforderung. Nämlich deine Videofilter so zu konstruieren das sie sequentiell und damit oft pipelined arbeiten können. Dazu benötigst du einen FPGA mit viel internem BRAM + DSP Blöcken. Im Idealfall benötigst du dann garkeinen ext. RAM mehr. Gruß Hagen
Naja, mir ist keine HDMI App bekannt, wo man alles im BRAM hatte halten können. Die FPGAs die dort zum einsatz kommen, haben ja auch noch andere Aufgaben, als nur Bildlein verwursten,
sprach ja auch vom Idealfall ;) Zb. einfache Videofilter die nur Buffer für eine kleine Anzahl von Bildzeilen benötigen.
Wäre denn der Cyclone befähigt, auch einen DDR3 zu treiben? 333 MHz sind ja da garnichts.
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.