Hallo und Entschuldigung wenn es schon so einen Thread gibt. Ich habe in Erinnerung das schonmal hier diskutiert zu haben, finde aber den Thread leider nicht. Ich möchte HDMI mit dem Spartan7 machen. Im Select IO UG der 7er Serie https://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf steht: The TMDS standard requires external 50Ω pull-up resistors to 3.3V on the inputs. TMDS inputs do not require differential input termination resistors. TMDS is only available in HR I/O banks and requires a VCCO voltage level of 3.3V. The IOSTANDARD is called TMDS_33. Soweit OK. Aber was ich nicht verstehe: Ist das LVDS? Und wieso geht das nur mit VCCO 3.3V? Wenn das wie LVDS eine Stromquelle ist, dann wäre doch die Stromstärke und nicht die Bankspannung entscheidend. Denn da fließt ein Strom und über der Terminierung wird dann eine Spannung messbar. Ja, die Bankspannung/2 ist dann die DC-Spannung um die herum das Signal schwingt. Aber das könnte ich zur Not AC-koppeln und mit einer für TMDS passenden Spannung DC-biassen. Ich habe zu HDMI Receivern auch schon Bildchen gefunden bei denen die Leitungen AC-gekoppelt sind vor der Terminierung. Dann wäre das DC Niveau ziemlich egal. Ich frage deswegen, weil ich an einer FPGA Bank mit 1.8 V noch ein paar IOs frei hätte die gut für HDMI reichen würden. Jetzt gibt es noch DIFF_HSTL_I_18, DIFF_HSTL_II_18, DIFF_MOBILE_DDR, DIFF_SSTL18_I und DIFF_SSTL18_II. Kann ich eines davon verwenden um das differentielle Signal für HDMI auszugeben?
In CMOS ist eine Stromquelle auch nur eine Transistorschaltung, die ihre Spannungsbereiche zum Arbeiten braucht. Scheinbar konnte man einfach nicht LVDS bzw. TMDS in dieser Technologie mit nur 1.8V umsetzen. Man sollte stark darauf achten wie die Signale terminiert werden. Prinzipiell sind die Common Mode Spannungen nach einem AC-Cap egal, solang sich die Empfangsschaltung darum kümmert. SSTL ist eher für DDR Speicher bzw. Leitungen ohne AC-Entkopplung gedacht. Wenn man solche IO-Tricks durchführen will, wäre auch eine kleine IBIS-Simulation sinnvoll.
Kann man denn mit den FPGA-Ausgängen dieselbe Qualität an Signalen erzeugen, wie es die einschlägigen Chips tun, oder gibt es da Einschränkungen? In einem anderen Faden wird es so dargestellt, dass es voll kompatibel sei, aus dritter Quelle höre ich, dass es eine Notlösung sei. Was ist denn nun genau die besondere Eigenschaft der TMDS-Signale? Ich lese im Wiki etwas von Current Mode. Wie wird der realisier?
OK, ja verstehe ich, aber was ich nicht weiß ist, welcher IO Standard eine Spannungsquelle beschreibt, wie LVCMOS, und welcher eine Stromquelle beschreibt/definiert wie LVDS. Ist von den genannten DIFF_HSTL_I_18, DIFF_HSTL_II_18, DIFF_MOBILE_DDR, DIFF_SSTL18_I und DIFF_SSTL18_II ein Standard dabei der genau wie LVDS eine Stromquelle definiert?
PCB schrieb: > https://en.wikipedia.org/wiki/Current-mode_logic Obwohl CML ja auch ein Standard für sich ist und nicht unbedingt mit LVDS gleichgesetzt werden sollte. Ich finde die Diskussion, ob Stromquelle oder Spannungsquelle nicht zielführend. Man muss einfach schauen wie der Standard richtig terminiert wird. Des Weiteren ist es dem Signal auf der 50 Ohm Leitung egal, ob es CML oder LVDS ist, denn auf einer langen Leitung gilt nur die U/I-Beziehung über den Wellenwiderstand. Bei den Standards ist demnach meist im Common-Mode der große Unterschied.
Wenn du noch genügend Pins frei hast, dann könntest du auch einen HDMI-Receiver/Transmitter ranknallen, der das physikalische Ebene regelt.
PCB schrieb: > Wenn du noch genügend Pins frei hast, dann könntest du auch einen > HDMI-Receiver/Transmitter ranknallen, der das physikalische Ebene > regelt. Das ist definitiv sinnvoller. HDMI auf den Spartanern ist sonst kaum vom Timing her elegant zu schaffen. Abgesehen davon wuerde ich die TDMS-Einkopplung keineswegs an einem 1.8V I/O riskieren, wer weiss was da die Clamp-Dioden alles an Effekten einschleppen. Ansonsten hat Lattice da einiges anzubieten, auf dem ECP3 geht HDMI in/out mit Tricks, aber besser noch mit einem Si* ohne HDCP (die kriegt man auch).
OK. Naja gut. Ich plane gerade ein FPGA Board an dem ich wieder etwas lernen möchte. Dieses Mal ist es USB3 über USB-C. Neben RAM, USB-Baustein FT600 habe ich aber noch viele IOs frei. Weil ich auch etwas mit SerDes lernen wollte dachte ich entweder an HDMI, schnelle Datenwandler oder eine Zweckentfremdung von SerDes. Im EEV Forum gibt es einen Logicanalyzer "Tastkopf" der über USB-C verbunden wird. Der besitzt einen IC der vier schr schnelle Komparatoren mit differentiellen Ausgängen hat. Dieser Ausgänge werden über die SuperSpeed Verbindungen geroutet, Versorgung (+/-) auch über USB-C und V_REF ebenfalls. Ich möchte auch sowas bauen, werde auf den USB-C nur 5V legen, dafür aber noch weitere Leitungen mit dem FPGA verbinden. Dann kann ich auf meinen LA-Tastkopf einen kleinen SPI-DAC für V_Ref und eine Ladungspumpe für die negative Versorgung setzen. Also ... das sind zwei verschiedene USB-C Buchsen. Eine für USB3/USB2 die am FT600 angeschlossen ist und über die dann das FPGA Board versorgt werden soll und dann eine weitere USB-C Buchse für schnelle IO aber nur für USB3/2. Aber ich möchte das nicht nur für den LA-Tastkopf verwenden, sondern auch für andere Dinge. Ich werde einen Adapter USB-C nach PMOD bauen und würde aber auch gerne HDMI über USB-C machen. Dafür habe ich die USB-C Buchse an eine FPGA Bank mit VCCO=3.3V angeschlossen. Wunderbar. Aber ich habe noch weitere IOs und würde gerne noch eine weitere USB-C Buchse verbauen. Dann hätte ich 8 schnelle IOs für zwei vierkanal LA-Tastköpfe oder 2x HDMI. Aber gut, dann lasse ich das, denn die freien IOs hängen an einer 1.8V Bank. Wobei, ich habe noch einen normalen PMOD an der 3.3V Bank eingeplant. Den könnte ich auf den USB-C routen und stattdessen an die 1.8V Bank einen PMOD hängen aber mit Pegelwandler davor. Mal gucken. Jedenfalls vielen Dank!
Der ADV7511 wäre ein guter Kandidat, den dürfte ich auch schon mal eindesignen: https://www.analog.com/media/en/technical-documentation/user-guides/ADV7511_Hardware_Users_Guide.pdf
Ja, könnte man machen, aber ich möchte ja was lernen. Bild ausgeben über VGA, also Farbwerte an einen DAC weitergeben und das Timing für ein Bild einhalten habe ich schon gemacht, das wird mir so einem IC auch nicht groß anders sein. Ich möchte eben selbst man das 8b10b und das TMDA machen und über SerDes ausgeben. Gleichzeitig möchte ich aber auch die Möglichkeit haben das als Eingang zu verwenden und dann ein differentielles Signal mit einem SerDes sehr schnell (>500MHz) "abzutasten". Das wäre dann ein schneller USB3-LA.
Moin, Wenns eh' nur so ein Versucherle ist, dann kannstes doch ausprobieren: Die LVDS Leitungen halt jeweils ueber einen >=100nF Koppel C fuehren, danach je 50 Ohm Richtung 3.3V Versorgung - da vielleicht irgendwie Obacht geben, dass die beim Einschalten eher langsam hochfaehrt, nicht dass die FPGA Ausgaenge zuviel Strom beim Aufladen der Cs abkriegen. Gruss WK
Ist das dann Aus- oder Eingang? Ich habe gelesen das wird an einem Eingang so gemacht. Aber ich habe mich schon so ziemlich gegen den 3. USB-C entschieden. Für kleine Spielereien reicht auch einer mit HDMItauglicher Beschaltung. Nur was mache ich mit den freien IOs? Ich habe jetzt noch FRAM, ADXL363, LTC2373-16 und ein Schieberegister für LEDs eingeplant. Was wäre denn noch interessant?
Moin, Gustl B. schrieb: > Ist das dann Aus- oder Eingang? Ich habe gelesen das wird an einem > Eingang so gemacht. Huups, stimmt. Ja das waere zwar dann schoen fuer den beidseitigen Leitungsabschluss, aber die armen Treiber muessten dann den doppelten Strom treiben. Dann wuerd' ich statt der 50 Ohm eher 560 Ohm oder 1k oder sowas nehmen, einfach nur um den DC Pegel auf der Leitung bei 3.3V zu haben. Klar, ist alles schon etwas fies, aber naja, wenns die IOs halt nicht native hergeben... Gruss WK
Noch eine Nachfrage weil ich dazu nichts finde: Darf man bei HDMI P und N der Päärchen tauschen? Ich würde behaupten ja. Da muss man dem SerDes dann vermutlich invertierte Bits übergeben. Würde das Layout deutlich bequemer machen.
Moin, Gustl B. schrieb: > Darf man bei HDMI P und N der Päärchen tauschen? Ich würde behaupten ja. > Da muss man dem SerDes dann vermutlich invertierte Bits übergeben. Koennte evtl. sogar auch so gehen - TMDS ist ja DC frei; vielleicht ist's auch verpolungsresistent. Bin mir aber da nicht sicher. Aber das invertieren im FPGA wird auf jeden Fall gehen. Gruss WK
Gustl B. schrieb: > Darf man bei HDMI P und N der Päärchen tauschen? Ich würde behaupten ja. Ja. > Da muss man dem SerDes dann vermutlich invertierte Bits übergeben. Genau.
Vielen Dank! Ich habe da jetzt für den USB-C einen TUSB321 als CC-Controller als DFP und dazu einen MP5016 als Current Limit Switch mit etwas über 500 mA für VBUS eingeplant.
Hallo zusammen, es ist so weit, ich habe die Platine hier und die HDMI Pärchen sind an einer 3,3 V FPGA Bank. Jetzt möchte ich also HDMI ausgeben. Ich dachte mir das wie folgt: Bild erzeugen wie bei VGA mit HSync und VSync. Farbdaten durch einen TMDS Encoder schicken. Farbdaten jeweils über einen SerDes ausgeben und die Clock auch ausgeben. Jetzt will ich mir also einen TMDS Encoder schreiben. Ja, gibt es fertig, will ich aber mal selber gemacht haben. Aber ich finde keine so wirklich gute Beschreibung. Eine Beschreibung https://www.oocities.org/yehcheang/TMDS_Encoding_Algorithm.htm sieht schön einfach aus. Eine andere http://www.ijircce.com/upload/2018/june/51_VHDL_IEEE.pdf macht das irgendwie anders und hat dann am ende noch einen 8B/10B Encoder. Aus meiner Sicht widersprechen sich diese beiden Beschreibungen. Wo finde ich denn "die Wahrheit" wie 8 Bit Pixeldaten zu einem 10 Bit TMDS Wert werden der dann so mit dem SerDes übertragen werden kann? Ausserdem habe ich gesehen, dass anscheinend manchmal kein SerDes verwendet wird, sondern der 5-fache Pixeltakt und ein ODDR FF. Welcher Weg ist denn sinnvoller?
im Wiki sieht TMDS sehr nach 8b10b aus. Aber vielleicht hilfts erst sich auf den genauen HDMI Standard festzulegen und dann auf den verwendeten TMDS Standard zu schauen.
Jetzt habe ich im SelectIO Wizard den DVI-Transmitter gefunden. Schicke Sache! Der macht das mit den SerDes von selbst. Aber dem TMDS Encoder brauche ich natürlich weiterhin. Aber dieser DVI-Transmitter will zwei Takte: clk_in: in std_logic; -- Fast clock from PLL/MMCM clk_div_in: in std_logic; -- Slow clock from PLL/MMCM Ich vermute mal, dass der langsame Takt der Pixeltakt ist und der schnelle Takt dann der 10-fache Pixeltakt für den SerDes? Jedenfalls limitiert das etwas am Spartan7, denn die PLL dort kann nur maximal 800 MHz. Ich würde gerne eine 16:10 Auflösung ausgeben weil ich hier 16:10 Monitore habe. Wenn ich die native 1920x1200 Auflösung nehme, dann sind das echt viele Pixel^^ aber OK, ich kann ja mit der Bildrate runtergehen bis es vom Pixeltakt unter 80 MHz liegt. 1280x800@30Hz würde da passen. 1280x800@60Hz passen nicht laut http://tinyvga.com/vga-timing/1280x800@60Hz Aber wie ist das bei HDMI, wie müssen da die H_blank und V_blank Zeiten sein? Genauso wie bei VGA oder können die kürzer ausfallen? Hier dieser Rechner https://tomverbeure.github.io/video_timings_calculator verwendet deutlich andere Blank Zeiten als die tinyvga Seite. Edit: Tim schrieb: > im Wiki sieht TMDS sehr nach 8b10b aus. Natürlich werden aus 8 Bits Farbinformation dann 10 Bits TMDS Farbinformation. Was mich irritiert ist, dass hier http://www.ijircce.com/upload/2018/june/51_VHDL_IEEE.pdf Bitketten vertauscht werden und dann drunter 8B/10B da steht, aber hier https://www.oocities.org/yehcheang/TMDS_Encoding_Algorithm.htm wird nichts vertauscht. Tim schrieb: > Aber vielleicht hilfts erst sich > auf den genauen HDMI Standard festzulegen [...] HDMI 1.0 genügt mir völlig.
:
Bearbeitet durch User
Hallo Gustl, such dir dir eine HDMI Spec, es muss nicht die aktuelle sein, da du die höheren Auflösungen eh nicht mit den normalen IOs des FPGAs schafftst. Fang auch nicht gleich mit einer hohen Auflösung an, sondern erstmal geringer bleiben, um elektrische Probleme auszuschließen. In der HDMI Spec ist alles ziemlich gut beschrieben, was du wie an Daten bereitstellen musst. Auf Drittquellen würde ich mich nicht verlassen. Lieber die Spec einmal durchackern. Umso öfter man sowas tut, umso einfacher geht das in Zukunft und man lernt, dass man schnell die Relevanten Sachen findet, weil man besser weiß, wonach man suchen muss. Und zum Thema FPGA: Ich würde definitiv die Serdes verwenden! Macht alles deutlich einfacher! Schöne Grüße
Danke! Ja, dieser DVI-Transmitter IP von Xilinx verwendet auch die SerDes. Allerdings will der eben auch den hohen Takt (10x Pixeltakt) haben. Wenn ich 1280x800@60 Hz mit normalen VGA Timings machen will, dann bräuchte ich 83.46 MHz Pixeltakt, das 10-fache schafft mein FPGA aber nicht. Ich könnte also 1280x800@30 Hz nehmen, das ginge gut, aber ich könnte auch 1280x800@60 Hz verwenden und die Blank Zeiten reduzieren. Dazu finde ich leider nichts in der HDMI Spezifikation. Hier https://www.fpga4fun.com/files/dvi_spec-V1_0.pdf auf Seite 32 steht nur, dass man eine 128 Pixel andauernde Pause benötigt und zwar spätetens alle 50 ms. Hier http://tinyvga.com/vga-timing/1280x800@60Hz ist der H_Blank aber 400 Pixel lang. Das mag ja für VGA Röhre mal sinnvoll gewesen sein, aber muss das bei HDMI heutzutage auch noch so lange sein oder kann ich die Blanks auf jeweils 128 Pixelzeiten zusammenstutzen? Edit: In der Tat ist das Encoding in dder Spezifikation Seite 29 gut beschrieben.
:
Bearbeitet durch User
Ich bin mir bei DVI/HDMI gar nicht sicher inwiefern man die Blank-Zeiten "manipulieren" darf. Du bist bei DVI/HDMI, im Gegensatz zu VGA, völlig digital unterwegs. Ich gehe momentan davon aus, dass es einen direkten Bezug zwischen Auflösung/Bild-Wiederholrate und digitalen Bitrate gibt - hier kann ich mich auch wirklich täuschen! SelectIO: Ich glaube, dass du SDR verwendest. Überprüfe mal und stelle dann auf DDR als Ausgang um, dann müsste eigentlich 5x Pixelclock reichen. Kann aber dann sein, dass du nur noch 5 Bit am Eingang, anstelle 10 Bit hast. Du brauchst dann für dein Design eine dritte Frequenz: PixClk, 2*PixClk, 5*PixClk
Angehängte Dateien:
-
tmds.png
150 KB
tja schrieb: > SelectIO: Ich glaube, dass du SDR verwendest. Ne, da steht DDR und serialisation factor 10. Ja, dann wäre das die 5-fache Frequenz ... naja, sehe ich gleich in der Simulation (-: tja schrieb: > Ich gehe momentan davon aus, dass es einen direkten > Bezug zwischen Auflösung/Bild-Wiederholrate und digitalen Bitrate gibt - > hier kann ich mich auch wirklich täuschen! Nun, laut Bilchen aus der Spec überträgt man ja explizit auch noch Hsync und Vsync. Da bräuchte es dann eigentlich keine langen Pausen als Blank. Aber werde ich sehen und schlicht ausprobieren wenn mein TMDS Encoder läuft. Irgendwann. Wobei das DE Signal ja angibt ob gerade Farbwerte oder die Controlsignale Übertragen werden. Ich muss mein DE also aus Hsync und Vsync erzeugen, quasi ein DE <= Hsync or Vsync;
:
Bearbeitet durch User
Angehängte Dateien:
-
dvi-transmitter.png
48 KB
Ja sehr schön Xilinx! Da verwendet man deren SelectIO IP und der liefert ... Konflikte. Ideen? Von Hand bauen mit einzelnen SerDes Blöcken? Edit: OK, man muss nur den Reset bedienen ... na gut, jetzt sieht alles fein aus.
:
Bearbeitet durch User
Moin, Gustl B. schrieb: > Wobei das DE Signal ja angibt ob gerade Farbwerte oder die > Controlsignale Übertragen werden. Ich muss mein DE also aus Hsync und > Vsync erzeugen, quasi ein > DE <= Hsync or Vsync; Obacht: DE ist dann aktiv, wenn echtes Bild uebertragen wird. Hsync und Vsync sind nur waehrend des Syncs aktiv. Aber inaktiv waehrend des "Blanks", also der Schwarzschultern. Die auch nicht zum Bild gehoeren. Das sind noch so Ueberbleibsel aus der analogen Videotechnik. Beim Timing hat man schon einiges an Freiheitsgraden, insbesondere, wenn kein "dolles" Audio uebertragen werden soll. Aber ich wuerd's fuer den Anfang einfach mal mit 640x480 VGA probieren, einfach weil das was ist, was vom Timing her noch gut abgehangen und ausgepatscht ist. Das funktioniert schon lange. Und wenn das mal laeuft, kann man natuerlich hergehen und beliebig Faxen treiben mit den Timings. Gruss WK
Dergute W. schrieb: > Obacht: DE ist dann aktiv, wenn echtes Bild uebertragen wird. Stimmt, danke! Dergute W. schrieb: > Beim Timing hat man schon einiges an Freiheitsgraden, insbesondere, wenn > kein "dolles" Audio uebertragen werden soll. Interessant. Audio werde ich nicht übertragen. Jetzt schreibe ich mir erst mal den TMDS Decoder für die Testbench. Aber die Spec ist ja witzig, auf Seite 31 https://www.fpga4fun.com/files/dvi_spec-V1_0.pdf steht einmal "D[9:0]" und dann geht es mit "case (D[0:9])" weiter. Ausserdem steht auf Seite 31 oft "D[7:0]", auf Seite 29 beim Encoder aber "D[0:7]". Man man man, irgendwie finde ich das schon wieder nicht so toll. Genau wie auf Sete 31 einmal entschieden wird anhand von "Active Data?", aber es ist unklar wie ich das feststelle. Muss ich da auf eines der 4 möglichen Bitmuster prüfen case 0010101011: C[1:0] : = 00; case 1101010100: C[1:0] : = 01; case 0010101010: C[1:0] : = 10; case 1101010101: C[1:0] : = 11; die nur vorkommen wenn "Active Data?" False ist? Edit: Hier http://bfiles.chinaaet.com/whpt/blog/20170919/1000008562-6364143185282736974850538.pdf ist einer neuere Spec. Aber da das alles abwärtskompatibel zu DVI ist, werde ich den Minimalumfang einbauen.
:
Bearbeitet durch User
Und es wird noch besser ... Der Xilinx DVI Transmitter bekommt zwei Takte, einmal den Pixeltakt und einmal den 5fachen Pixeltakt. Der schiebt die Daten dann auch schön als DDR mit dem 5fachen Takt heraus und legt den Pixeltakt auf die HDMI/DVI Taktleitung. Soweit so gut. Jetzt gibt es aber auch einen Xilinx DVI Receiver. Da kann man einstellen, dass der einen externen Takt verwendet. Allerdings braucht der dann den gleich den 5fachen Pixeltakt. Man kann den DVI Receiver also nicht einfach an das DVI hängen mit Clock und Daten, sondern man muss selber vorher eine PLL einbauen. Naja ...
Und noch eine Nachfrage: Stimmt das was ich hier https://www.fpga4fun.com/HDMI.html sehe in den kleinen Bildchen, also dass ein 10 Bit Wert mit dem LSB zuerst übertragen wird und dass die Clock während der ersten 5 Bits Low und während der höherwertigen 5 Bits High ist? Hier ist noch ein Bilchen das es anders zeigt, da werden die ersten Bits übertragen während die Clock High ist. Auch da ist aber ein Fehler im Bild, denn TMDS 2 kommt zweimal vor. Was stimmt denn oder wo finde ich da genauere Angaben in der Spec? Wo steht da ob zuerst das MSB oder LSB übertragen wird und ob die Bitreihenfolge zwischendrinnen umgekehrt wird? Edit: Tatsache, LSB First steht in der Spec.
:
Bearbeitet durch User
Moin, Gustl B. schrieb: > Man kann den DVI Receiver > also nicht einfach an das DVI hängen mit Clock und Daten, sondern man > muss selber vorher eine PLL einbauen. Mein Eindruck ist, dass die PLLs in FPGAs lange nicht so breitbandig zuverlaessig locken koennen, wie die PLLs in den entsprechenden "richtigen" Receiverbausteinen. Die fressen dann z.b. alles von 25...150MHz Takt. Das kriegt eine FPGA-PLL ohne Riesen-Affentheater aussenrum nicht hin. Gustl B. schrieb: > und dass die Clock während der ersten 5 Bits Low und > während der höherwertigen 5 Bits High ist? Die Clockphase sollte wurscht sein, dass muesste der Empfaenger im Rahmen seines line de-skewing in den Griff kriegen koennen. Gruss WK
Danke! Und: Hier in der Spec https://www.fpga4fun.com/files/dvi_spec-V1_0.pdf auf Seite 29 ist ein Fehler mit der Klammersetzung. Statt (Cnt(t-1)>0 AND(N1{q_m[0:7]}>N0{q_m[0:7]})OR(Cnt(t-1)<0 AND N0{q_m[0:7]}>N1{q_m[0:7]}) sollte es wohl (Cnt(t-1)>0 AND N1{q_m[0:7]}>N0{q_m[0:7]})OR(Cnt(t-1)<0 AND N0{q_m[0:7]}>N1{q_m[0:7]}) sein. Edit: Und was ist denn hiermit gemeint? Cnt(t) = Cnt(t-1) - 2*(~q_m[8]) + (N1{q_m[0:7]} - N0{q_m[0:7]}); Konkreter meine ich 2*(~q_m[8]) Ich interpretiere das so: 2*(~q_m[8]) = 2 wenn q_m[8] = '0' 2*(~q_m[8]) = 0 wenn q_m[8] = '1' Oder ist ~q_m[8] dann -1 wenn q_m[8] = '1'?
:
Bearbeitet durch User
Moin, Puuh - keine Ahnung; gibts da nicht vielleicht schon irgendwas auf Opencores, wo das schon fertig eingebaut ist? Gruss WK
Na klar gibt es das^^ aber das wäre doch zu einfach. Auch einfach wäre es die ganzen Möglichkeiten als eine dicke LUT zu hinterlegen. Derzeit baue ich mir eine Pipeline die das aber errechnen soll, mal gucken ob die später mal den Pixeltakt schafft.
Ich bin ein Depp. Habe hier sogar zwei USB-C nach DP Adapter (für mein Notebook) aber keinen von USB-C nach HDMI ... männo!
Moin, Tja, USB nach HDMI ist technisch auch deutlich aufwendiger als nach DP. Bei USB und DP ist das exakte Pixeltiming eher wurscht, da werden eh' immer irgendwelche Pakete verschickt. Bei HDMI faellts direkt auf, wenn da mal ein Takt lang kein Pixel kommt... Gruss WK
Dann sollte ich also auch noch DP einbauen ... ist das auch so "einfach" wie bei DVI/HDMI odder müsen die Pixeldaten da sehr viel komplizierter verpackt werden? Bei DVI/HDMI werden die ja nur stumpf für jedes Pixel neu kodiert und übertragen. Ohne Pakete und so. Leider hat DP recht hohe Frequenzen, das wird mein Spartan7 nicht schaffen. Edit: Schafft er nicht. Der kann maximal 1250 MHz SerDes.
:
Bearbeitet durch User
So, jetzt will ich mir selber ein Kabel löten, habe auch schon alles da, will aber herausfinden welches Adernpaar im HDMI Kabel zu welcher TMDS Lane gehört. Dazu habe ich Bildchen gesucht wie dieses hier: https://upload.wikimedia.org/wikipedia/commons/9/94/HDMI_Connector_Pins.jpg oder https://www.pc-magazin.de/bilder/27103616/500x300-c0/Service-Wissen-07-09.jpg oder https://www.elektroland24.de/out/pictures/master/product/7/busch-jaeger-0261_32-hdmi-anschlussdose_0261_32_7.png Und es fällt schon mal auf, dass sich die Farben unterscheiden. Aber bei beiden ist auf Pin 1, oder dem Stecker links oben eine + Ader gezeichnet. Wenn ich jetzt hier das Kabel durchmesse, dann ist dieser Pin aber mit der weißen Ader vom roten Pärchen verbunden. Wo gibt es dann da eine "Wahrheit"? Oder ist dann mein Billigkabel hier mit den falschen Farben verbunden? Edit: Die Belegung aus dem letzten Bildchen stimmt erstmal grob, aber in meinem Kabel sind die + Adern immer weiß und die - Adern bunt. Weil das aber bei allen 4 Lanes so ist, kann ich die auch vertauscht lassen.
:
Bearbeitet durch User
Sind bei DVI/HDMI der HSync und VSync wie bei VGA ebenfalls active LOW?
Moin, Gustl B. schrieb: > Sind bei DVI/HDMI der HSync und VSync wie bei VGA ebenfalls active > LOW? Erlaubt ist, was gefaellt - und wie's der Monitor gerne haette, steht in seiner EDID. Gruss WK
Tatsache! Und sehr interessant: https://github.com/linuxhw/EDID/blob/master/Digital/Fujitsu%20Siemens/FUS07B9/08F0764A4775 Hpol und Vpol sind nicht irgendwie fest, sondern mal beide N, mal beide P und einmal sogar Hpol N und Vpol P. Das ist zwar sehr schön wenn Hardware so flexibel ist, ist aber auch ein Nachteil wenn man zuerst eine EDID lesen muss und so. Mal gucken ob es auch anders funktioniert.
Angehängte Dateien:
-
640x480.jpg
300 KB
Da ist das Ding! Was war mein letztes Problem? Es lag an der Reihenfolge in der der SerDes die Bits ausgibt. Ich habe jetzt 4 solche SerDes eingebaut und betreibe die je nach Einsteckrichtung des USB-C Steckers mit unterschiedlichen Daten. Für die Clock gebe ich eben "1111100000" aus. Und weil ich auf meiner Platine aus Routinggründen bei zwei Paaren die N und P vertauscht habe, invertiere ich für den entsprechenden SerDes dann das Bitmuster. Bonusfrage: HDMI kennt ja nur eine Steckrichtung. Aber einen HDMI USB-C Adapter kann man in zwei Richtungen einstecken. Hat dann dieser Adapter den Pulldownwiderstand drinnen? Bei meinem selbstgelöteten Adapterkabel habe ich das so gemacht.
:
Bearbeitet durch User
Dergute W. schrieb: > Die Clockphase sollte wurscht sein, dass muesste der Empfaenger im > Rahmen seines line de-skewing in den Griff kriegen koennen. Tatsache. Ich kann die Clock problemlos um 180° verschieben.
Also 640x480 funktioniert, aber 1280x800 bringt (wenige) Bildfehler. Hm ... mal gucken wie das dann mit dem guten gekauften Kabel aussieht.
Krass wie weit man von den normalen Timings abweichen kann ... Bei 1280x800 hat man laut http://tinyvga.com/vga-timing/1280x800@60Hz 400 Pixel HBlank. Aber 39 Pixel funktionieren auch (weniger habe ich nicht getestet). Und damit sinkt die Bitrate sehr deutlich. 60 Hz muss man auch nicht schaffen, mein Monitor frisst laut eigenem Menü alles zwischen 50 Hz und 85 Hz. Und Tatsache, 50.2 Hz werden korrekt dargestellt. Jetzt bin ich bei 1280x800@55 Hz und 39 Pixeln HBlank (VBlank ist weiterhin 28 Zeilen). Damit ist der Pixeltakt von 83.46 MHz auf 60 MHz gesunken (ich habe die 39 Pixel HBlank so gewählt um auf genau 60 MHz Pixeltakt zu kommen). Und jetzt habe ich auch keine Pixelfehler. Ich bin tatsächlich sehr erstaunt was alles funktioniert. Hier https://tomverbeure.github.io/video_timings_calculator kann man sich viele Daten zu seiner Wunschauflösung rechnen lassen.
:
Bearbeitet durch User
Gustl B. schrieb: > Krass wie weit man von den normalen Timings abweichen kann ... Ja, die digitalen Displays sollten da ziemlich tolerant sein. Viel kritischer war es, wenn man früher zu VGA-Zeiten noch ein Quentchen mehr Auflösung oder Wiederholrate aus Grafikkarte und Röhrenmonitor rausholen wollte. Gruselige Zeiten, wo man in der X11-Config die Werte händisch modifiziert hat...
Moin, Naja, ist nicht sooo verwunderlich - so ein Nicht-Bildroehrenmonitor braucht ja eigentlich keine Austastluecken. Die in der Groesse sind ein Relikt aus den Zeiten, als man mit dem H-Ruecklauf die Hochspannung erzeugt hat und im V-Ruecklauf nicht zu schnell sein konnte, weils billig sein musste. Was widerum einem Roehrenmonitor wurst war, aber einen modernen Monitor zum ziemlichen Ausrasten bringt, ist wenn man mal in einer einzelne Zeile (gerne auch im Blanking/V-Sync) ein einzelnes Pixel mehr oder weniger ausgibt... Derweilen braucht man die Blankingzeiten "nur" noch, um Audio zu uebertragen. Da kanns dann mit so Faxenaudio "99.droelfzehn-Dolby-Spezial-UHD" wieder Probleme geben, wenn das alles nicht in die zu knapp bemessenen Blankings passt. Den Part mit dem USB-C check' ich so garnicht. Was hatsn damit aufsich? Achja: Koenntest du mal gucken, ob die Inversion einer/mehreren Lanes OK ist oder nicht? Bei 8B10B bin ich mir recht sicher, dass man das invertieren kann, bei TMDS grad nicht. Gruss WK
Angehängte Dateien:
-
leds.jpg
1,9 MB
Duke Scarring schrieb: > Ja, die digitalen Displays sollten da ziemlich tolerant sein. > Viel kritischer war es, wenn man früher zu VGA-Zeiten noch ein Quentchen > mehr Auflösung oder Wiederholrate aus Grafikkarte und Röhrenmonitor > rausholen wollte. Ja, echtes VGA hatte ich auch mal gemacht. Dergute W. schrieb: > Naja, ist nicht sooo verwunderlich - so ein Nicht-Bildroehrenmonitor > braucht ja eigentlich keine Austastluecken. Die in der Groesse sind ein > Relikt aus den Zeiten, als man mit dem H-Ruecklauf die Hochspannung > erzeugt hat und im V-Ruecklauf nicht zu schnell sein konnte, weils > billig sein musste. Jo, aber wieso macht man das denn immernoch? Man könnte doch auch Timings für digitale Bildschirme spezifizieren die dann mit weniger Pixeln auskommen. Dergute W. schrieb: > Was widerum einem Roehrenmonitor wurst war, aber einen modernen Monitor > zum ziemlichen Ausrasten bringt, ist wenn man mal in einer einzelne > Zeile (gerne auch im Blanking/V-Sync) ein einzelnes Pixel mehr oder > weniger ausgibt... Verständlich. Danke für den Hinweis. Dergute W. schrieb: > Derweilen braucht man die Blankingzeiten "nur" noch, um Audio zu > uebertragen. Da kanns dann mit so Faxenaudio > "99.droelfzehn-Dolby-Spezial-UHD" wieder Probleme geben, wenn das alles > nicht in die zu knapp bemessenen Blankings passt. Fine ich zwar nett, dass das geht, aber ... will man wirklich die Lautsprecher im Monitor nutzen? Ich habe das bisher noch nie getan. Dergute W. schrieb: > Den Part mit dem USB-C check' ich so garnicht. Was hatsn damit aufsich? Das liegt an meiner Bastelplatine (Anhang). USB-C ist eben klein und bietet viele Kontakte. Also habe ich den verlötet. Allerdings muss man dann eben auch die Steckrichtung erkennen und entsprechend die HDMI-Lanes anders mit Daten füttern. Dergute W. schrieb: > Achja: Koenntest du mal gucken, ob die Inversion einer/mehreren Lanes OK > ist oder nicht? Bei 8B10B bin ich mir recht sicher, dass man das > invertieren kann, bei TMDS grad nicht. Ich habe jetzt zwei Dinge ausprobiert: 1. Reihenfolge der Bits: Darf man nicht ändern. Das macht Pixelfehler. 2. Invertieren aller Bits einer Lane: Hm ... ja, geht, aber das Bild ändert sich. Ich bekomme weiterhin das Bild mit meinen Farbverläufen, aber die sind jetzt eben anders - aber weiterhin schöne Verläufe.
Gustl B. schrieb: > Krass wie weit man von den normalen Timings abweichen kann ... Das ist auch der Grund wieso ein Monitor (ohne groessere Modifikation) die ganzen G-Sync und Free-Sync oder wie die alle heissen unterstuetzt. Theoretisch gibt es genau 0 techische Gruende wieso ein nicht-Roehrenmonitor eine fixe Bildwiederholrate braucht. Das ist hisorisch bedingt nur aus Kompatibilitaetsgruenden so. Ich bin jetzt kein Displayport Experte, aber ich meine es gibt einen Modus (nicht kompatibel zu HDMI weswegen die mechanische Adapter auch nicht funktionieren) der einfach nur die Videodaten sendet, ohne an irgendwelche Video Timings gebunden zu sein (ausser natuerlich die Pixelclock). Da werden die Pixeldaten einfach zo dargestellt wie sie ankommen und am Ende wird wieder von vorne angefangen.
Moin, Gustl B. schrieb: > Fine ich zwar nett, dass das geht, aber ... will man wirklich die > Lautsprecher im Monitor nutzen? Ich habe das bisher noch nie getan. Ja, ich schaetz' mal, dass das halt aus der "HomeTheatre" Ecke kommt. Mir reicht da schon auch ein Stereopaar fuer den integrierten Bruellwuerfel. Gustl B. schrieb: > Das liegt an meiner Bastelplatine (Anhang). Aaah - jetzt faellt der Groschen auch bei mir. OK, mit den selbstgebastelten Strippen wirds dann natuerlich nicht leichter bei hoeheren Pixeltakten... Gustl B. schrieb: > 1. Reihenfolge der Bits: > Darf man nicht ändern. Das macht Pixelfehler. OK, ist klar. > 2. Invertieren aller Bits einer Lane: > Hm ... ja, geht, aber das Bild ändert sich. Aeh - hast du da jetzt die Bits alle vor dem TMDS Encoder invertiert oder danach? Gruss WK
Dergute W. schrieb: > Ja, ich schaetz' mal, dass das halt aus der "HomeTheatre" Ecke kommt. Guter Einwand! Die nutzen dann zwar nicht die Lautsprecher im Fernseher, aber der DVD-Player überträgt das Audio über HDMI zum Receiver. Dergute W. schrieb: > Aeh - hast du da jetzt die Bits alle vor dem TMDS Encoder invertiert > oder danach? Dahinter. Also zwischen Encoder und SerDes. Vor dem Encoder würde ich ja meinen Farbwert invertieren. ... Wobei ja auch so jetzt irgendwie der Farbwert verändert wurde. Seltsam ...
:
Bearbeitet durch User
Moin, Gustl B. schrieb: > Vor dem Encoder würde ich ja meinen Farbwert invertieren. ... Wobei ja > auch so jetzt irgendwie der Farbwert verändert wurde. Seltsam ... Merci, wollt nur nochmal sichergehen. Sieht also so aus, als sollte man bei TMDS nicht so einfach die +/- Leitungen ohne Inversion kreuzen. Gruss WK
Vermutlich, aber kann ich noch nicht sicher sagen. Zumindest bekomme ich weiterhin ein schickes Farbverlaufbild. Ich muss da mal irgendwas eindeutigeres hinlegen, Text oder ein Muster oder diesen Farbverlauf genauer angucken wo Pixel 0,0 ist und mit welcher Farbintensität wo begonnen wird.
Ich bin stinksauer das mir der Thread kapput gemacht wurde. Du und noch ein paar andere. Ich habe gleich im Eröffnungsposting geschrieben, das ich keine wirkliche Ahnung von FPGA's habe. Deshalb habe ich im FPGA Forum Hilfe gesucht. Ich wollte nicht, das Leute, denen man immer wieder erklären muss, "LED nur mit Vorwiderstand" etc. hier eine Basis Diskussion anfangen, ob meine Zeichnung auf Pappe funktioniert. Um denen den Wind aus den Segeln zu nehmen, werde ich eine LTspice Simulation machen. Ich habe gleich und immer wieder geschrieben, das die Masse in meiner Zeichnung nur lokal, nicht mit Erde verbunden ist. Nach aussen sind nur die beiden Buchsen, an denen der simulierte Kondensator zu sehen ist. Natürlich habe ich auch etwas gegen die Streukapazitäten im Köcher. Ich habe 1996 einen 6 seitigen Artikel in der Zeitschrift "Elektronik" (DSP56002) veröffentlicht. 2016 zwei Seiten im Funkamateur. Diplom Elektrotechnik TU habe ich 1992 gemacht. Meine Schwerpunkte liegen mehr auf Analog, RF, Leistungselektronik und Mikrocontroller. Ich hatte gehofft, das wir das als Crowdfunding Geschichte zusammen machen können. Diese Kapazitätsdekade ist für Lehre und Ausbildung, aber auch im Testfeld und Labor sehe ich Anwendungspotential. Als ich das erste Mal vor vielleicht 30 Jahren einen Motor mit Frequenzumrichter vor die Nase bekommen habe, habe ich auch gesagt, was soll der komplizierte Scheiss, es gibt doch Thyristorsteller.
Na dann erkläre doch mal wie du das genau machen willst. Mit der Schaltung aus deiner Zeichnung kannst du jedenfalls keinen Kondensator nachbilden. Ein Kondensator hat nämlich keine Richtung. Ich finde Crowdfunding auch ein gutes Konzept, aber eben nur für Ideen/Produkte die man auch bauen kann. Zuerst Geld einsammeln und dann doch nichts liefern ist Betrug, also zuerst darüber nachdenken wie man das bauen kann und dann Crowdfunden. Weil du vermutlich keinen echten Kondensator mit allen Eigenschaften nachbauen kannst, wäre es hilfreich ein erreichbares Ziel zu definieren. Also die Anforderungen soweit senken bis sie erreichbar werden. Aber ja ich bleibe dabei, mit nur zwei Anschlüssen kann man keinen Kondensator in allen Eigenschaften nachbilden. Warum geht das nicht? Also du hast deinen virtuellen Kondensator, der ist irgendwie geladen, die Software weiß natürlich wie. Ist aber egal. Jetzt wird einer oder beide Anschlüsse mit einem oder beiden Beinen eines externen geladenen Kondensators verbunden. Wie willst du jetzt entscheiden ob dein virtueller Kondensator an welchem der beiden Anschlüsse Ladungen aufnimmt oder abgibt? Und vor allem wie viel? Dein Gerät weiß nämlich nicht ob das angeschlossene Ding eine Drahtbrücke, ein 1pF oder ein 1F Kondensator ist. Oder vielleicht ist auch eine Induktivität oder eine Spannungsquelle angeschlossen. Mein Tipp wäre das erstmal zu simulieren. Also in Software zu bauen.
Aber wenn es dir nicht um die Umsetzung geht und das nicht diskutiert werden soll, dann stell doch konkrete Fragen. Fang an das in Software oder einer HDL zu schreiben und wenn es Probleme gibt helfen wir.
Wahhhh!! Falsches HyperRAM auf die Platine gelötet ... und zwar 7KS0642GAHI03 statt 7KS0642GAHI02. Warum ist das ein Problem? Ich habe die Pins PSC und #PSC nicht mit dem FPGA verbunden weil ich das DDR Center-Aligned Read Strobe (DCARS) nicht nutzen will. Jetzt wäre natürlich die Frage ob der Baustein mit DCARS das nur zusätzlich kann, oder ob der auch zwingend diese zusätzliche Clock braucht. Neuer RAM ist bestellt ... Edit: Jetzt war der USB-C nach HDMI Adapter in der Post. Nette Sache aber ... ich bekomme kein Bild. Mit meinem selbstgelöteten Adapter aber schon. Es könnte also sein, dass die Steckrichtung genau vertauscht ist, ja, habe ich schon ausprobiert, es gibt kein Bild. Ideen? Edit: Diese Deppen! In dem Adapter sitzt eine kleine Platine. Und auf der sind mehrere ICs. Einer sah auf den ersten Blick wie ein Redriver aus, ist es aber nicht. Der ps176hdm ist ein ... DP nach HDMI Converter M-) Tolle Wurst! Ich will das aber nicht, ich will einen HDMI-USB-C nach HDMI-HDMI-Stecker Adapter. Meinetwegen mit Redriver, aber ohne sonstiges Zeug. Leider steht das weder auf der Produktseite von Anker noch bei Amazon. Jetzt ist die Frage: Gibt es überhaupt einen Adapter oder Kabel wie ich es haben möchte? Oder wird über USB-C immer nur DP ausgegeben und jeder Adapter von USB-C nach HDMI hat daher einen DP nach HDMI Converter-IC drinnen? Eigentlich müsste es das egebn was ich will, denn HDMI über USB-C ist spezifiziert.
:
Bearbeitet durch User
So, ich habe jetzt ein schön geschirmtes Kabel gebaut. Dazu habe ich mir ein voll belegtes USB-C nach DP Kabel gekauft und statt dem DP einen HDMI Stecker angelötet. Der Vorteil von dem Kabel ist, dass bei jedem einzelnen Paar noch eine Litze als Masse dabei ist. Tja ... aber das Ergebnis ist ... es gibt Bildfehler. Aber was sehr seltsam ist, ist die Tatsache, dass die Bildfehler statisch sind. Ich bekomme in einem Bereich des Bildschirms ein gelbes Rechteck und in den ersten vielleicht 50 Zeilen ein paar gelbe Streifen in einem festen horizontalen Bereich. Der Rest des Bildes ist fehlerfrei. Das sieht für mich also so aus, also würde das Kabel die Datenrate schaffen, sonst würde ich nämlich zufällige Fehler an beliebigen Positionen erwarten. Weil es aber bei niedrigerer Datenrate fehlerfrei aussieht suche ich nach einer Erklärung wie so statische Fehler entstehen können. Ich kann mir das nicht erklären. Jedenfalls verwende ich jetzt 1024x640@60Hz und das ist wunderbar fehlerfrei bei 50 MHz Pixeltakt. Bin sehr zufrieden.
Moin, Gustl B. schrieb: > Weil es aber bei niedrigerer Datenrate fehlerfrei aussieht suche ich > nach einer Erklärung wie so statische Fehler entstehen können. Ich kann > mir das nicht erklären. Werden denn alle constraints eingehalten, die du aufgestellt hast und hast du welche? Gruss WK
Duke Scarring schrieb: > Hast Du mal die Autotune-Taste am Monitor probiert? Gute Idee, mache ich mal. Dergute W. schrieb: > Werden denn alle constraints eingehalten, die du aufgestellt hast und > hast du welche? Ich habe die Clock die ins FPGA reingeht constraint. Aber sonst bisher nichts. Aber könnte ich auch mal machen ... aber von Constraints in Kombination mit SerDes habe ich noch keine Ahnung.
Moin, Gustl B. schrieb: > aber von Constraints in > Kombination mit SerDes habe ich noch keine Ahnung. metoo - aber dein Fehlerbild scheint mir schon in diese Richtung zu gehen. Gruss WK
Thread beobachten
Seitenaufteilung abschalten
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.