Guten Morgen. Ich hab momentan leichte Schwierigkeiten, mir das Richtige Ev. board von Xilinx auszuwählen. Folgendes möchte ich machen: Ich bekomme von einem uC, wahrscheinlich über RS-232 RGB-Bilder zugeschickt. Diese Bild-Daten möchte ich auf dem FPGA abspeichern, um Sie im FPGA mittels PAL-Encoder als FBAS Signal umzuwandlen. Das FBAS Signal wir anschließend über ein Video DAC an ein LCD Didplay mit Composite Anschluss gesendet. Mein Problem ist gerade, dass ich nun nicht genau weiß, welches Evaluation Board von Xilinx ich da nun verwenden muss. Ich gehe momentan davon aus, dass ich immer ein Bild abspeicher (max. 640x480). Die Auflösung steht noch nicht ganz fest. Das ist so meine Grundüberlegung. Vielleicht geht es ja auch etwas unkomplizierter!? Ich bin für jede Hilfe dankbar. Vielen Dank im Voraus.
So wie Du es erklärt hast, brauchst Du ein FPGA mit genug Speicher. Ich kenne mich bei Xilinx nicht gut aus. Aber Lattice hat da einige ganz nette im Angebot. Die ECP2/M. Was soll denn das geben?
Nimm doch einfach nen externen Ram. Ist auch weit billiger als sich nen stärkeren FPGA zu leisten. Noch dazu ist Speicher im FPGA ohnehin ein sehr beschränktes Gut. Noch dazu braucht deine Anwendung wahrscheinlich nicht besonders viel Ressourcen. Soweit ich weiß haben die meisten Evals ohnehin nen Ram mit drauf. Ach ja bei 640*480*3*8 Bit kommt schon ganz schön was zusammen.
Wie, "Was soll das denn geben?" Ich muss RGB in Composite umwandeln. Ich habe zwei Ansätze: 1. Encoder mittels FPGA erstellen 2. FPGA nur als Bildspeicher und mit nem IC den Encoder realisieren Bin quasi parallel auch auf der Suche nach IC's die einen RGB to Pal Encoder darstellen. Aber welcher ist der Richtige?! Gibts da eventuell einen Tip von einem Kenner? Veieln Dank für die Antwort
>FPGA nur als Bildspeicher und mit nem IC den Encoder realisieren Ach ich würd den FPGA gleich nur als Deko draufpappen.. Ne echt FPGAs sind auch weit günstiger als jeder Speicher. So manche billige Mp3 Player .. nein lassen wir das lieber ;)
> Wie, "Was soll das denn geben?" Ich muss RGB in Composite umwandeln. Ich Das Zauberwort heißt Colour Space Converter, dazu findest du was in der Xilinx App-Note 930, den mußt/solltest du mit nem FPGA machen. Bildspeicher mit externem RAM. Ein geeignetes Brett könnte das Spartan 3 A EvBoard sein (150 USD), das hat einen Riesen-SDRAM.
Die Wandlung YCrYCb zu FBAS mußt du dann noch mit einem externen Stein machen, die gibt es zuhauf bei AD, NXP, TI....
@berndg Wozu brauch ich denn den Colour Space Converter? Wenn ich RGB Daten habe, und diese dann an einen externen PAL-Encoder (der RGB als Input hat)sende , wozu brauch ich dann den Colour Space Converter???# Und schon einmal vielen Dank für die vielen und schnelle Antworten!!!
> Ich bekomme von einem uC, wahrscheinlich über RS-232 RGB-Bilder zugeschickt. Diese Bild-Daten möchte ich auf dem FPGA abspeichern, um Sie im FPGA mittels PAL-Encoder als FBAS Signal umzuwandlen. Hmm, sozusagen deine eigenen Worte. :-) Aber du hast völlig recht, du kannst den ganzen Prozess natürlich auch in RGB machen und am Ende mit einem geeigneten PAL-Encoder zu FBAS zurückwandeln. Mir ist jezt allerdings nicht geläufig, welcher Encoder RGB zu FBAS macht. Der SAA 7103 macht das, aber nur für 600 x 800 Bilder. Nachsehen.
Da gibt es wohl einige. Im welchem Speicher würde ich denn das Bild abspeichern??? Das FPGA besitz so einieg Speichergruppen. Ich hab mir mal das Datenbaltt vom Spartan 1600E angeschaut. Da steht: 64 MByte (512Mbit) of DDR SDRAM, x16 ata interface, 100+MHz Was bedeutet das alles überhaupt genau. Ziemlich verwirrend. Ich würde jetzt denke, das dieser Speicher zum Bild hoinzterlegen (sagen wir mal 640x320) ausreichen würde. Oder bin ihc einfach zu doof?!
Nimm einen externen RAM, der vom FPGA angesteuert wird, sonst wird die Sache zu aufwendig! Dann reicht auch ein kleiner FPGA zur Steuerung z.B. XC 3 S 200 oder max. XC 3 S 400, würde ich meinen.
Mit dem externen RAM habe ich auch schon überlegt gehabt. Das soll wohl aber etwas kompliziert sein. ICh werde aufjedenfall ein Xilinx Evaluation Board benutzen. Zur ZEit gibt es bei mir ein Spartan3, 3E und 1600E. WEnn die Bildauflösung doch noch höher sein muss wollte ich eventuell auf ein Virtex 4 oder 5 umsteien. Das enstcheidet sich aber erst in den kommenden zwei Wochen. Ich gehe aber ersteinmal von einer Bildauflösung 640x320 aus. Warum reicht den der SDRAM vom 1600E nicht aus???
Da hab ich jetzt was durcheinander gebracht :-( Nimm das 1600E, da ist genug Overkill drin :-). Gruß Bernd
>> Mit dem externen RAM habe ich auch schon überlegt gehabt. Das soll wohl >> aber etwas kompliziert sein. Nein ist es nicht, wenn du z.B. einen SPI Flash Speicher verwendest. Die Ansteuerung dafür zu coden kostet dich evtl ein Tag. Zu dem sind die IC's recht schnell (70 Mbit/s sind oft locker drin). Und so ein 32 MB SPI Flash kostet auch nicht die welt.
So, jetz hab ich für heute ersteinmal genug Info von euch bekommen. Jetzt werd ich mir noch ein zwei geeignete IC PAL Encoder auswhälen und mal schauen,wie das alles so zusammen passt. Vielen Dank ersteinmal für die tolle Hilfe.
Sieh mal bei Xilinx oder Silica nach, bei denen gibt es Video-Ansteckplatten für den Hirose-Steckverbinder am Board (Wenn dein Chef das Geld rausrückt).
Da es zu meiner Diplomarebit gehört, muss ic hda schon einiges an Arebit reinstecken. Aber trotzdem noch mal eine Frage.Oder auch zwei Es wurde ja im Forum schoeinmal über einen Tesbildgenerator gesprochen. Ähnlich ist meine Aufagbe ja auch. Ich bekomme von einem uC (Testbilder)Bilder und muss sie auf einem Display mit Composite Anschluss drastellen. Fest steht wohl, dass ich ein FPGA Spartan 1600E benutze und einen RGB-PAL Encoder (Bsp. MC1377). 1. Wie übertrage ich am betsen die Bilder vom uC auf das FPGA? 2. WEnn ich das FPGA als Bildspeicher verwende müssen die Daten ja an den IC geschickt werden. Welche übertragungsvariante verwende ich am betsen dafür?
> Warum reicht den der SDRAM vom 1600E nicht aus??? Wie wäre es mal mit einer einfachen Überschlagsrechnung: Auflösung 640x480=307200 Bildpunkte XC3S1600E hat intern 663552 Bit Blockram. Das reicht für ganze 2 Bit "Farbtiefe" pro Pixel. > SPI Pixeltakt 70 Mbit/s 307200 Bildpunkte 25x pro Sekunde wiederholen: 307200x25=7680000 mal pro Sekunde ein Pixel auslesen (Austastlücken u.ä. lasse ich mal großzügigerweise weg) Das würde für 8 Bit Farbtiefe reichen. Der SPI-Flash sollte allerdings noch groß genug sein. Du wirst also um ein FPGA mit externem Speicher nicht herumkommen. > 64 MByte (512Mbit) of DDR SDRAM Die kannst du dafür benutzen. Das ist ein einzelner RAM der an das FPGA angeschlossen ist. Einen passenden Controller kannst du dir mit dem MIG generieren lassen.
@ Lo Me > Da es zu meiner Diplomarebit gehört, muss ic hda schon einiges an Arebit > reinstecken. Aber trotzdem noch mal eine Frage.Oder auch zwei Welches Fach studierst du denn?
Ich arbeite auch mit FPGA & Video; allerdings empfange ich ein BT656 Videosignal von einem VideoADC. Um realistische Testbilder für die Simulation zu bekommen hab ich die Bilder aus der Kamera über den FPGA in einen SRAM (extern) geschrieben und dann als BMP durch die serielle Leitung gequetscht. Du könntest das ja umgekehrt machen. PC/µC sendet ein BMP an den FPGA, der decodiert es und legt es im SRAM ab. Wenn dieser Vorgang abgeschlossen ist, kannst Du das Bild einfach aus dem Speicher über den FPGA zum VideoDAC schicken. Als Hardware könntest Du das RetroComputingBaseboard von Trenz Elektronik nehmen. Bei uns sind das die Studenten-FPGA-Boards auf der Uni. Und der Preis ist auch nicht schlimm. Ich habe Privat das FPGA-Modul und ein Pinheaderboard. Also da ist zwar keine Peripherie drann dafür sind 4x40PinHeader drauf.
Wie wär's mit einem PAL-Encoder-Core? http://www.pcb-dev.com/index.php?option=com_content&task=view&id=16&Itemid=57 Solang es sich bei deiner Diplomarbeit um nicht-kommerzielle Nutzung handelt, kannst du den verwenden. Mfg Thomas Pototschnig
@Thomas Danke, aber ich denke mal, das das Projekt irgend wann mal kommerzialisiert wird. D.h. einfach dein Projket übernehemn geht also nicht. ICh wollte den PAL Encoder mittels IC (ev. MC1377) realisieren. Mit dem FPGA möchte ich die Bilddaten vom uC zwischen speichern. Jetzt mal ne Frage zu deinem Projekt. Wie bekommt dein Board die Bilddaten (RGB...?)? Worüber sendest du die Daten vom uC zum Graf.Board? DAnke
Da gibts verschiedene Möglichkeiten - entweder über SPI (was aber langsam und auf keinen Fall echtzeitfähig ist) oder man macht sich die Arbeit ein paralleles Interface zu implementieren, das in den Speicherbus eingebunden ist. Bei meiner Lösung gibt es 2 Busse mit max 30MB/s (immer 16Bit Daten!), wovon einer dafür verwendet wird die Bilddaten aus einem externen SRAM auszulesen, der Andere wird dafür verwendet um die Bilddaten ins SRAM zu schreiben. Das ganze wird von einer Speichersteuerung gesteuert, die dann das SRAM mit 60MB/s anspricht. Gibt also weder Wartezeiten, noch Konflikte beim Lesen/Schreiben. Die SPI-Schnittstelle sitzt nur davor und erzeugt 16Bit parallele Daten und gibt einen Schreibimpuls aus. Hier sieht man noch ein Blockschaltbild wie das aussieht: http://www.opencores.org/projects.cgi/web/graphiti/overview Mfg Thomas Pototschnig
Ok. Wenn ich das richtig verstehe, liest du in einem Speicher die Daten vom uC ein, schiebst sie an das nächste weiter um sie aus dem zweiten RAM wieder auszulesen??? Ich habe momentan einfach ein Problem, wie ich die Bilddaten, sagen wir mal RGB mit 640x320 Auflösung, am betsen vom uC zum FPGA (RAM) übertrage um sie anschlließen sinnvoll in einem RAM abzuspeichern. Muss ich wirklich jeden Pixel (640x320) für jeden Farbanteil, also 3x (R, G u. B)speichern? Oder gibt es da irgendwie eine Platzsparende möglichkeit???
Lo Me wrote: > Ok. Wenn ich das richtig verstehe, liest du in einem Speicher die Daten > vom uC ein, schiebst sie an das nächste weiter um sie aus dem zweiten > RAM wieder auszulesen??? Jo, ein Microcontroller wäre viel zu langsam soviel Bilddaten in echtzeit zur Verfügung zu stellen. Jede Grafikkarte hat doch auch einen Bildschirm-Speicher, das ist kein Unterschied ... > Ich habe momentan einfach ein Problem, wie ich die Bilddaten, sagen wir > mal RGB mit 640x320 Auflösung, am betsen vom uC zum FPGA (RAM) > übertrage um sie anschlließen sinnvoll in einem RAM abzuspeichern. > Muss ich wirklich jeden Pixel (640x320) für jeden Farbanteil, also 3x > (R, G u. B)speichern? Oder gibt es da irgendwie eine Platzsparende > möglichkeit??? Kommt drauf an was du für ein RGB-Format hast. Bei RGB 5:6:5 benötigst du 2Byte pro Pixel. Wenn es schnell gehen muss ist eine gute Lösung den FPGA in den Speicherbereich des Controllers einzubinden. So ist es ja auch bei jeder Grafikkarte beim PC ... Man kann über Speicheradressen auf den Bildschirmspeicher zugreifen. Mfg Thomas Pototschnig
Aber ich dachte ein FPGA selbst reicht für nen Bildspeicher nicht aus? Ich wollte das Ev. Board Spartan 1600E von Xilinx benutzen. Momentan sieht es so aus, dass ich die Bilddaten von einem uC bekomme. Die wollte ich dann auf dem Ev. Board ein einem SRAM zwischen speichern um sie dann, entweder über VGA-Schnittstelle des Boards wieder auszugeben oder an den IC PAL-Encoder weiter sende. Mit dem Abspeichern der Bilddaten würde ich in einem SRAM den notwendigen Speicherbereich, abhängig von der Auflösung, festlegen. Dann jedes Pixel und sein RGB Wert abspeichern. Dazu mal eine Frage: WEnn ich davon ausgehe, dass ich für jeden Farbraum (R,G u.B) 0...255 Bits , also 1Byte einplanen muss, d.h. bei einer Auflösung von 640x320 = 2.048.00 Bits plus die 3x256 bits für den RGB Farbraum, wie würde ich das denn am betsen abspeichern???
Lo Me wrote: > Aber ich dachte ein FPGA selbst reicht für nen Bildspeicher nicht aus? > Ich wollte das Ev. Board Spartan 1600E von Xilinx benutzen. Momentan > sieht es so aus, dass ich die Bilddaten von einem uC bekomme. Die wollte > ich dann auf dem Ev. Board ein einem SRAM zwischen speichern um sie > dann, entweder über VGA-Schnittstelle des Boards wieder auszugeben oder > an den IC PAL-Encoder weiter sende. Tut er auch nicht, bei mir ist das SRAM extern als zwei 512k*8 mit 10ns Zugriffszeit realisiert. > Mit dem Abspeichern der Bilddaten würde ich in einem SRAM den > notwendigen Speicherbereich, abhängig von der Auflösung, festlegen. Dann > jedes Pixel und sein RGB Wert abspeichern. Dazu mal eine Frage: WEnn ich > davon ausgehe, dass ich für jeden Farbraum (R,G u.B) 0...255 Bits , also > 1Byte einplanen muss, d.h. bei einer Auflösung von 640x320 = 2.048.00 > Bits plus die 3x256 bits für den RGB Farbraum, wie würde ich das denn am > betsen abspeichern??? Du verdrehst Bits und Bytes aber ganz schön ... Stell deine Frage bitte nochmal neu ;-)
SOrry, ok noch einmal. Also ich habe mir das so vorgestellt, dass ich den Speicherbereich je nach Auflösung festlege. Nehmen wir 640x320 Pixel an. D.h. ich hätte ein Register mit der Größe von 320 Zeilen und 640 Spalten. Für jedes Pixel muss ihc ja den jeweiligen Farbwert speichern. Keine Ahnung ob 5:6:5 oder...? Was ist den meistens so der Standard? Jetzt muss ich ja irgendwie meinen Farbwert Rot, Grün und Blau in den festgelegten Speicherbereich hinterlegen. Bedeutet das jetzt, dass ich für jeden Farbwert einen Speicherbereich von 640x320 festlegen muss?
Lo Me wrote: > SOrry, ok noch einmal. > Also ich habe mir das so vorgestellt, dass ich den Speicherbereich je > nach Auflösung festlege. Nehmen wir 640x320 Pixel an. D.h. ich hätte ein > Register mit der Größe von 320 Zeilen und 640 Spalten. Für jedes Pixel > muss ihc ja den jeweiligen Farbwert speichern. Keine Ahnung ob 5:6:5 > oder...? Was ist den meistens so der Standard? > Jetzt muss ich ja irgendwie meinen Farbwert Rot, Grün und Blau in den > festgelegten Speicherbereich hinterlegen. > Bedeutet das jetzt, dass ich für jeden Farbwert einen Speicherbereich > von 640x320 festlegen muss? Äääh ... 5:6:5 ist zB ein Standard für RGB16 bit ... rot:5bit, grün:6bit, blau:5bit. Wenn du 640x320 RGB 16bit hast, benötigst du 640*320*2Byte Speicherplatz. Mfg Thomas Pototschnig
Und wie würde ich die 640x320*2Byte am besten im SRAM speichern. Wie sieht denn bei dir die Speicherorganisation für die Bilddaten aus?
Lo Me wrote: > Und wie würde ich die 640x320*2Byte am besten im SRAM speichern. > Wie sieht denn bei dir die Speicherorganisation für die Bilddaten aus? Die Pixel hintereinander im RAM? Wie sonst?
>Und wie würde ich die 640x320*2Byte am besten im SRAM speichern. >Wie sieht denn bei dir die Speicherorganisation für die Bilddaten aus? Na am Besten verkehrt herum. Wenn du sie vorwärts einspeicherst, kannst sie hinter rückwärts besser auslesen.
Ja das weiß ich. Da habe ich mich wohl nicht richtig ausgedrückt.Ich habe ja für jedes Pixel 3 Farbwerte. Jeder Farbwert hat R=5Bit, G=6bit und Blau=5bit wenn wir eine Farbtiefe von 16 Bit habe. Richtig? In meiner Überlegung muss ich für jedes Pixel 16Bit speichern. Wenn ich nun auf meinem Evaluation Board nen 64 MByte (51Mbit) DDR SDRAM mit x16Data habe, hat jede Speicheradresse 16Bit? Würde ich dann in jede Adresse gemeinsam meine RGB WErte speichern??? ICh weiß, doof e Fragen, aber irgendwie stehe ich heute voll aufm Schlauch!!!
Lo Me wrote: > Aber ich dachte ein FPGA selbst reicht für nen Bildspeicher nicht aus? Davon gehe ich auch aus. > Ich wollte das Ev. Board Spartan 1600E von Xilinx benutzen. Momentan > sieht es so aus, dass ich die Bilddaten von einem uC bekomme. Wie bekommst Du Deine Bilddaten in den µC? erzeugt dieser die Bilder? Wenn der µC die Bilder erzeugt, dann kannst Du ja den µC im FPGA unterbringen. Für den VideoDAC wirst Du idealerweise BT656 verwenden. BT656 ist eine 4:2:2 Y+Cr/Y+Cb codierung. Also für 2 Pixel hast Du 2*8Bit Y Werte, einen Cr und einen Cb Wert mit je 8Bit. Wobei Du (meist) zwei verschiedene Busbreiten zur Auswahl hast: 8Bit: Y Cr Y Cb, Y Cr Y Cb, Y Cr Y Cb, .... 16Bit: Y Y Y Y Cr Cb Cr Cb .... Des weiteren hast Du AV-Codes im Datenstrom. 8Bit hat den Vorteil, weniger Leitungen zu benötigen wobei die DotClock bei 27Mhz ist , 16 Bit hingegen kommt mit 13,5 Mhz DotClock aus. Viele VideoADC können allerdings auch RGB, hier hast Du allerdinge im Allgemeinen einen höheren Speicherverbrauch. Und Du musst die SyncSignale extra aufbereiten (im BT656 können sie im Datenstrom eingebettet sein) > > Mit dem Abspeichern der Bilddaten würde ich in einem SRAM den > notwendigen Speicherbereich, abhängig von der Auflösung, festlegen. Dann > jedes Pixel und sein RGB Wert abspeichern. Dazu mal eine Frage: WEnn ich > davon ausgehe, dass ich für jeden Farbraum (R,G u.B) 0...255 Bits , also > 1Byte einplanen muss, d.h. bei einer Auflösung von 640x320 = 2.048.00 > Bits plus die 3x256 bits für den RGB Farbraum, wie würde ich das denn am > betsen abspeichern??? Wenn Du RGB abspeichern willst, würde ich BMP als Format wählen. Ein einfaches Format, das auch im Simulator leicht zu verifizieren (und dort auch einfach in ein File zu schreiben) ist.
Ehmm DDR ram ?? Bei deinem aktuellen kenntnisstand würde ich das stark bezweifeln dass du das angesteuert bekommst (macht auch nicht wirklich sinn für die Anwendung). Nimm ein asynchrones SRAM mit kleiner Zugriffszeit (10ns oder so). Ich befürchte aber fast du bist selbst mit dem Controller dafür (Zeitmultiplex lesen/schreiben wie oben erwähnt) schon überfordert... Und da es zu deiner Diplomarbeit gehört solltest du mal ein bisschen die Grundlagen recherchieren! (Farbformate, verschiedene Speicher, ..) Musst doch eh nen Grundlagen Kapitel schreiben ;)
@Gabriel Moin. ALso die Bilder sind auf dem uC hinterlegt. Hast du zufällig einen Video DAC im Kopf, der Y+Cr/Y+Cb als Inout besitzt? Ich hatte mir den MC1377 ausgewählt, der allerdings nur RGB Inout hat.
Vielleicht das ganze noch mal überdenken ob an der Stelle wirklich ein FPGA sinnvoll ist? Hast du noch irgendetwas anderes was von einem übernommen werden muß oder sinnvoll von ihm übernommen wird? Das ganze Bild im FPGA zu speichern ist nicht praktikabel, externer Speicher muß eh her. Wenn die Bilder von einem uC stammen und auch noch mittels RS232 übertragen werden ist deine Eingangsdatenraten doch ziemlich winzig. Der FPGA hat letztlich kaum was zu tun. Gerade bei deinem Kenntnisstand: Wie wäre es mit einer Lösung aus CPLD + SRAM + Video Encoder? (evt. noch + uC) Dein eigentliches Problem ist die Ausgangsdatenrate, dafür musst du aber im Grunde bloss die Adressen für das SRAM passend generieren. Da die Eingangsdaten auch nur langsam reinkommen, reicht es dir wohl auch wenn du bloss während H/V Sync in SRAM schreibst, ein richtiges Multiplexing brauchst du daher wohl nicht mal.
Ich dachte an ein FPGA weil ich hier ein FPGA Spartan 3E ENtwicklungsboard zur verfügung habe. Was allerdings wohl Problematisch ist, das die vorhandene VGA Schnittstelle nur 8 verschiedene Farben darstellen kann, weil auf dem Board kein VideoDAC vorhanden ist. Ich hatte mir überlegt gehabt, die Bilddaten über VGA SChnittstelle auf einen IC (MC1377...) der die VGA Signale (RGB) zu Composite umwandelt. Aber die Farbtiefe wird wohl etwas zu gering!
Sind die schwarz/weiß bilder? Müssen die format-Infos in der header des Bildes mitgespeichert werden? wie viele Bytes sollen insgesamt gespeichert werden?
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.