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
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
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
Wie geht das denn, ist das dann intern gepuffert? Der H-Takt muesste doch derselbe sein, lediglich die Austastpixel sind weniger. ??????????????
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
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
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??
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
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.
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.
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?
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?
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
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.
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
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?
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
ok, aber woran erkennt der Monitor, dass in diesem reduced mode gefahren wird?
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
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!
>VSync gesamt: 160 Pixeltakte >HSync gesamt: 39 Zeilen Dann wäre der HSync ja länger als der VSync ...
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...
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.
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.
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
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
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?
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?
Uli schrieb: > Die SERDES müssten das doch können (?) Ja, nur hat der Spartan 3 keine Highspped SERDES
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.
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
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.
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.
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...
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.
Aus dem Artikel, sogar extra in fett:
> I have verified that 720p can work using LVDS_33 signalling over a 1.5M HDMI
cable
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???
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.
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.
> 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.
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.
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.
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)
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!!!!
Bin an einem ähnlichen Problem dran. Woher bekommt man denn mal die echten timings?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.