Forum: FPGA, VHDL & Co. FPGA für HDMI input + Ethernet output


von Tommy (Gast)


Lesenswert?

Hallo Leute,

ich suche einen möglichst günstigen FPGA, mit dem ich einen HDMI input 
(natürlich ein fertiger ip-core) realisieren kann.

Die Bilder soll in einen ram gespeichert werden, jpeg komprimiert werden 
und anschließend via Ethernet versendet werden. Also quasi "KVM over IP" 
do it yourself.

Vielleicht gibt es auch schon ein fertiges Projekt? Ich würde mir sehr 
gerne ansehen, wie so etwas genau realisiert wird und günstigstmöglich 
umgesetzt werden kann.


Beste Grüße,

Tom

von hunz (Gast)


Lesenswert?

Zumindest fürs Prototyping könnte das hier ein passendes Board sein wenn 
Xilinx für dich ok ist: 
http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_114_119&products_id=829 
- das hat RAM, HDMI inputs und GBit Ethernet
XAPP495 beschreibt HDMI für Spartan-6 - bitte beachten dass ohne 
externen Receiver kein FullHD geht - falls du das brauchst. Näheres 
steht in der XAPP.
Wegen JPEG encoding kannst du mal bei opencores gucken.

von Tommy (Gast)


Lesenswert?

Ich würde das Projekt - sofern es noch kein solches gibt - gerne 
öffentlich und frei machen, daher die Frage nach dem günstigst möglichen 
FPGA mit dem das realisierbar ist. Soll garantiert nichts mehr anderes 
können und anschließend in 100er Stückzahlen produziert werden.

Hdmi input + 2 x Ethernet Gigabit (Quasi als Switch, auf dem am ersten 
port der Rechner angeschlossen ist, am zweiten Port die Pakete vom 
Rechner und vom FPGA rauskommen)

Beste Grüße

von Tommy (Gast)


Lesenswert?

1280x1024 würde voll ausreichen.

von hunz (Gast)


Lesenswert?

SXGA geht mit dem höchsten speedgrade (4) gerade mal so. Dann lieber 
externer TMDS Receiver, die Lieferbarkeit von speedgrade 4 ist eher 
schlecht.
Board musst du dir dann sowieso selber bauen. Vielleicht wird ein 
Spartan3A/E dann auch günstiger als ein Spartan6.
Wenn du kein fertiges Modul mit FPGA+RAM benutzen willst, musst du dich 
halt auch um die RAM-Anbindung kümmern. Bei Spartan6 kommst du um DDR 
nicht herum weil der MCB kein SDR mehr kann. Vielleicht lässt sich das 
Layout hier als Grundlage für FPGA+RAM benutzen: 
http://pipistrello.saanlima.com/index.php?title=Welcome_to_Pipistrello
Soweit ich das sehe sind da aber BGAs auf Top+Bottom, das macht die 
Fertigung komplizierter und teurer.
Bei Spartan3A/E kannst du auch SDR mit dem MIG benutzen, allerdings sind 
die DDR-RAMs soweit ich weiß mittlerweile billiger als SDR. Nur das 
Layout ist dann etwas einfacher.
In jedem Fall würde ich für ein open source Projekt (d.h. unter 
Verwendung von entsprechend lizenzierten, bestehenden cores) von >= 2-3 
Mann-Monaten ausgehen für Layout+Design wenn du mit beidem Erfahrung 
hat.

von PittyJ (Gast)


Lesenswert?

JPEG komprimiert und dann per Ethernet verschickt werden...
Das sind ja noch mindestens 2 IP-Cores mehr. Vielleicht kann man HDMI 
per FPGA aufdröseln. Aber diese Schritte würde ich dann doch von einem 
Prozessor erledigen lassen. Es gibt da zwar ein paar Cores für Jpeg 
Encoding. Aber sobald man selber etwas machen möchte, geht das in einem 
Prozessor einfacher.

von Martin S. (strubi)


Lesenswert?

Moin,

auf dem Lattice HDR-60 könnte das ebenfalls gehen, sofern sich die 
HDMI-Richtung (default: Ausgabe) leicht umdrehen lässt.
DDR-RAM ist dazu nicht nötig, die Daten müssen nur zeilenweise gepuffert 
werden, der ECP3 hat dafür genug RAM. Die Frage stellt sich eher nach 
der Durchsatzrate.

Ich bin ansich von einer Xilinx-basierten Kamera zum HDR-60 geraten und 
war positiv überrascht, wie gut sich die Sachen portieren liessen.
Ansich ist das Ding 'ne fertige Kamera. Link:
http://www.latticesemi.com/products/developmenthardware/developmentkits/hdr60videocameradevkit/index.cfm
Auf der Messe (Embedded) gab's dazu auch GigE-Übertragung zu sehen. 
JPEG-Encoder wird es auch in Bälde geben, läuft hier bereits per USB.

Allerdings kann ich auch sagen: Mit OpenCores wird's nur bedingt 
hinzukriegen sein. Die meisten der JPEG-Encoder auf OC sind in der 
Praxis kaum brauchbar. Ich würde mal mindestens mit einem Mannjahr 
Arbeit rechnen oder Entwicklungskosten um 50'000 Euro. Und obige IPcores 
in einer brauchbaren Qualität wird es garantiert nicht als OpenSource 
geben.
Ebenso musst Du Dich für eine brauchbare Soft-CPU entscheiden, das ist 
nicht ganz einfach bzw. oft herstellerabhängig (ausser mico32).

Wenn Du mit einer niedrigen Framerate auskommst, wird die Sache in 
kleinen Stückzahlen deutlich weniger aufwendig ausfallen, wenn Du ein 
übliches DSP-Modul z.B. mit Blackfin und einem FPGA hernimmst (FPGA fürs 
Deserializing und DCT, Blackfin für Kompression und Versand). Auf die 
Weise lassen sich etwa an die 20-25 fps bei 1024x1024 hinkriegen. Mit 
den neueren Dualcore-Chips vermutlich einiges mehr, aber das habe ich 
noch nicht probiert.

Grüsse,

- Strubi

von Oli (Gast)


Lesenswert?

hunz schrieb:
> - das hat RAM, HDMI inputs und GBit Ethernet
> XAPP495 beschreibt HDMI für Spartan-6 - bitte beachten dass ohne
> externen Receiver kein FullHD geht - falls du das brauchst. Näheres
> steht in der XAPP.

Welcher Textpassage in der besagten APP kann ich das entnehmen, dass 
"ohne Receiver kein HDMI geht" und was wäre der "receiver"?

Ein serializer chip?

von Christian R. (supachris)


Lesenswert?

Ohne Receiver kein Full-HD steht da im Posting, anscheinend sind die 
FPGA integrierten SERDES nicht schnell genug. Aber in der XAPP ist das 
nicht zu finden, im Gegenteil in der Tabelle am Anfang steht ja 
742MBit/s für Full HD, also reichen die 1080MBit/s vom ISERDES.

Eine spannende Frage ist allerdings die Sache mit HDCP...

von Name: (Gast)


Lesenswert?

Christian R. schrieb:

> Eine spannende Frage ist allerdings die Sache mit HDCP...

Es gibt das quelloffene NeTV-Projekt von bunnie, welches mit einem 
Spartan6 ein Video-Overlay über ein HDMI-Signal setzt - auch wenn das 
Signal HDCP-verschlüsselt ist. Da HDCP eine Stromchiffre ist und für das 
Overlay die neuen Daten passend verschlüsselt werden müssen sollte auch 
ein Umbau zu einem HDCP-Decoder möglich sein.

https://github.com/bunnie/netv-fpga

von Tommy (Gast)


Lesenswert?

Martin S. schrieb:
> Wenn Du mit einer niedrigen Framerate auskommst, wird die Sache in
> kleinen Stückzahlen deutlich weniger aufwendig ausfallen, wenn Du ein
> übliches DSP-Modul z.B. mit Blackfin und einem FPGA hernimmst (FPGA fürs
> Deserializing und DCT, Blackfin für Kompression und Versand). Auf die
> Weise lassen sich etwa an die 20-25 fps bei 1024x1024 hinkriegen. Mit
> den neueren Dualcore-Chips vermutlich einiges mehr, aber das habe ich
> noch nicht probiert.

Das klingt sehr interessant, da eine Framerate von 5fps schon völlig 
ausreicht! Das Gigabitswitching würde man dann wohl auch eher von einem 
switch IC erledigen lassen.

Also würde ich die Sache wie folgt anpassen:

HDMI deserialisation via FPGA, ein Prozessor packt zu jpeg (oder eher 
was, das besser für videostream mit kaum Änderung gedacht ist) und 
verschickt via ethernet auf einen Port des Switch ICs.

Sollte dann wohl schon deutlich unaufwändiger werden das ganze. 
Prinzipiell kommt es beim FPGA dann ja nur auf die Geschwindigkeit der 
SERDES an? Es geht nur um die Ausgabe einer Onboard-Grafik eines PCs, 
HDCP wird nicht benötigt, Filme sollen nicht angezeigt werden. Nur der 
schnöde Windows-Desktop.

Vielleicht hat dann sogar noch jemand eine Empfehlung zu möglichst 
günstigen Komponenten für das ganze.

Vielen vielen Dank euch!

von Tommy (Gast)


Lesenswert?

Ich denke das: 
http://www.xilinx.com/support/documentation/application_notes/xapp460.pdf

dürfte ziemlich nah an das herankommen, was ich suche. Damit sollte ein 
XC3S200A schon ausreichen.

von Martin S. (strubi)


Lesenswert?

Hi Tommy,

Tommy schrieb:
> Das klingt sehr interessant, da eine Framerate von 5fps schon völlig
> ausreicht! Das Gigabitswitching würde man dann wohl auch eher von einem
> switch IC erledigen lassen.
>

5fps bei Deiner Auflösung ist ev. mit einem BF537 unter uClinux mit 
optimiertem JPEG-Encoder grade noch zu schaffen, aber NUR, wenn er nicht 
noch Farbraum-Umrechnungen machen muss. Aber letztere passen ja prima 
ins FPGA.

> Also würde ich die Sache wie folgt anpassen:
>
> HDMI deserialisation via FPGA, ein Prozessor packt zu jpeg (oder eher
> was, das besser für videostream mit kaum Änderung gedacht ist) und
> verschickt via ethernet auf einen Port des Switch ICs.
>
> Sollte dann wohl schon deutlich unaufwändiger werden das ganze.
> Prinzipiell kommt es beim FPGA dann ja nur auf die Geschwindigkeit der
> SERDES an? Es geht nur um die Ausgabe einer Onboard-Grafik eines PCs,
> HDCP wird nicht benötigt, Filme sollen nicht angezeigt werden. Nur der
> schnöde Windows-Desktop.
>

Mal ne ganz doofe Frage: Warum musst Du dann über HDMI gehen? Du 
könntest das ganze doch auch über eine VNC-Verbindung direkt vom PC 
übertragen. Also reine Softwarelösung.
JPEG verunstaltet Bildschirminhalte mit Kanten ziemlich, ist ev. nicht 
das geeignete Format. Es gibt aber einige interessante delta-Codecs (die 
nur Änderungen schicken). Sowas macht auch ein guter VNC-Server.

> Vielleicht hat dann sogar noch jemand eine Empfehlung zu möglichst
> günstigen Komponenten für das ganze.
>

Auf der Messe habe ich bei Bayer DSP ein schickes neues Xynergy 
Coremodul mit DSP und FPGA gesehen. Läst sich per SODIMM auf ein 
Mainboard pappen.

Im Prinzip habe ich das komplette Referenzdesign für eine intelligente 
FPGA-Linux-Kamera, d.h. den ganzen Verarbeitungs/Versandteil mit 
optimiertem JPEG-Codec fertig für Einsatz. Müsste man nur auf die 
entsprechende Plattform portieren, den Rest kannst Du selber machen.
Wegen der Komprimierung sind auch die 100MBit statt 1Gbit ausreichend.

Genaueres kann ich Dir auch per Email schicken.

Grüsse,

- Martin

von Kest (Gast)


Lesenswert?

OT: Sorry, bis jetzt habe ich mich zurückgehalten, aber irgendwie 
verstehe ich das Ganze nicht:
- HDMI (aber natürlich IP-Core)
- JPEG on the fly
- GBit (Switch als IC)
- FPGA möglichst günstig
- DIY open source

Und dann die Frage, wie man alles nun macht... Hmm. Das, was Du da alles 
aufzählst ist verdammt viel Arbeit und richtig teuer. Jeder einzelne 
Punkt hat wohl mehrere Mann-Wochen, wenn nicht -Monate! Die DSPs, FPGAs, 
IC, womöglich als BGA, Leiterplatte, Software und nicht zu vergessen 
Programmierrools und IP-Cores, die locker flockig in kEuro Bereich 
liegen könnten.

Wieso schreibst Du nicht, was Du genau vor hast, privat oder nicht und 
ein Paar Details zu Umständen, dann kann Dir auf jeden Fall besser 
geholfen werden.

Grüße
Kest

von Lattice User (Gast)


Lesenswert?

Martin S. schrieb:
> Moin,
>
> auf dem Lattice HDR-60 könnte das ebenfalls gehen, sofern sich die
> HDMI-Richtung (default: Ausgabe) leicht umdrehen lässt.

Ist nicht umdrehbar, da für das HDMI Interface die Highspeed Serdes 
verwendet werden, und die haben getrennte Pins für Input und Output.

von Paul B. (Gast)


Lesenswert?

Christian R. schrieb:
> Ohne Receiver kein Full-HD steht da im Posting, anscheinend sind die
> FPGA integrierten SERDES nicht schnell genug. Aber in der XAPP ist das
> nicht zu finden, im Gegenteil in der Tabelle am Anfang steht ja
> 742MBit/s für Full HD, also reichen die 1080MBit/s vom ISERDES.
>
> Eine spannende Frage ist allerdings die Sache mit HDCP...

in der XP 495 steht eine Tabelle, die aufschlüsselt, dass mit den SERDES 
bei 1080 MHz gerade die 1280x1024x60 zu machen sind.

Ich würde auch gerne Füll HDMI 1080p über direkte Ausgabe per TMDS 
betreiben. Hat das jemand mal gemacht?

Geht das mit einem schnelleren FPGA?

Bitte 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
Noch kein Account? Hier anmelden.