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
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.
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
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.
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.
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
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?
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...
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
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!
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.
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
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.