www.mikrocontroller.net

Forum: FPGA, VHDL & Co. DVI-Signal mit FPGA generieren


Autor: Benjamin Meier (mebe90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen.

Ich bin gerade dabei mich in FPGAs einzuarbeiten,
da ich ein Projekt habe, wofür ein FPGA wohl das richtige ist.

Das Projekt:
Ich möchte einen Print entwickeln, der einen DVI-Ausgang hat (wenn 
möglich auch einen VGA). Im FPGA möchte ich mit der Software in einem 
soft-core (wahrscheinlich Cortex-M1) definieren können, was auf dem 
Bildschirm angezeigt werden soll. Das Board soll dann eingesetzt werden, 
um eine Modelleisenbahn oder ähnliches zu überwachen. Damit ich die 
Daten etwas anschaulich darstellen und animieren kann, möchte ich einen 
Bildschirm anschliessen können. Die rohdaten erhalte ich von einem 
Steuerungssystem über einen CAN-Bus.

Die Frage:
Hat jemand von euch bereits ein ähnliches Projekt gemacht, oder weiss 
wie ich das mit dem DVI am besten mache? Ich nehme an, dass ich um einen 
externen Chip zum Generieren des DVI-Signals sowieso nicht herum komme. 
Kann jemand einen solchen Chip empfehlen? Gibt es evtl. einen 
FPGA-Programmier-Baustein, der mir die Kommunikation mit dem Chip 
bereits abnimmt, oder gar einen, der das Bild aus linien, Texten, 
Rechtecken, Dreiecken,... zeichnet??

Besten Dank im Voraus

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TFP410A, und ja ich arbeite gerade an einem ähnlichen Projekt. Nach 3 
Stunden konnte ich eine kleine Farbanimation mit Altera Cyclone III c120 
+ TFP410A auf einem 1680x1050x60Hz TFT darstellen. Ist wirklich sehr 
einfach. Das Design zur Erzeugung des UXGA-DVI Signales hat 143 Zeilen 
VHDL und benötigt 217 LEs. Aber auch nur weil schon eine farbige 
Animation damit dargestellt wird.

Der Core zur Erzeugung des DVI Timings ist identisch zu jedem VGA 
Testbild Generator und echt simpel.

Komplizierter wird es erst wenn du die Frames in einen externen RAM 
ablegst und von dort holen musst.

Nutzt du Altera Quartus hast du schon eine Video-DSP MegaCore Library 
drinnen. Mit der kannst du diese DVI Chips direkt ansteuern, samt DSP 
Funktionen zur Bildbearbeitung, Avalon Video Streaming und Framebuffer 
mit Anbindung an zb. DDR2 SDRAM.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch einen Tipp von mir. Die neueren DVI kompatiblen TFTs unterstützen 
das "CVT reduced blanking". Die HSync und VSync Zeiten sind also auf 5% 
reduziert gegenüber normalem CVT Modus. Ein zb. 1680x1050x60Hz CVT Modus 
hat einen Pixeltakt von 146.25MHz. Mit reduced Blanking sind es nur noch 
120MHz.

Gruß Hagen

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie geht das denn, ist das dann intern gepuffert? Der H-Takt muesste 
doch derselbe sein, lediglich die Austastpixel sind weniger. 
??????????????

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Korrekt, die H-Sync Zeiten sind verkürzt und das ermöglicht es den 
Pixeltakt bei gleicher Auflösung und Framerate zu reduzieren. Puffern 
muß man dafür aber nichts. Der DVI Wandler Chip bekommt an seinen 
Eingängen RGB[23..0], HSync, VSync, DE und IDCK (evtnl. differientiell 
wenn man möchte). Man sendet pro Zeile erstmal x Pixel über RGB[23..0] 
bei aktiviertem DE. In den Sync-Phasen setzt man DE immer low. Nach den 
Pixeln also DE=Low. An IDCK der Pixeltakt. Für 1680x1050 also 1680 IDCK 
Takte DE=High und die Pixel an RGB[]. Danach HSync Phase mit DE=low, 48 
Takte HSync=0, 32 Takte HSync=1 und wieder 80 Takte HSync=0. Also 
Backporch +HSync +Frontporch. Bei CVT reduced Blanking ist die HSync 
Phase immer 160 Pixeltakte lang. Die VSynczeiten sind 3 + 6 + 30. Dh. 
die 6 Zeilen VSync müssen 460µs ergeben bei dem berechneten Pixeltakt 
von 120MHz und 60Hz Framerate.

Das wäre das Format für DVI-Single-Link Displaymodis. Natürlich 
unterstützen diese DVI Treiber auch den Dual-Link-Modus bei dem 2 Pixel 
auf 2 Taktflanken übertragen werden. Allerdings steuert man sie dan 
meistens so an das man 2 Pixelports hat, für geraden und ungeraden Pixel 
also 48 Bits.

Dazu sollte man sich aber in den DVI, VESA, DDC Standards einarbeiten. 
Englisches Wikipedia ist ein guter Anfang.

Würde man CVT reduced Blanking mit dem Pixeltakt von CVT ausgeben so 
erhöht man die Framerate auf 73Hz bei 1680x1050'er Auflösung.

Gruß Hagen

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D.h. der Chip puffert das Timing?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein wie kommst du darauf ? Oben habe ich es doch deutlich erklärt.

Generell werden alle Monitore im Pixeltakt angesteuert. Nur in den 
Takten in denen das Bild übertragen wird sendet man die Pixeldaten. 
Deren Anzahl entspricht der gewünschten Displayauflösung. Hinzukommen 
pro Zeile H-Sync Phasen in denen keine Pixel übertragen werden sondern 
Synchronisierungssignale. Es ergibt sich zb. bei 1680x1050 eine absolute 
Pixelauflösung von 1840x1089 Pixeln beim CVT reduced Blanking und diese 
werden mit 120MHz gesendet. Rechne es nach 120MHz/1840/1089=60Hz 
Framerate.

Nichts mit puffern oder sonstwas, es ist ganz simpel.

Arbeitet man mit normalem CVT Timing eröht sich meistens die Anzahl der 
Takte für das H-Blanking pro Pixelzeile und damit muß man den Pixeltakt 
inkrementieren um auf die gleiche Framerate zu kommen.

Der Unterschied ist also das man weniger "Daten" insgesamt pro Frame 
senden muß weil man die Anzahl der Blanking Takte reduziert hat auf 5% 
des normalen Timings. Ein TFT Monitor hat keinen Elektronenstrahl wie 
beim CRT Monitor und benötigt daher keine Rücklaufzeiten um den 
Elektronenstrahl wieder an den Anfang der Zeile/Bildes zu positionieren. 
Deswegen kann man bei diesen mit CVT reduced Blanking arbeiten. Und das 
reduziert die nötige Bandbreite die man über das Kabel übertragen muß. 
Beim DVI geht dies sequientiell Bit für Bit für RGB getrennt und 
differientiell über zwei Adern pro Farbe in 8b10b Codierung. Dh. pro 8 
Bit pro Farbewert für jeweils RGB werden 10Bit differientiel übertragen. 
Pro 10Bit Packet mit beim obigen Bsp. 120MHz, ergibt einen effektiven 
DVI-Datenstromtakt von 1.2GBit/s und das *4 für RGB und Control Kanal in 
parallel. Das zeigt das man nach Möglichkeit diesen hohen Takt 
reduzieren sollte, besonders wenn es for free ist wie beim CVT reduced 
Blanking Timing. Denn das reduziert die Strörungen bei der 
Datenübertragung und das wiederum erhöt die Qualität der 
Displaydarstellung. Man kann das auf dem TFT sehr gut erkennen, benutzt 
man CVT-RB im Vergleich zu CVT mit hohen HDTV Auflösungen wird man 
erkennen das das Bild verschwommener aussieht als beim CVT-RB.

Wenn deine Grafikkarte im Computer den CVT-RB-Modus unterstützt und du 
benutzt einen TFT dann sollte man diesen auch aktivieren, egal ob man 
den TFT per DVI oder analog angeschlossen hat. Das erhöht sichtbar die 
Bildschirmqualität der Darstellung.

Zudem gilt für DVI folgende Regel: ist der Pixeltakt höher als 165MHz so 
muß dieser Grafikmodus im Dual statt Singlelink Modus üerbtragen werden. 
Dh. statt pro Takt nur 1 Pixel zu übertragen wird man 2 Pixel pro Takt 
übertragen müssen, also auf beiden Flanken des Taktes. Vor oder nach dem 
DVI Wandler Chip (TFP401A oder TFP410A) wird man dann einen 48Bit 
breiten Datenbus benutzen der mit 2 Pixeln pro Pixeltakt 
gefüttert/gelesen wird.

Benutzt man nun aber CVT reduced Blanking so reduziert man den Pixeltakt 
deutlich und somit kann man auch höhere Bildschirmauflösungen noch im 
Singlelink Modus benutzen bei denen man ansonsten schon den Duallink 
Modus benutzen müsste. So kann man HDTV bis 1920x1200x60Hz im Singlelink 
benutzen. Da noch nicht viele TFTs den Duallink Modus unterstützen kann 
man so auch auf diesen Teilen höhere Auflösungen fahren.

Lade dir das Datenblatt, schaue dir den DVI, CVT und DDC Standard an.


Gruß Hagen

Autor: Benjamin Meier (mebe90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!

Der Chip scheint gut zu sein.
Habe ein Board gefunden, das diesen Chip verwendet.
Ist gedacht, um mit dem Altera Cyclone III Board zu verwenden.

http://www.bitec.ltd.uk/hsmc_dvi.html

Ist die MegaCore-Library auch verfügbar, wenn ich das FPGA im 
Altium-Designer programmieren will? (Bin mit Altium halt von der 
Board-Entwicklung schon ziemlich vertraut.)

Ist es denn möglich ohne externen RAM Eine Bedienoberfläche zu gestalten 
und diese Live zu generieren? Ich denke da an Rechtecke mit Text, kleine 
Symbole, um die Oberfläche anschaulicher zu gestalten...
Oder muss ich die Anzeige in ein RAM generieren und anschliessend durch 
den DVI-Teil an den Bildschirm senden lassen?

Ich möchte natürlich möglichst klein bleiben, wieviel RAM benötige ich 
allenfalls, konkrete Chips??

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Exakt dieses Board + DevKit habe ich auch, auch dort gekauft da es als 
Bundle günstiger ist. Allerdings ist die Qualität der Doku und des einen 
sinnvollen Beispieles wirklich schlecht. Mit den Beispielen von Altera 
zu den Video MegaCores kann man mehr anfangen.

>Ist die MegaCore-Library auch verfügbar, wenn ich das FPGA im
>Altium-Designer programmieren will?

Das weiß ich nicht schätze aber schon da es IP-Cores sind. Eventuell 
kann es Probleme mit den durch Altera verschlüsselten Designfiles geben.
Wenn ich mich recht besinne müsste Altium ebenfalls ein solches DVI 
Board anbieten (wobei mir diese Firma einfach zu teuer ist, trotz 
derzeitiger Sonderangebote).

>Ist es denn möglich ohne externen RAM Eine Bedienoberfläche zu gestalten
>und diese Live zu generieren? Ich denke da an Rechtecke mit Text, kleine
>Symbole, um die Oberfläche anschaulicher zu gestalten...
>Oder muss ich die Anzeige in ein RAM generieren und anschliessend durch
>den DVI-Teil an den Bildschirm senden lassen?

Möglich dürfte Alles sein, ob es sinnvoll oder praktikabel ist ist eine 
andere Frage. Ich würde schon mit einem Framebuffer arbeiten, genau 
genommen sogar mit zwei oder sogar drei Framebuffern.

Du könntest dich an die Altera Beispiele halten und einen NiosII 
Prozessor, FrameBuffer, Avalon Memory Manager/Streaming Bus, DVI Video 
Output Core und DDR2 SDRAM High Performance Controller benutzen. Das 
kann man in Quartus über den SOPC Builder einfach zusammen klicken. 
Fehlt noch den NiosII Prozessor mit einem Programm zu füttern, fertig 
ist deine CPU mit integrierter DVI Grafikkarte.

>Ich möchte natürlich möglichst klein bleiben, wieviel RAM benötige ich
>allenfalls, konkrete Chips??

Na du fragst Sachen. RAM Bedarf hängt von deinem Konzept ab und 
besonders von deiner gewünschten Displayauflösung. Das kannst du dir 
aber auch selber ausrechnen. zb. 1024*768*24Bit Pixel in 2 Framebuffern 
benötigt 1024*768*3*2 = 4.5MBytes.

Einen RAM Buffer wirst du aber mit Sicherheit benötigen meiner Meinung 
nach. Du möchtest ja ein Videobild wiederholt und permanet anzeigen. 
Aber der Inhalt dieses Videobildes wirst du nur mit der Geschwindigkeit 
der Benutzerinteraktionen verändern in der meisten Zeit. Ergo musst du 
das Videobild auch zwischen speichern. Man könnte zwar theoretisch für 
jeden Vdeoframe alle Zeichenoperationen live bei Erzeugung des Frames 
durchführen aber denke mal drüber nach wie das bei einer zb. schrägen 
Linie quer über das Bild gehen soll. Denn den Frame sendest du immer 
zeilenweise über DVI die Line zeichnest du aber iA. schräg mit Random 
Access in den Videobuffer.
Über Fonts, Kreise und dergleichen wolllen wir garnicht mehr nachdenken.
Der FPGA erzeugt für den DVI Chip einen kontinulierlichen Video Stream. 
Der FPGA muß also irgendwoher seine Videostream Datenb bekommen und das 
ist in der Regel aus einem externen Speicher.

In meinem Projekt arbeite ich mit 3 Framebuffern und 1920x1200. Werde 
DDR2-SDRAM-ECC Module einsetzen (Server DIMMs) und habe so einen 72Bit 
breiten Datenbus. Intern also 144Bit Datenbus und somit bearbeite ich 6 
Pixel pro Datenword in einem Rutsch. Man muß schon ganz genau wissen wie 
man die Latenzen der DDR2 SDRAMs am besten ausgleicht. In meinem Falle 
werden immer 4 Datenwörter a 144 Bit = 24 Pixel gelesen und geschrieben 
im DDR2 SDRAM, also ein 2*2'er Burst. Das muß man machen da die DDR2 
Controller/Speicher nur im Burstmodus auch ihren theoretischen 
Datendurchsatz erreichen. Da ich mit dem TFP401A ein max. 1920x1200 HDTV 
Bild entgegenehme und dieses maximal mit 100Hz rausgeben muß hat man 
eine hohe Bandbreite beim Umschaufeln der Videodaten.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bachte auch das jenachdem welche Bestandteile du aus der Altera 
Video-DSP Library benutzt du auch Lizenzen dafür abdrücken musst. Das 
ist nicht gerade billig.

Autor: Benjamin Meier (mebe90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr gut,

dann werde ich mir wohl mal so ein Board besorgen und die Grenzen ein 
wenig auschecken, schauen, wie ich was machen will.

Danke für eure Hilfe.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re schrieb:
> Zudem gilt für DVI folgende Regel: ist der Pixeltakt höher als 165MHz so
> muß dieser Grafikmodus im Dual statt Singlelink Modus üerbtragen werden.
Wie sieht es aus, wenn der Takt niedriger ist?
Ich habe ein DVI-Design, das nur mit 108MHz läuft und dennoch doppelt 
überträgt. (DDR-Ausgänge im FPGA).

Ich nehme an, dass der Transceiverchip dafür paramteriert werden muss?

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re schrieb:
> Zudem gilt für DVI folgende Regel: ist der Pixeltakt höher als 165MHz so
> muß dieser Grafikmodus im Dual statt Singlelink Modus üerbtragen werden.
Wie sieht es aus, wenn der Takt niedriger ist?
Ich habe ein DVI-Design, das nur mit 108MHz läuft und dennoch doppelt 
überträgt. (DDR-Ausgänge im FPGA).

Ich nehme an, dass der Transceiverchip dafür paramteriert werden muss?

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> Wie sieht es aus, wenn der Takt niedriger ist?
Dann brauchst Du nur einen Link.

> Ich habe ein DVI-Design, das nur mit 108MHz läuft und dennoch doppelt
> überträgt. (DDR-Ausgänge im FPGA).
Auch dieser eine Link (=single-link) nutzt DDR auf den Datenleitungen.

> Ich nehme an, dass der Transceiverchip dafür paramteriert werden muss?
Was ist denn Dein eigentliches Problem?

Duke

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
>> Ich nehme an, dass der Transceiverchip dafür paramteriert werden muss?
> Was ist denn Dein eigentliches Problem?
Das das Beispiel von Xilnx nicht für die gewünschte Bandbreite geht, 
obwohl es auch ohne reduced blanking oder zweiten link auskommen müsste.

Soweit ich das sehe, werden die 3x8Bit als 12x2 korrekt übertragen, 
allerdings wundere ich mich über das timing und den Umstand, das Xlinx 
das nicht als DDR constrainen will.

Ich habe denselben Effekt wie an einer anderen Stelle im Design (hier 
beschrieben):
Beitrag "Xilinx IO constraints werden ignoriert"

Ungeachtet dessen habe ich noch ein Verständnisproblem:

Angenommen, das timing ist so korrekt (12 Bit x DDR) = 24 Bit je 
Videopixeltakt, wie passt dass dann zu der Aussage von Hagen oben?

Hagen Re schrieb:
> Zudem gilt für DVI folgende Regel: ist der Pixeltakt höher als 165MHz
> so muß dieser Grafikmodus im Dual statt Singlelink Modus üerbtragen
> werden. Dh. ... 2 Pixel pro Takt übertragen,
soweit klar
> also auf beiden Flanken des Taktes.
misverständlich!

Gemeint ist wohl "2Pixel auf 2 Pfaden" und ZUDEM (wie gehabt) 2 
Datenworte auf beiden Flanken.

Dafür spricht:

> Vor oder nach dem DVI Wandler Chip (TFP401A oder TFP410A) wird man
> dann einen 48Bit breiten Datenbus benutzen
> der mit 2 Pixeln pro Pixeltakt gefüttert/gelesen wird.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
>> Was ist denn Dein eigentliches Problem?
> Das das Beispiel von Xilnx nicht für die gewünschte Bandbreite geht,
> obwohl es auch ohne reduced blanking oder zweiten link auskommen müsste.
Du erwähnst gerade zum ersten Mal ein Beispiel von Xilinx. Welches? 
Link? XAPP?

> Soweit ich das sehe, werden die 3x8Bit als 12x2 korrekt übertragen,
> allerdings wundere ich mich über das timing und den Umstand, das Xlinx
> das nicht als DDR constrainen will.
Ich kenne nur das DVI-Design aus der grlib. Dort kommen DDR-FFs zum 
Einsatz. Da die sowieso in den IOBs sitzen, braucht man m.E. auch nicht 
viel zu constrainen.


> Ungeachtet dessen habe ich noch ein Verständnisproblem:
>
> Angenommen, das timing ist so korrekt (12 Bit x DDR) = 24 Bit je
> Videopixeltakt, wie passt dass dann zu der Aussage von Hagen oben?
Zitat Wikipedia[1]:
"Single-Link-Verbindung (max. 3,72 GBit/s) oder eine 
Dual-Link-Verbindung (max. 7,44 GBit/s)"

24 Bit/Pixeltakt * 165 MHz = 3960 MBit/s
mehr geht halt über die paar Adern mit diesem Standard nicht rüber.

> Hagen Re schrieb:
>> Zudem gilt für DVI folgende Regel: ist der Pixeltakt höher als 165MHz
>> so muß dieser Grafikmodus im Dual statt Singlelink Modus üerbtragen
>> werden. Dh. ... 2 Pixel pro Takt übertragen,
> soweit klar
>> also auf beiden Flanken des Taktes.
> misverständlich!
>
> Gemeint ist wohl "2Pixel auf 2 Pfaden" und ZUDEM (wie gehabt) 2
> Datenworte auf beiden Flanken.
Ja. Das ist misverständlich.
Single-Link nutzt 3 differentielle Päärchen, bei Dual-Link sind es 6.
Das Interface des Adapterchips kann aber wieder anders ausfallen.

Duke

[1] http://de.wikipedia.org/wiki/DVI

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist ein Beispiel-Code aus dem S6-VideoKit von Xilnx.

Autor: Michel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re schrieb:
> Es ergibt sich zb. bei 1680x1050 eine absolute
>
> Pixelauflösung von 1840x1089 Pixeln beim CVT reduced Blanking und diese
>
> werden mit 120MHz gesendet.

Geht das Prozedere auch mit analog VGA?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michel schrieb:
> Hagen Re schrieb:
>> Es ergibt sich zb. bei 1680x1050 eine absolute
>>
>> Pixelauflösung von 1840x1089 Pixeln beim CVT reduced Blanking und diese
>>
>> werden mit 120MHz gesendet.
>
> Geht das Prozedere auch mit analog VGA?

Vom Timing, Bildschirmbuffer usw. sollte es gleich sein. Statt aber nun 
den zB. 24Bit RGB Pixelstrom an einen DVI Treiber Chip zu übergeben wird 
mit drei DACs (zB. R2R) für RGB getrennt drei analoge Signale erzeugt. 
Je nach RGB Anbindung werden noch die Steuersignale HSync und/plus/xor 
VSync mit übertragen. Es gibt auch RGB über nur 3 Leitungen, dann wird 
im Grün Kanal das HSync/VSync Signal gemischt übertragen. Also je nach 
HSync/VSync Anbingung kann man mit 3 bis 5 Leitungen arbeiten.

Gruß hagen

Autor: Michel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, aber woran erkennt der Monitor, dass in diesem reduced mode gefahren 
wird?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm, ich denke überhaupt nicht. Bei modernen TFTs sind die Austastlücken 
unnötig und somit vertragen sie CVT RB von Hause aus, dh. ihnen sind die 
Austastlücken egal, Hauptsache sie sind noch minimal vorhanden um auf 
den Stream synchronisieren zu können. Herkömmliche CRT Monitor dagegen 
können mit CVt RB nichts anfangen.

Die entscheidende Frage ist eher: woran erkennt die Grafikkarte das sie 
CVT RB mit dem angeschlossen Monitor benutzen kann ? Und das beantwortet 
das oben angesprochene DDC Protokoll: ein 128 Bytes I2C EEPROM das im 
Monitor residiert und von der Grafikkarte ausgelsen werden kann. In 
diesem EEPROM sind im DDC Format die untersützten Bildschirmauflösungen 
samt Timing gespeichert.

Gruß hagen

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin neu in der Videoverarbeitung und bin mir nicht sicher ob 
folgende Rechnung stimmt.

Ich steuere ein TFT Monitor mit Reduced Blanking über eine DVI 
Schnittstelle an.
Auflösung: 1280x1024
Bildwiederholfrequenz: 60Hz
VSync gesamt: 160 Pixeltakte
HSync gesamt: 39 Zeilen (Da bin ich mir nicht sicher, wieviele Zeilen 
ich da brauche, bzw. wie sich das berechnet)


Pixelfrequenz = (1280 + 160) x (1024+39) x 60 = 91,8432 MHz

Muss ich jetzt, um ein DVI Signal zu erzeugen einen Pixeltakt von 91 MHz 
nehemen und die HSync-Zeit entsprechend verkürzen?

Danke schonmal!

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Chip hast Du?

Autor: Dr. Schnaggels (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>VSync gesamt: 160 Pixeltakte
>HSync gesamt: 39 Zeilen

Dann wäre der HSync ja länger als der VSync ...

Autor: franke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Format: 1280 x 1024 @ 60 Hz - Reduced Blanking
VESA CVT Name: 1.31M4-R


  HOR PIXELS        1.280  PIXELS
  VER PIXELS        1.024  LINES
  HOR FREQUENCY        63.194   kHz
  ACTUAL VER FREQUENCY        59.957   Hz
  PIXEL CLOCK        91.000   MHz      1  PIXELS
  CHARACTER WIDTH         87.912   ns      8  PIXELS
  SCAN TYPE        NON-INT
  ASPECT RATIO        5:4
  HSYNC POLARITY        POSITIVE
  VSYNC POLARITY        NEGATIVE


  HOR TOTAL        15.824   us  180  CHARS  1.440  PIXELS
  HOR ADDR        14.066   us  160  CHARS  1.280  PIXELS


  HOR BLANK        1.758   us  20  CHARS  160  PIXELS
  HOR BLANK+MARGIN        1.758   us  20  CHARS  160  PIXELS
  PREDICTED H BLANK DUTY CYCLE        25.252   %
    (from GTF blanking formula)
  ACTUAL HOR BLANK DUTY CYCLE        11.111   %
  ACT. HOR BLNK+MARGIN DUTY CYCLE        11.111   %
  H LEFT MARGIN         0.000   us  0  CHARS  0  PIXELS
  H FRONT PORCH         0.527   us  6  CHARS  48  PIXELS
  HOR SYNC        0.352   us  4  CHARS  32  PIXELS
  H BACK PORCH        0.879   us  10  CHARS  80  PIXELS
  H RIGHT MARGIN        0.000   us  0  CHARS  0  PIXELS


  VER TOTAL        16.679   ms      1.054.0   LINES
  VER ADDR        16.204   ms      1.024.0   LINES


  VER BLANK        0.475   ms      30.0   LINES
  V TOP MARGIN        0.000   us      0.0   LINES
  V FRONT PORCH        47.473   us      3.0   LINES
  VER SYNC        110.769   us      7.0   LINES
  V BACK PORCH        316.484   us      20.0   LINES
  V BOTTOM MARGIN        0.000   us      0.0   LINES

Hab da mal was rausgesucht... sorry für s Format...

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist ja ein absolut tolles Format. 91MHz lassen sich ja so einfach 
erzeugen. Da nehme ich aber lieber non-reduced blanking bei 108MHz oder 
135MHz mit mehr Wiederholrate.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, hab in meinen Angaben HSync und VSync vertauscht.

Natürlich H-Sync 160 Pixeltakte nach den Pixels für eine Zeile und 39 
Zeilen für das V-Sync Signal. Aber wie beschrieben, habe ich keine 
Ahnung wie ich auf die Anzahl V-Sync Takte komme!

Es handelt sich um ein Evalboard von Lattice mit einem LCP3-70EA (HDR-60 
Kamera Evalboard). Das DVI Interface wird direkt über eine 
SERDES-Schnittstelle verbunden.

Autor: Dimi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat schon jemand versucht die DVI bzw. HDMI ohne extra IC anzusteuern? 
Spartan 6 Board von Digilent hat ja keinen Chip. Ist es ohne weiteres 
möglich 1024x768@50/60Hz mit Spartan 3 / Cyclone II zu erzeugen?

MfG

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimi schrieb:
> Hallo,
>
> hat schon jemand versucht die DVI bzw. HDMI ohne extra IC anzusteuern?
> Spartan 6 Board von Digilent hat ja keinen Chip. Ist es ohne weiteres
> möglich 1024x768@50/60Hz mit Spartan 3 / Cyclone II zu erzeugen?
>
> MfG

Nein,  1024x768@50/60Hz braucht im reduced Blanking 91 MHz Pixeltakt.
Mal 10 -> Bitrate an den Pins: 910 Mbit/s. Das ist zuviel für den 
Spartan3

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die SERDES müssten das doch können (?)

Autor: Dimi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe eben im Inet gefunden...

  # 1024x768 @ 60.00 Hz Reduced Blank (CVT)
  #   field rate 59.87 Hz; hsync: 47.30 kHz; pclk: 56.00 MHz
  Modeline "1024x768_60.00_rb"  56.00  1024 1072 1104 1184  768 771 775 
790  +HSync -Vsync

Pixelclock ist 56MHz, oder 560Mbit/s

Vielleicht geht das?

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig. Die Serdes sind schnell genug für eine direkte Ausgabe des DVI 
Signals. Leider reagiert mein angeschlossener Bildschirm nicht.

Ich hab folgendes nützliches Tool gefunden:
http://sourceforge.net/projects/umc/?source=dlp

Mit dem Tool kann man sich den Pixelfrequenz und die Anzahl HSync/VSync 
Taktzyklen berechen lassen.

Jetzt eine andere Frage:
Eine Verbindung über DDC ist nicht zwingend nötig oder?

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uli schrieb:
> Die SERDES müssten das doch können (?)

Ja, nur hat der Spartan 3 keine Highspped SERDES

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe schrieb:
> Richtig. Die Serdes sind schnell genug für eine direkte Ausgabe des DVI
> Signals. Leider reagiert mein angeschlossener Bildschirm nicht.

Welcher FPGA?



>
> Ich hab folgendes nützliches Tool gefunden:
> http://sourceforge.net/projects/umc/?source=dlp
>
> Mit dem Tool kann man sich den Pixelfrequenz und die Anzahl HSync/VSync
> Taktzyklen berechen lassen.
>

> Jetzt eine andere Frage:
> Eine Verbindung über DDC ist nicht zwingend nötig oder?

Hängt möglicherweise vom Monitor ab, je älter desto grösser die Chance 
dass er ohne auskommt.

Es gibt noch eine weitere Falle.
Der FPGA gibt normalerweise LVDS aus, DVI/HDMI ist aber CML mit Pullups 
gegen 3.3V. Also Datenblätter und APP Notes durchforsten.

Autor: Dimi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch einen DE0-nano Board rumliegen. Er hat einen Cyclone IV 
onboard. Vielleicht geht es damit. Ich werde die nächste Zeit eine 
kleine Adapterplatine mit HDMI-Buchse basteln und dann probiere ich es 
aus.

Welche kleinste Auflösung "versteht" HDMI???
Habe gerade mit CTV-Calculator ausgerechnet, bei 320x240 ist der 
Pixeltakt nur 60MHz. Wird es funktionieren oder braucht man die übliche 
>640x480?

MfG

Autor: Dimi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... mein Fehler. Pixeltakt 6 MHz bzw. 60Mbit/s

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimi schrieb:
> Ich habe noch einen DE0-nano Board rumliegen. Er hat einen Cyclone IV
> onboard. Vielleicht geht es damit. Ich werde die nächste Zeit eine
> kleine Adapterplatine mit HDMI-Buchse basteln und dann probiere ich es
> aus.
>
> Welche kleinste Auflösung "versteht" HDMI???
> Habe gerade mit CTV-Calculator ausgerechnet, bei 320x240 ist der
> Pixeltakt nur 60MHz. Wird es funktionieren oder braucht man die übliche
>>640x480?
>
> MfG

Geht eher nicht, Auskunft geben die Monitordaren die man über DDI 
auslesen kann. PCs geben schon seit ewigen Zeiten die VGA Auflösung 
320x240 mit Pixel und Zeilenverdoppelung als 640x480 aus.

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimi schrieb:
> Welche kleinste Auflösung "versteht" HDMI???

1280x720ip50

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uli schrieb:
> Dimi schrieb:
>> Welche kleinste Auflösung "versteht" HDMI???
>
> 1280x720ip50

Da es hier aber implizit um DVI und nicht HDMI geht, ist auch kleiner 
möglich.

Autor: MiK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eventuell hilft dir das hier ja weiter:

http://hamsterworks.co.nz/mediawiki/index.php/Dvid_test

Das Projekt verwendet zwar einen Sparten 6, lässt aber die SerDes außen 
vor.
Sollte sich also einigermaßen leicht portieren lassen. Stellt sich 
natürlich trotzdem die Frage ob das auch elektrisch über die 
Pfostenstecker funktioniert...

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und ob der Spartan 3 die benötigte TMDS33 Ausgänge hat.

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> ... und ob der Spartan 3 die benötigte TMDS33 Ausgänge hat.

Artikel lesen!
Hamster hat seinen Test mit LVDS33 gemacht. Entspricht zwar nicht dem 
DVI/HDMI Standard, aber bei den doch moderaten Geschwindikeiten von 
640x480 ( 250 Mbit/s ) ist es offensichtlich kein Problem.
800x600 ist vielleicht auch noch drin.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
in dem ucf steht aber was anderes (?)

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus dem Artikel, sogar extra in fett:

> I have verified that 720p can work using LVDS_33 signalling over a 1.5M HDMI 
cable

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Nach einer gefühlten Ewigkeit kann ich über die Serdes Schnittstelle 
endlich ein Testbild auf einem TFT-Monitor ausgeben. Der Fehler lag in 
der Konfiguration des Serdes Interface.
Danke für die Unterstützung!!!!!!!!!!!!!!!!

Also ich kann bestätigen, dass das der von mir erwähnte HSYNC/VSYNC 
Rechner korrekte Werte ausgiebt!

Was aber momentan noch nicht 100%ig funktioniert ist die Ausgabe des 
Testbildes auf einem DVI Monitor. Gebe ich das Bild auf einem Monitor 
mit einem HDMI Eingang aus wird das Bild korrekt dargestellt. Versuche 
ich das gleiche an einem Monitor mit einem DVI Eingang, bricht die 
Verbindung nach einer zufälligen Zeit von 1 bis 10 Sekunden ab und zeigt 
dann nach ca. 1s wieder ein Bild. Hat jemand vielleicht eine Ahnung an 
was das liegt???

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe schrieb:

>
> Was aber momentan noch nicht 100%ig funktioniert ist die Ausgabe des
> Testbildes auf einem DVI Monitor. Gebe ich das Bild auf einem Monitor
> mit einem HDMI Eingang aus wird das Bild korrekt dargestellt. Versuche
> ich das gleiche an einem Monitor mit einem DVI Eingang, bricht die
> Verbindung nach einer zufälligen Zeit von 1 bis 10 Sekunden ab und zeigt
> dann nach ca. 1s wieder ein Bild. Hat jemand vielleicht eine Ahnung an
> was das liegt???

Pech würde ich sagen.
Wenn ich mir den Schaltplan des HDR-60 anschaue, sehe ich dass die 
Serdes Ausgänge einfach kapazitiv mit der HDMI Buchse verbunden sind. 
Das ist leider nicht entsprechend der HDMI/DVI Spec, und ob es geht 
hängt von der Toleranz des Empfängers ab. Der HDMI Monitor ist 
vermutlich einfach besser.

Aber Vorsicht: Die Cs auf keinen Fall überbrücken, denn dann liegen 3.3V 
an den Serdes Ausgängen des FPGAs an, und das mögen diese nicht.

Autor: Dimi S. (ilovespeccy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MiK

Danke für den Link! Ich probiere es einfach aus...

MfG

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die schnelle Antwort .

Aber eg sollte auch ein DVI Display ohne Probleme funktionieren, da dem 
Eval Board auch ein HDMI auf DVI Adapter beiliegt. Ich werde mit den 
Parameter der Serdes Schnittstelle herumspielen. Vllt gibt es eine 
Konfiguration bei der es funktioniert.

Wenn es nicht klappen sollte wende ich mich direkt an Lattice.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ein HDMI auf DVI Adapter

Der ist rein elektrisch, ungefähr genauso technisch aufwendig wie Klinke 
auf Cinch... Vermutlich stimmt irgendwas mit der Signalintegrität nicht, 
und das fällt mit einem anderen Eingang einfach mehr auf.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg, dass ein HDMI/DVI Adapter keine Meisterwerk der 
Elektrotechnik (oder Feinmechanik) ist, war mir schon bewusst...

Übrigens funktioniert ein Bsp. Bitstream an dem Monitor mit dem 
DVI-Anschluss. Also es ist technisch möglich trotz Kondensatoren am 
Ausgang.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jaja, das ist aber halt Zufall. Es ändern sich beim anderen Monitor bzw. 
Kabel halt leicht die elektrischen Eigenschaften (Terminierung, etc.) 
und dann reicht dann aus, dass die nicht ganz konforme Signalerzeugung 
zuviel Dreckeffekte erzeugt. Versuch mal andere/längere Kabel, evtl. 
gehts dann mit DVI auch nicht mehr.

Die "normalen" HDMI-Aus/Eingänge sind inzwischen so robust, dass ein 
Noname-10m-Kabel für 15EUR problemlos geht. Selbst hartes Aufsplitten 
bar jeder korrekten Terminierung der TMDS-Signale wird oft geschluckt 
(eigentlich völlig unmöglich ;) ). Von daher scheint bei dir schon was 
sehr weit neben der Spec zu liegen. Ein weiter oben liegendes 
Kodierungsproblem (falsches Videotiming, etc.) sollte andere Effekte 
zeigen.

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe schrieb:
> Hallo Georg, dass ein HDMI/DVI Adapter keine Meisterwerk der
> Elektrotechnik (oder Feinmechanik) ist, war mir schon bewusst...
>
> Übrigens funktioniert ein Bsp. Bitstream an dem Monitor mit dem
> DVI-Anschluss. Also es ist technisch möglich trotz Kondensatoren am
> Ausgang.

Bei der gleichen Auflösung?
Wenn ja, mit den Serdes Einstellungen herumspielen, da lässt sich am 
Signal einiges verändern.
Und den Lattice Support nach den "richtigen" Einstellungen zu befragen 
ist sicher keine schlechte Idee.

Technisch möglich ja, aber grenzwertig. Je niedriger die Auflösung desto 
schwieriger wird es. Bei 10b8b wofür die Serdes plus kapazitive Kopplung 
gedacht ist, ist die längse Sequenz von aufeinanderfolgenden 0 oder 1, 
5bit.
Bei TDMS 9bit.
(DisplayPort verwendet übrigens 10b8b, ist aber komplexer als HDMI/DVI)

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, bin zu einer Lösung gekommen, die mich auch nicht 100%ig befriedigt!

Ich habe sehr ungefähr alle Einstellungsmöglichkeiten an den Serdes 
getestet und jedesmal bekam ich dieses Blinken des Monitors. Es war 
nicht einmal eine minimale Verbesserung zu erkennen.

Dann habe ich die VSync Zeiten verkürzt und die HSync Zeiten 
entsprechend verlängert um auf 60 Hz zu kommen. Tatsächlich fand ich 
dann eine VSync und eine HSync Zeit bei der das DVI-Display ohne 
Probleme funktioniert. Lediglich wenn ich mir die Informationen über 
mein Bildsignal am DVI-Display anschaue, bekomme ich nicht die Auflösung 
sondern die VSync- und HSyncfrequenzen.
Kennt jemand vllt noch ein anderes Programm mit dem man die VSync und 
HSync Takte ausgeben kann?

Ich hab das Gefühl, dass das keine saubere Lösung ist!?  Aber immerhin 
funktioniert es so:)

Danke nochmal!!!!

Autor: T. R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin an einem ähnlichen Problem dran. Woher bekommt man denn mal die 
echten timings?

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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