Es gibt jede menge FPGA boards wo man HDMI direkt mit FPGA IO pins macht. In prinzip laufen tut so was OK. Aber wenn man den FPGA board ohne strom hat, und der monitor noch an ist dann fliesst relative grosses strom von Monitor in das FPGA rein. Das kann man so einfach gar nicht vermeiden. Da sollte man keine Angst haben und ein PTN3363 HDMI treiber einbauen, ist zwar ein komponent (QFN32) mehr aber dann ist HDMI sauber. Der treiber ist "AC coupled" zu FPGA und "DC coupled" zu HDMI. Kein rückstrom! Ich habe gerade eine solche adapter platine getestet mit HDMI test code von fpga4fun - CRUVI-HS HDMI platine CR00240 angesteckt an CR00107 Spartan-7 board. Das test design funktionierte gleich, bild auf dem Monitor da. Das interface zu FPGA sollte mit 1.2V bis 3.3V VCCIO kompatible sein. Egal was differential aus dem FPGA rauspusten, der treiber macht davon HDMI! Kurz: wenn sie HDMI mit FPGA pins machen wollen sparen sie nicht mit dem HDMI treiber.
Antti L. schrieb: > und der monitor noch an ist dann fliesst relative > grosses strom von Monitor in das FPGA rein. Woher kommt der Strom? Ist das der 5V-Erkennungspin? Wenn es ein Empfänger ist, sollte doch dort nur ein Leckstrom vom Reiver kommen. Antti L. schrieb: > CRUVI-HS HDMI platine CR00240 Und die gibt es vermutlich bei Euch zu kaufen? Warum nicht einfach einen 8,- ADV74xx auf die Platine?
Andi F. schrieb: > Antti L. schrieb: >> und der monitor noch an ist dann fliesst relative >> grosses strom von Monitor in das FPGA rein. > Woher kommt der Strom? Ist das der 5V-Erkennungspin? > Wenn es ein Empfänger ist, sollte doch dort nur ein Leckstrom vom Reiver > kommen. > Leckstrom kommt durch terminierungs pullup widerstände 8 x 50 Ohm zu 3.3V in monitor! Wenn man die HDMI clock/data leitungen zu FGPA direkt verbindet dann hat man den Leckstrom! > Antti L. schrieb: >> CRUVI-HS HDMI platine CR00240 > Und die gibt es vermutlich bei Euch zu kaufen? sehr bald, ja wir verfügbar sein > > Warum nicht einfach einen 8,- ADV74xx auf die Platine? Konnte nicht schlau werden welchen chip du meinst. Aber der PTN3363 kostet um die 1 EUR.
Antti L. schrieb: > Leckstrom kommt durch terminierungs pullup widerstände 8 x 50 Ohm zu > 3.3V in monitor! Wenn man die HDMI clock/data leitungen zu FGPA direkt > verbindet dann hat man den Leckstrom! Kann man da nicht seriell ein paar Kondensatoren in die Datenleitungen einfügen um den DC-Pfad zu unterbinden?
Rick D. schrieb: > Antti L. schrieb: >> Leckstrom kommt durch terminierungs pullup widerstände 8 x 50 Ohm zu >> 3.3V in monitor! Wenn man die HDMI clock/data leitungen zu FGPA direkt >> verbindet dann hat man den Leckstrom! > Kann man da nicht seriell ein paar Kondensatoren in die Datenleitungen > einfügen um den DC-Pfad zu unterbinden? nein TMDS /HDMI muss DC coupled sein, die treiber ziehen strom von pullup terminatoren...
Antti L. schrieb: > CRUVI-HS HDMI platine Soso, "Cruvi", die hatten wir doch schonmal: Beitrag "Re: CRUVI - ist das hier um zu bleiben?" So ein Zufall, dass da ein Antti Lukats drinhängt. Kann mal jemand den Spam entfernen?
Wieso Spam? Trenz veröffentlicht auch Schaltpläne, das ist also durchaus gut wenn die was bauen auch wenn man es nicht kauft. Und CRUVI ist tatsächlich nett. Denn was gibt es als Alternative? Diesen XCY... bei Digilent und OpalKelly den man aber nur schlecht selber löten kann und PMOD das wenige Pins hat und für schnelle Signale nicht taugt. Klar, man kann auch FMC nehmen aber da kosten die Stecker und sind auch schlecht von Bastlern zu löten. Ich verwende privat CRUVI, das hat genug IOs, die Standardbelegung macht Sinn und ich kann das mit Heißluft löten.
Gustl B. schrieb: > Wieso Spam? Wenn jemand schreibt, dass er "gerade eine solche Adapterplatine getestet" hätte, aber Mitarbeiter oder gar Geschäftsführer des Herstellers ist, ist das versteckte Werbung.
Werbung ja klar, aber es ging gerade um Spam. Jeder der für etwas wirbt macht Werbung. Auch ich wenn ich meine Hobbyprojekte vorstelle mache Werbung. Wenn du eine Idee gut findest und sie hier schreibst und verteidigst, dann wirbst du für diesen Gedanken. Ob etwas Spam ist hat mit Werbung nichts zu tun, sondern damit ob das für den Adressaten relevant und interessant ist. Ich finde das interessant und zack schon ist das kein Spam.
Wenn die entsprechenden FPGA-Pins den TMDS-Standard abdecken, braucht es keinen extra Treiber. Notabene: Die HDMI-Datensignale sind DC-frei, koennen also z.B. bei der ECP-3 Serie von Lattice mit einem Kondensator in Serie an den HDMI-Port. Dass das bei manchen Aufloesungen am Standard vorbeischrappen kann, ist eine andere Geschichte. Auf den DDC-Pins kann natuerlich Strom fliessen, und man sollte drauf achten, sein FPGA nicht allenfalls ueber die Clamping-Dioden mit Strom zu versorgen...
Das ist ein guter Hinweis für alle, die HDMI realisieren wollen und das bisher nicht kannten. Einige Digilent-Boards und wenige Xilinx-Boards nutzen ebenfalls solche Chips. Für HDMI an den GPIOs der 7series gibt es bereits einige Boards im Bereich einige 100 EUR. FullHD 60Hz läuft nur out of spec. Damit würde ich jetzt nicht mehr anfangen, sondern gleich etwas für die GPIOs der US+ (Artix/Spartan) vorbereiten oder an die Gigabit-Transceiver eines XC7A25T (CSG325) anschließen. Für niedrige Auflösungen genügt dank (re)driver ggf. der 1.27er pinheader am günstigeren TE0890-01. Das teurere CRUVI CR00240 braucht es dann nicht.
Martin S. schrieb: > Wenn die entsprechenden FPGA-Pins den TMDS-Standard abdecken, braucht es > keinen extra Treiber. Chip-2-Chip in jedem Fall, habe ich schon für UHD gemacht. Man muss aber aufpassen, wenn es um lange Leitungen geht und man hot-plug betreiben will. Da kann man schon mal die Ausgänge grillen.
Gustl B. schrieb: > Adv7511 gibt aber auch andere ältere aus der Familie. ja ADV7511 ist der Klassiker für HDMI, wenn platz und IO da sind kann man es nehmen. Aber dann muss I2C programmierung auch noch stimmen. Mit FPGA IO und level shifter ist es billiger, kleiner und nimmt weniger IO, für manche Projekte schon ausreichend.
Martin S. schrieb: > Wenn die entsprechenden FPGA-Pins den TMDS-Standard abdecken, braucht es > keinen extra Treiber. Notabene: Die HDMI-Datensignale sind DC-frei, > koennen also z.B. bei der ECP-3 Serie von Lattice mit einem Kondensator > in Serie an den HDMI-Port. Dass das bei manchen Aufloesungen am Standard > vorbeischrappen kann, ist eine andere Geschichte. > Auf den DDC-Pins kann natuerlich Strom fliessen, und man sollte drauf > achten, sein FPGA nicht allenfalls ueber die Clamping-Dioden mit Strom > zu versorgen... Das ist das problem, auch die FPGAs die "TMDS" unterstützen kann man eigentlich ohne den level shifter verwenden! Das ist blöde aber so ist es, dh auch bei einem Spartan-7 oder Artix-7 muss man HDMI machen mit LVDS IO standard und HDMI treiber IC, sonst ist rückstrom da! Mit kondensator in series macht man HDMI nicht, egal ob es mal laufen kann so.
2 Punkte noch zu dem Thema: 1) "Weniger Pins" stimmt, aber man braucht die Transceiver. Ich habe vor fast 10 Jahren ein HDMI-Design mit dem Spartan 6 gemacht und stand vor der Frage, es mit den Tranceivern zu lösen oder nicht. Der Punkt war damals der Mehrpreis für die Transceiver-Version des Spartan. Die Chips waren in Summe nicht viel teuerer und lösen das Kabelimpedanzproblem. Das Thema ist heute sicher ein anderes, weil man Transceiver in FPGas für lau bekommt. Aber: 2) Man muss auch schauen, welche Raten der Transceiver macht. Mit einem Chip ist es ohne Weiteres Möglich, ein 10Bit-Video zu machen oder auch UHD, was Raten erfordert, die z.B. ein Artix nicht bringt und ein Spartan schon gar nicht. Da darf dann mindestens ein Kintex ran. Im Gegenteil dazu kann man mit einem Chip und einer 33 Bit-Verbindung ein Videosignal mit einem €15,- FPGA bringen.
J. S. schrieb: > 2 Punkte noch zu dem Thema: > > 1) "Weniger Pins" stimmt, aber man braucht die Transceiver. Ich habe vor > fast 10 Jahren ein HDMI-Design mit dem Spartan 6 gemacht und stand vor > der Frage, es mit den Tranceivern zu lösen oder nicht. Der Punkt war > damals der Mehrpreis für die Transceiver-Version des Spartan. Die Chips > waren in Summe nicht viel teuerer und lösen das Kabelimpedanzproblem. > Das Thema ist heute sicher ein anderes, weil man Transceiver in FPGas > für lau bekommt. Aber: > bei Transceiver muss man immer treiber oder retimer verwenden. Der PTN3363 ist aber für NORMALE IO's nicht die transceiver. Klar kann man damit nicht allzugrosse Auflösung machen, aber etwas geht. > 2) Man muss auch schauen, welche Raten der Transceiver macht. Mit einem > Chip ist es ohne Weiteres Möglich, ein 10Bit-Video zu machen oder auch > UHD, was Raten erfordert, die z.B. ein Artix nicht bringt und ein > Spartan schon gar nicht. Da darf dann mindestens ein Kintex ran. Im > Gegenteil dazu kann man mit einem Chip und einer 33 Bit-Verbindung ein > Videosignal mit einem €15,- FPGA bringen. HDMI mit Transceiver ist ganz andere Geschichte.
Antti L. schrieb: > Mit kondensator in series macht man HDMI nicht, egal ob es mal laufen > kann so. Gerne mit Begruendung. Nochmal: HDMI ist DC-frei wie DVI (8b10b Codierung). Wir haben durchaus Designs laufen, die dem 1.0 Standard entsprechen und DC-entkoppelt sind. Allerdings sind das wie gesagt Lattice-Bausteine und keine Xilinx-HDMI-Hacks. Es gibt viele Refdesigns, die Treiberbausteine verwenden, um die 2.0 specs zu schaffen. Insofern verstehe ich neben der schon angemerkten Kritik den Sinn dieses Beitrags nicht.
Martin S. schrieb: > Antti L. schrieb: >> Mit kondensator in series macht man HDMI nicht, egal ob es mal laufen >> kann so. > > Gerne mit Begruendung. Nochmal: HDMI ist DC-frei wie DVI (8b10b > Codierung). Das ist klar. Das ist so. > Wir haben durchaus Designs laufen, die dem 1.0 Standard entsprechen und > DC-entkoppelt sind. Allerdings sind das wie gesagt Lattice-Bausteine und > keine Xilinx-HDMI-Hacks. Eine AC coupling mit series C ist nicht erlaubt, da HDMI eingang nicht "self biased ist". Die 50ohm pullups zu 3.3V ziehen alle eingange auf 3.3V, dann gibts du AC gekoppeltes signals drauf. Das ist nicht so richtig, egal ob es so geht oder nicht. HDMI muss DC gekoppelt sein. > Es gibt viele Refdesigns, die Treiberbausteine verwenden, um die 2.0 > specs zu schaffen. Insofern verstehe ich neben der schon angemerkten > Kritik den Sinn dieses Beitrags nicht. 2.0 schafft man mit FPGA I/O pins so oder so nict. Der Treiber notwendig um den rückstrom zu blokieren. Sonst wäre Xilinx TMDS ok auch direct.
Antti L. schrieb: > bei Transceiver muss man immer treiber oder retimer verwenden. Bei den Kabeln ja, Chip-2-Chip nicht. Habe ich ja schon genau so gemacht. Kurze Distanzen ohne große Kapa funktionieren. Sind sogar als Design in einem ->regulierten Umfeld mit erweiterten Sicherheitsanforderungen so unterwegs. > NORMALE IO's ... damit nicht allzugrosse Auflösung Das ist für mich z.B. ein Punkt: Wenn es aus funktionieller Sicht nicht zu einer ansprechenden Auflösung reicht, dann hilft auch keine technisch günstige Lösung als HDMI-Signal. Unter dem "HD" verstehe ich nach wie vor high density und wenn damit nicht wenigsten 1080p laufen, kann ich auch gleich VGA machen. Und: HDMI ist wie gesagt mit royalities belegt, was dem Billignutzer im Wege steht. Ich sehe keine Anwendung für eine technisch einfache und günstige Lösung, die mich dann noch Geld kosten soll. Wenn Geld, dann richtig und dann bitte richtiges Bild. Fürs Heimbasteln wie auch das Industriebasteln kann ich Hobbywerkern und Kunden nur Displayport empfehlen. Von mir aus auch mit geringer Auflösung, z.B. SD "Schmalspur HD". Hier ist übrigens ein 1080p60 Signal mit VGA gemacht und zwar mit eurem Spartan 6 TE630 :-) https://youtu.be/F8HvA-YQ8is
:
Bearbeitet durch User
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.