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_conten...

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?