Hallo zusammen
Ich würde gerne mit einem FPGA ein HDMI-Signal (max. Full HD)
analysieren. Dabei ist das Ziel, dass ich Zugriff auf die einzelnen
Pixelinformationen erhalte. Mit diesen Informationen möchte ich dann
z.B. RGB-LEDs ansteuern.
Die Frage die sich mir stellt ist:
HDMI direkt an das FPGA anschliessen oder evtl. zuvor einen HDMI zu
Parallel Konverter verwenden? (Falls es sowas gibt).
Bin für Vorschläge / Kommentare aller Art offen.
Danke!
Moin,
schau dir mal das Lattice EVDK/VIP an. Damit geht sowas, allerdings ist
das HDMI-Input-Board da nicht im Bundle mit dabei und HDCP-Sourcen
werden nicht unterstuetzt.
Man kann auch direkt HDMI bei ECP3 (und wohl auch -5) unter Einhaltung
der TMDS-Signalregeln an die PCS-Eingaenge routen, aber muss sich dann
sehr eingehend mit den Timings und der betreffenden Logik beschaeftigen.
Sehr aufwendig. Gibt hier einige Threads zu.
Vielen Dank für eure Antworten.
Das sieht sehr vielversprechend aus.
Schaue ich mir gleich mal an.
HDCP soll/muss aktuell nicht unterstützt werden.
Weitere Inputs/Vorschläge weiterhin sehr willkommen.
Das Mojo Shield scheint genau das richtige zu sein. Leider scheint es
die ursprüngliche Version nicht mehr zu geben.
Hat evtl. noch jemand ein Mojo mit HDMI-Shield herumliegen?
Weltbester FPGA-Pongo schrieb im Beitrag #6027023:
> Digilet ATLYS ginge noch. Da ist der HDMI Receiver gleich mit drauf.
Danke für deine Antwort.
Beim Mojo scheint es bereits eine art Library zu geben für die
Dekodierung. Fragt sich, ob sich diese für das ATLYS Board verwenden
lässt.
Leider alles discontinued beim Mojo
https://alchitry.com/products/hdmi-shield?_pos=3&_sid=220711b39&_ss=r
Ich will ja niemandem auf die Fuesse treten, aber es duerfte Gruende
haben, warum diese HDMI-Shields nicht mehr angeboten werden: Elektrisch
ist das totaler Murks, wie fast alles aus dieser Mojo-Serie. Mal
abgesehen davon, dass der Spartan6 den Standard vom Timing her schlecht
packt, siehe auch Beitrag "SVGA aus FullHD schneiden".
Aber zum bisschen rumbasteln genuegt's. Fragt sich nur, ob man nicht
doch am falschen Ende gespart hat, wenn man wochenlang am Timing
rumkratzt und es einfach nicht stabil kriegt...
Strubi schrieb:> Aber zum bisschen rumbasteln genuegt's. Fragt sich nur, ob man nicht> doch am falschen Ende gespart hat, wenn man wochenlang am Timing> rumkratzt und es einfach nicht stabil kriegt...
Danke für deine Antwort
Es geht tatsächlich darum, erstmal ein Gefühl für HDMI mit einem FPGA zu
bekommen.
Was wäre denn deine erste Wahl?
Bzw. was würdest du empfehlen?
Tönt nach dem genau richtigen Projekt für das Open Hardware Projekt
NeTV2:
https://www.crowdsupply.com/alphamax/netv2
Out of the box gibt es zwei Modi:
- NeTV Classic Mode
NeTV2 will ship to backers in "NeTV Classic Mode." In this mode, the
FPGA is configured with a bitstream that allows the NeTV2 to add
encrypted pixels to an encrypted video stream, without ever decrypting
the video stream.
- Libre Mode
The libre mode of NeTV2 is geared more toward developers. In this mode,
the NeTV2 works only with unencrypted video feeds, but has full access
to the entire video stream. This lets you arbitrarily manipulate pixels
in real time
Features & Specifications
FPGA: Xilinx XC7A35T-2FGG484
On-board RAM: 512 MBytes, 32-bit wide DDR3-800
Video Ports: 2 x HDMI type A inputs, 1 x HDMI type A output, 1 x
HDMI type D output. One input/output pair configured for in-line 'NeTV
mode' video filtering.
Max Video Bandwidth: 1920 x 1080 @ 60 Hz
Developer I/O: PCI-express 2.0 x4 with "hax" GPIO extensions on
optional/unused pins, 100Base-T ethernet, micro-USB, microSD, JTAG
Power: Either 12 VDC via barrel jack, or 12 VDC via PCI-express; 10
W max operating power
SBC: Optional Raspberry Pi 3B+ for seamless JTAG configuration and
overlay video generation
HDL: Optimized for migen/LiteX Python-based hardware description
language
Dimensions: 160 mm x 120 mm x 51 mm (optional plastic case outer
dimensions)
Dazu gibts auch einen langen Vortrag:
https://media.ccc.de/v/35c3-9629-snakes_and_rabbits_-_how_ccc_shaped_an_open_hardware_success
John schrieb:> Was wäre denn deine erste Wahl?> Bzw. was würdest du empfehlen?
Ich wuerde heute, um moeglichst schnell zu einem Ergebnis zu kommen, die
EVDK/VIP-Geschichte mit einem HDMI-Receiverchip anwerfen. Es gab auch
noch ein ECP3-Video Protocol-Kit, das war allerdings teurer. Das VIP
gab's vor einem Jahr fuer'n Promo-Preis von knapp 200 USD.
Fragt sich, wie tief du ins Verstaendnis von dem, was 'da unten'
zappelt, so einsteigen willst. Aber so oder so wuerde ich was nehmen
wollen, was von den Impedanzen her nah an den TMDS-Standard hinzutunen
ist. Wir haben's damals gleich auf den ersten PCB-Schuss mit dem ECP3
hinbekommen.
Die NeTV2-Hardware ist sicher auch interessant, nur mit dem
(n)migen-Hack wuerde ich nicht arbeiten wollen. Muss aber jeder selber
wissen. Wenn's laeuft, laeuft's.
Wenn du das ganze allerdings komplett in die Simulation stecken willst,
wird's mit OpenSource etwas kniffliger. Bei Lattice fehlen z.B. die
VHDL-Modelle und man muss sie sich muehsamst selber konvertieren. Oder
gleich auf Verilog gehen..
Hat dieses MOJO-Viech einen Transceiver drauf? Sieht mir mehr nach
buffer aus. Und was mit mit dem NETTV? Der gesamten Beschreibungsseite
ist nichts konkretes zu entnehmen.
Für weitere Recherchen würde ich das empfehlen:
http://hamsterworks.co.nz/mediawiki/index.php/Minimal_HDMI
Ich sehe dort nur ESD, aber keinen buffer / transceiver. Es bestehen
also gfs. Pegelprobleme und in jedem Fall die Notwendigkeit, die
HDMI-low level Funktionalität mit den FPGA-IOs abzubilden. Das ist
natürlich genau die richtige Aufgabe für einen Bastler :-)
Anders herum betrachtet ist es aber auch gut, dass sich de potenzielle
Nutzer des PCBs daran abarbeiten kann. So kommt er nicht in die
Situation, es aus dem Kasten zu nehmen, es anzuschalten und das mickrige
35er-FPGA binnen 3h vollzuprogrammieren, um dann festzustellen, dass man
damit so gut wie nichts machen kann, was den Namen Videobearbeitung
verdient.
John schrieb:> Beim Mojo scheint es bereits eine art Library zu geben für die> Dekodierung. Fragt sich, ob sich diese für das ATLYS Board verwenden> lässt.
Keine Ahnung, aber grundsätzlich lässt sich alles irgendwie portieren.