Forum: FPGA, VHDL & Co. HDMI/TMDS am Spartan7 mit VCCO 1.8V


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Tim (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Videomann (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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?

von PCB (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Tim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von PCB (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du noch genügend Pins frei hast, dann könntest du auch einen 
HDMI-Receiver/Transmitter ranknallen, der das physikalische Ebene 
regelt.

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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!

von PCB (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Tim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von tja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von tja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Gustl B. (-gb-)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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 ...

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Puuh - keine Ahnung; gibts da nicht vielleicht schon irgendwas auf 
Opencores, wo das schon fertig eingebaut ist?

Gruss
WK

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (-gb-)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, da ist das Ding.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Sind bei DVI/HDMI der HSync und VSync wie bei VGA ebenfalls active LOW?

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (-gb-)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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
von Gustl B. (-gb-)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Also 640x480 funktioniert, aber 1280x800 bringt (wenige) Bildfehler. Hm 
... mal gucken wie das dann mit dem guten gekauften Kabel aussieht.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sprudelstrudel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von -gb- (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von -gb- (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
Wieso schreibt ihr das nicht einfach dort, wo's hingehört?

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hast Du mal die Autotune-Taste am Monitor probiert?

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.