Hallo zusammen, ich stehe gerade vor dem Problem einen AD9888 (Baustein von Analog Devices) an einen Xilinx FPGA anzubinden. Bei dem AD9888 handelt es sich um ein analoges Display Interface für Computer VGA Signale. Also Wandlung vom analogen Ausgang der Graka auf 3 * 8 Bit (RGB Daten) . Die Anforderung besteht nun darin, dass ein Frame Capture bis hoch in Viedeo Format 1080p möglich sein muss. ( also keine Videosequenzen mit Motion-Detection untersuchen usw. ), sondern quasi SNAP-Shot Funktion mit sofortigem Pre-Processing durch den FPGA (ohne Zwischenspeichern im externen Ram) 1. Kann ein Xilinx Virtex II oder Spartan III ( z.B. 1000 er ) diese hohen Datenraten überhaupt verarbeiten ? Bitte sagt jetzt nicht schau ins Datenblatt. Es geht mir mehr um einen Tipp aus der Praxis von jemand, der mglw. schon mit der Verarbeitung von solchen hohen Datenraten zu tun hatten. 1080p heißt ca. max Pixeltakt von 150 MHz also im Klartext auf 3 Datenkanälen ( RGB ) kommen je 150 MByte / sec ??? 2. Falls das direkte einlesen in den FPGA nicht möglich ist, welche Technik wendet man in der Praxis am besten an ? Zwischenpuffern in S-RAM ? Eigentlich wollte ich mir die Kombination aus externem DDR RAM + Refresch Controller im FPGA nicht antun. Schon jetzt ein herzliches Danke schön für jeden Beitrag. Gruß vom Peter
Hallo zusammen, bin leider in meiner Fragestellung immer noch nicht so richtig weiter gekommen. Hat denn niemand einen Tipp oder evtl. einen guten Link. Bin leider selbst nach intensivem Suchen noch nicht richtig weiter gekommen. Gruß vom Peter
Hallo Peter, das Problem ist wohl hauptsächlich, dass niemand so genau versteht, was du willst. Ein Takt von 150 MHz ist mit den genannten FPGAs prinzipiell möglich, wenn die Logik nicht allzu komplex ist. Mir ist allerdings nicht klar, wie oder wo du das Ergebnis speichern willst. Externes RAM kommt bei der Geschwindigkeit sicher nicht in Frage - es sei denn, du komprimierst im FPGA mit einem relativ simplen Algorithmus (wenig Logik!...). Der interne Speicher der FPGAs kann auch mit 150 MHz gelesen und geschrieben werden. Aber der liegt in der Größenordnung von 10 bis wenige 100 kB - genügt also wahrscheinlich nicht für ein ganzes unkomprimiertes Bild (Video-Format 1080 sagt mir nix). Mehr kann ich nicht sagen, da ich nicht weiß, was Ziel des Einlesens ist. Gruß, Thomas
Die Frage ist wo sollen die Daten hin und was willst du überhaupt mit den Daten machen. Selbst wenn du ein Preprocessing machen willst, irgendwo müssen die Daten dann doch gespeichert werden. Der interne Ram wird da bei weitem nicht ausreichen. Videoformat 1080p sagt mir überhaupt nichts. Beschreib doch einfach was genau du erreichen willst und wozu das ganze gut sein soll. Gruß Tobias
Hallo zusammen, sorry ich hab wesentliche Details vergessen zu erwähnen. 1. Videoformat 1080P bedeutet in meinem Fall im Prinzip ein VGA Video-Signal, welches aus Rot, Grün, Blau, H-Sync und V-Sync Impulsen besteht. P steht für progressive d.h. es wird z.B. mit einer Bildwiederholfrequenz von 60 Hz immer ein ganzes Bild übertragen. Also 1980 Pixel breit und 1080 Pixel hoch. Das ganze 60 mal pro Sec. Zum Vergleich DVD Auflösung hat gewöhnlich 720*576 dies nennt man dann 576p 2. Daten-Senke Die Daten sollen über den PCI Bus in einen PC übertragen. Das ganze soll also im Entwurfs-Stadium als Einsteckkarte für den PC aufgebaut werden. ( z.B. Raggedstone Spartan 3 Karte von Enterpoint ) Die PCI Steuerung usw. ist in der Entwurfs-Phase nicht so problematisch, weil die Karte zunächst unter WIN98, WINME laufen wird und ein direkter Zugriff auf die IO Konfig Adresse möglich ist. Es wird also kein Kernel Treiber benötigt. Die Transferrate über den PCI Bus wird ca. 12 MByte / sec betragen, was bei 4 Byte je Zugriff den Bus nicht sehr belastet. ( Für WIN XP usw. wird dann später ein Kernel Treiber geschrieben, der MEM Zugriffe im Burst Modus erlaubt. ) 3. Design Die Architektur soll Pipelined ohne Frame Zwischenpuffer Speicher entworfen werden. Ablauf: A. Einlesen von 8 Zeilen R, G, B Bild-Daten Es werden dafür ca. 2000 Spalten-Pixel * 8 Zeilen eingelesen und im Block-Ram des FPGA gepuffert. B. Nun werden die Makroblöcke von je 8 * 8 Pixel DCT transformiert. ( Diskrete Kosinus Transformation ) ( Die 18 bzw. 24 internen multiplizierer des xilinx Spartan werden natürlich voll ausgenutzt ) c. Während der Makroblock kodiert wird werden gleichzeitig die nächsten 64 Pixel vom AD Wandler eingelesen usw. d. Der kodierte Makroblock wird quantisiert, huffman codiert , lauflängen codiert und über den PCI Bus an den PC übertragen. e. Es erfolgt also eine quasi JPEG ähnliche codierung. Mein Problem besteht eben in folgender Fragestellung: Der AD-Wandler generiert einen eigenen Takt je nach Framrate des Video Signals z.B. ( 1024 768 75 Hz ) Dieser Takt muss als Takt synchroner Takt für das einlesen der Bild Daten für das FPGA dienen. Dieser Takt ist wie gesagt sehr hoch. Sobald die Daten in das Block-Ram geschrieben wurden, werden Sie an die Addierer und Multiplizierer mit einem festen Rechenschema übergeben. Der Takt für diese Rechenoperationen kann weit niedriger sein. Wie spreche ich also den Block-Ram mit 2 verschiedenen Takt-Frequenzen an ??? Oder mach ich mir ein Problem wo keines ist ? Gruß vom Peter
Ja, das hier ist kein Problem, da du ja auf Dual Port RAM zurückgreifen kannst. Dieses hat für jeden Port auch einen extra Clock Eingang. Natürlich musst du überprüfen, ob dein Block Ram groß genug ist für den 8 Zeilen Block, und solltest dann mehrere (min. 2) Block Rams benutzen, so dass immer auf ein anderes geschrieben wird, und vom anderen die Daten wieder ausgelesen und wie von dir beschrieben transformiert werden können. Ich denke auch 150Mhz dürften mit dem Sparten 3 gerade noch so machbar sein. Ich würde es trotzdem vorsichtshalber einfach mal vorher simulieren. Ist ja nicht so schwer mal eben ein File zu schreiben, in dem 24Bit eingelesen werden und sofort an ein Block Ram übergeben werden. Dann die maximale Taktrate nachsehen.
Hallo, Peter im Prinzip ist das möglich... im Prinzip ;-) Am Eingang sollte halt ein großes FIFO (asynchron) sein, wo du mit einer Frequenz die Datein reinschreibst und mit der anderen ausliest. Danach willst Du aber DCM-Transformieren und da ist ein Problem. Rechne genau aus, wieviele Takte wofür Du brauchst. Ich habe das schon mal ausgerechnet und kann mich erinnern, dass es sehr knapp war. Ohne Zwischenspeicher kannst Du es vergessen. Einfache Rechnung: 8 Zeilen * 1980 Pixel/Zeile 3 Farben min. 8 Bit = 371 kByte Dazu kommen aber dieverse Tabellen (Huffman, Eingangs-, Ausgangsfifo, sonstiges Zeug) und Du bist ganz schön beim Anschlag. (keine Ahnung, was so ein Spartan 3 hat, aber bestimmt nicht sehr viel) SDRAM, DDRAM ist nicht schwer zu implementieren, und Du kommst nicht drumherum. SRAM ist simpel und schnell, Am besten Du spendierst einen Speicher Deinem Design. Deine Frage allgemein ist schwer zu beantworten, denn man muss schon ganze Menge Know-How besitzen, um es hinzubekommen. Mach Dir einfach mal richtig Gedanken, was Du machen möchtest, was wie lange dauern soll (darf) und dann siehst Du ja, ob 150 MHz (weis immer noch nicht, wie Du darauf gekommen bist) reichen oder nicht. Spontan würde ich behaupten, dass 150 MHz locker möglich sind, da musst Du aber sehr darauf achten, dass Dein Design pipelined ist. Stell' mal konkrete Fragen, hier wird Dir sicherlich geholfen :-) Gruß Kest
Hallo Kest, danke für Deine Tipps und Dein Interesse. Thema: Block-Ram Also es ist meinerseits schon viel an Vorarbeit vorausgegangen, was ich so im einzelnen nicht geschrieben hab. Trivial ist das ganze natürlich nicht.. Lt. Spezifikation Xilinx hat ein Spartan 3 ( 1000er ) 432 KBit Block Ram und 120 KBit distributet Ram Spartan 3 ( 1500er ) 576 KBit Block Ram und 208 KBit distributet Ram Achtung: Bei Deiner Rechnung hat Du versehentlich Bits als Einheit berechnet und Bytes als Einheit im Ergebnis hingeschrieben. Also der Mindestblock der eingelesen werden muss bevor die Berechnung beginnen kann sind demnach ca. 371 KBits. Du hast natürlich trotzdem recht, dass das evtl. knapp werden könnte. Lt. meiner Nachfrage soll die raggedstone mit Spartan 3 1500 PCI Karte, (die ich zum testen verwenden will) von "enterpoint" nächste Woche wieder lieferbar sein. Wenn jemand eine Preis / Leistung vergleichbare PCI Karte kennt bitte, bitte posten. Lt. meiner Info werden größere FPGAs von der freien ISE von Xilinx sowieso nicht unterstützt. Theam: FIFO Eingangs-FiFo wird recht klein bemessen, weil ja die Daten eingangs-seitg synchron mit dem Takt des Video-Signals gelesen werden müssen. Der Ausgangs-FiFo wird dann halt so groß "wie noch übrig bleibt" gemacht werden. Je größer der Ausgangs-fifo desto besser kann eine kurzzeitige Lese-Unterbrechung vom PCI Bus (im mycro-sec Bereich) gepuffert werden. Ein Problem, (welches ich schon auf dem PC simuliert habe) ist ja die Tatsache, dass die Daten - über den PCI Bus ( ca. 12 MByte / sec ) gelesen, - in einen Stream vom Programm verpakt werden müssen - und über den PCI Bus auf die Platte gespeichert werden müssen. Also insgesamt ca. 25 MByte / sec übertragen werden müssen. Die theoretische Bandbreite besteht zwar bei ca. 33 MHz * 4 Byte aber das nur unter ganz bestimmten Vorraussetzungen, die ich dir warscheinlich nicht näher erklären muss. Das USER-Prog auf dem PC muss also einen ganz ausgeglichenen Zugriff auf dem PCI Bus erzeugen, der ständig einen Block 1024 Byte von der Karte liest und im Wechsel danach 1024 Byte in die Datei schreibt. Ein Ausgangs-Puffer von ca. 4000 Kbyte sollte reichen. (hoffentlich) Thema: SD-Ram Ich hab das auch schon sehr genau untersucht, bin aber immer wieder zu dem Ergebnis gekommen, dass das für mich als "Nicht-FPGA Profi" einfach zu schwierig ist. Ein SD-Ram Controller für meine Zwecke muss: - gleichzeitig Das SD-RAM regelmäßig refreshen - gleichzeitig Lesezugriff - gleichzeitig Schreibzugriff durchführen Wenn Du bedenkst dass die Daten mit ca. 150 Mhz eingelesen werden müssen und immerhin noch mit ca. 50Mhz ausgelesen werden müssen ... Das ganze müßte dann quasi als Dual-Port Ram contoller implementiert werden. Aufgrund der Pipelined Strukur für die Berechnung der DCT sind keine Wait-States möglich. ( Für mich viiiiiel zu schwer ) Thema: 150 MHz Die 150 Mhz scheinen zunächst total übertrieben, weil selbst HDTV eigentlich keine solche Bandbreiten produziert. Aber nur auf den ersten Blick. Bei 1080p werden ja z.B. bei europäischer Norm 50Hz übertragen. Also 50 Halbbilder. Obwohl die meisten Filme eigentlich nur 24 Vollbilder/sec bzw. 25 Vollbilder/sec haben. Aufgrund der Nachleuchtproblematik der Röhren werden also einfach 2 Bilder mit gleichem Inhalt nacheinader übertragen. Damit ist die übertragene Bildinformation zwar gleich geblieben, aber die Bandbreite hat sich glatt verdoppelt. D.h. einfach ausgedrückt der Pixeltakt hat sich dadurch verdoppelt. Wenn man bedenkt, dass die meisten PC Monitore nur mit 60Hz arbeiten, dann ist die Bandbreite nochmals etwas höher. 1. Lösung: Bandbreiten Problematik Der AD-Wandler kann bei zwei aufeinanderfolgenden Bildern immer nur jedes 2. Pixel Sampeln. Also beim ersten Bild das 1. 3. 5. und beim zweiten Bild ( hoffentlich gleichen Inhalts ) das. 2. 4. 6. usw. Achtung: Das hat jedoch nichts mit dem Interleaced Verfahren zu tun. Interleaced beschreibt die Übertragung von Halb-Bildern wobei immer ganze vollständige Zeile übertragen werden. 2. Lösung: Bandbreiten Problematik ( von mir angestrebt ) Das FPGA erhält zwar die Daten mit voller Bandbreite. Verwirft aber jedes 2. Bild vollständig. Also Intern soll maximal mit ca. 60 MHz gearbeitet werden. Thema: DCT ( überschlägige Betrachtungsweise ) Wie Du bestimmt auch weißt gibt es verschiedene optimierte Verfahren für die Berechnung der DCT. Im allgemeinen kommt man auf - ca 80 Multiplikationen und je nach Verfahren - und zusätzlich ca. 400 Additionen für einen 8 * 8 Pixelblock. Beispiel: Wenn der FPGA mit ca. 40 bis 50 Mhz für das DCT Rechen-Schema getaktet wird ( das ist in etwa mein Ziel ) Dann müssen eben diese 80 mul + 400 Add in ca. 50 Takten erledigt werden. ( Im Falle von HDTV, also höchste Anforderung !!! ) Es gibt da bereits einen von Xilinx erstellten IP-Core, den ich allerdings noch nicht genau analysiert habe. ( Zeit ??? ) Auf Opencores gibt es ebenfalls bereits eine IP-Core Implementierung. Im FPGA erzeugt man aufgrund der begrenzten Rechen genauigtkeit Rundungsfehler, welche aber akzeptiert werden müssen. Meine Simulationen haben ergeben, dass trotzdem hervorragende Ergebnisse im Bezug auf die Bildqualität zu erreichen sind. Gruß vom Peter
Kurze Korrektur um nicht zu verwirren: Es muss korrekt heißen: Bei 1080p werden ja z.B. bei europäischer Norm 50Hz übertragen. Also 50 Vollbilder. Obwohl die meisten Filme eigentlich nur 24 Vollbilder / sec bzw. 25 Vollbilder/sec haben.
Hallo, Peter ja, sorry, habe mich verrechnet mit Bytes und Bits. Ist ja ganz spannend, was Du so machst :-) Nun, mein Senf dazu: zu Xilinx und großen FPGAs - ja, das stimmt. Mit 6.3er Version konnte man nach der Installation des Service Packs bis 3s5000 gehen :-o Das nur so, als Fallback. Aber ich denke, ein 1000er oder 1500er wird ausreichen (abgesehen vom Speicher). Den ext. Speicher kann man ja in beliebiger Breite ausführen, z.B. 64 oder gar 128 Bit, damit steigt der Durchsatz. Die SDRAM-Controller übernehmen für Dich alles (Refresh und so). Vor dem SDRAM und nach dem SDRAM ist ein FIFO. Das ist einfacher, als Du denkst: eine Statemachine steuert die Zugriffe - ist das Eingangsfifo voll (oder zumindest genug DAten für einen Burst), wird geschrieben; ist das Ausgangsfifo fast leer - soll ein Burst gelesen werden. Das war's. NAch Außen hin ist dann Dir egal, ob dahinter ein SDRAM, SRAM oder gar BLOCKRAM ist. Ich sage Dir aber, dass Du mit dem Blockram nicht weiterkommst (Du kannst mich aber anders überzeugen, wenn es fertig ist :-)) Du schreibst: "Ein Ausgangs-Puffer von ca. 4000 Kbyte sollte reichen." Verschrieben? ;-) Wie soll den PCI implementiert werden? Im FPGA oder mit einem Bridge-Controller (sorry, die Karte, die Du immer erwähnst sagt mir erstmal gar nichts) Du schreibst: "- ca 80 Multiplikationen und je nach Verfahren - und zusätzlich ca. 400 Additionen für einen 8 * 8 Pixelblock" Stimmt es??? :-o Mir war so, dass es 64 Multiplikationen waren. Aber auch egal. Was richtig hart wird, ist ohne externen RAM auszukommen. Denn wenn Du dann plötzlich auf die Speichergröße Grenze stößt, hast Du gleich verloren. Ich sage Dir, wie ich vorgehen würde, bzw. welche Fragen ich hätte: - wenn viele BRAMs benutzt werden, könnte es Probleme mit den Multiplizierern geben - sie sind ja nah am BRAM -> also eventuell GEschwindigkeitseinbruch, wenn bestimmte Grenze überschritten wird (es muss dann hin und her geroutet werden) - die ersten 8 ZEilen werden eingelesen und berechnet. WAs passiert in der Zeit? Wo gehen die Daten hin, die dann kommen? Wo sollen sie abgespeichert werden? - als erstes würde ich DCM optimieren und bis aufs letzte Takt alles ausrechnen - wie können Adresszeiger optimiert werden? Wie soll das FIFO aufgebaut werden? - eine "Kern"-Entity, wo 64 Werte (8 Bit) seriell reingehen, und dabei später seriell die Werte in der gleichen Reihenfolge rausschiebt wäre als nächstes dran. - dann würde ich mir den Kopf machen, wo ich Daten her nehme (aus dem externen oder int. Speicher). Die Pixel kommen ja nicht nacheinander (8x8 Blöcke), leider :-/ - dann... na ja, erstmal das... Also bevor ich da mich ans Hardware setze und mich entscheide, welche FPGAs passen, muss vieles "stehen". ... ich meine, was hindert Dich daran SDRAM oder SRAM dranzuhängen? Pins hast Du ja genug. Ich habe mal ein Design mit einem 3s4000 gemacht, da habe ich gleich 3 DDR-Controller hineingeroutet (2x64 und 1x32 Bit) Kest
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.