Hallo,
ich versuche derzeit ein Display mit vier LVDS-Daten-Kanälen und einem
CLK-Kanal mit einem Zynq in Hardware anzusteuern; das dazugehörige
Timing-Diagramm findet ihr im Anhang. Ich hänge aber etwas an der
Takterzeugung.
Den schematischen Aufbau findet ihr im Blockdiagramm. Für die LVDS
Signale wollte ich die OSERDES-Elemente des Zynqs nutzen. Hierzu habe
ich mir einen 7 mal schnelleren Takt für die serielle Schnittstelle
erzeugt (35.11 * 7 --> ~245.77 MHz). Aus diesem Takt erzeuge ich mir
mittels eines Zählers den Pixelclock von 35.11 MHz (zwei Serial-Takte
an, drei aus, zwei an). beide Takte führe ich auf jeweils einen BUFG.
Für die HYNC-, VSYNC- und DE-Signale zähle ich nur noch den Pixelclock.
Das ganze soll nun in einem Datengenerator zusammengesetzt werden, was
soweit auch funktioniert.
ABER: Die Ausgabe des seriellen Daten-Signals erfolgt ja
Phasenverschoben zum Pixelclock. Mein Datengenerator müsste also
ebenfalls Phasenverschoben meine Daten auf die OSERDES-Elemente geben.
Wie setze ich soetwas jetzt am geschicktesten um? Nutze ich einfach
einen kleinen Signalgeber, der bei korrekter Phasenlage dem
Datengenerator die neuen Signale ausgeben lässt?
Oder denke ich in die falsche Richtung und mein Taktkonzept ist falsch
aufgebaut?
Viele Grüße
Das einfachste ist, Du nutzt für den LVDS-Clk auch den Serdes.
Packe einfache die Bilddaten in vier Schieberegister, die Du mit dem
schnellen clk rausschiebst und dem langsamen clk neu befüllst.
Das gleiche machst Du mit dem Clk für das Display mit einem 5. Register.
Hier beschreibst Du das Register jeweils mit "1100011" und schiebst das
dann raus.
Gruß Micha
Am Besten alle Signale (inkl. Clk) in
IO-FFs legen, dann die seriellen Daten
per DDR-FFs ausgeben.
In Deiner Skizze hast Du das
Clk-hi-lo-Verhältnis von 4:3, oft findet
man aber auch 1:1, d.h. die "mittleren"
Daten liegen genau auf der fallenden
Flanke, und das passt eben gut zu DDR-FF.
Per IO-Delays kannst Du dann die Phasen
zwischen Signalen und Clock einstellen.
Hallo,
schon mal vielen Dank für eure Antworten.
Also wenn ich euch richtig verstehe, soll ich sowohl für den Takt als
auch für die Daten SerDes nutzen. An den Takt-SerDes lege ich dann das
Bitmuster von Micha an. Dann erzeuge ich mir meinen 35.11 MHz und 245.77
MHz Takt im FPGA. Den 35.11 MHz Takt nutze ich dann um die
Schieberegister der SerDes zu aktualisieren und den 245.77 MHz Takt für
die seriellen Daten zum Display.
Dazu hätte ich aber noch eine generelle Frage. Bei der Übertragung des
ersten Pixels würde das Display nun ja eine Flanke sehen, und dann für
2*(TClk/7) ein High-Signal. Ist das dem Display egal? Oder erwartet es
eine Flanke und dann für 4*(TClk/7) ein High-Signal?
Mehr als die Abbildung im ersten Post lässt sich das Datenblatt des
Displays bzgl. der Timings nicht aus.
Viele Grüße
Guenther schrieb:> Dazu hätte ich aber noch eine generelle Frage. Bei der Übertragung des> ersten Pixels würde das Display nun ja eine Flanke sehen, und dann für> 2*(TClk/7) ein High-Signal. Ist das dem Display egal? Oder erwartet es> eine Flanke und dann für 4*(TClk/7) ein High-Signal?> Mehr als die Abbildung im ersten Post lässt sich das Datenblatt des> Displays bzgl. der Timings nicht aus.
Das Bitmuster, was dann den Bit-Takt / 7 darstellt, kannst du doch frei
definieren. Wichtig ist, dass du alle OSERDES am gleichen Takt und
gleichen Reset hängen hast, dass die synchron laufen.
Hallo Christian,
verstehe ich da jetzt etwas falsch?
Dem Display wird doch der Takt in Form des Bitmusters "1100011"
übertragen. Im Datenblatt findet sich die Abbildung aus dem ersten Post
("Timing.png"). Hier sieht man zum Teil noch die Übertragung des
vorherigen Pixels. Noch bevor die serielle Übertragung des vorherigen
Pixels fertig ist, liegt bereits eine neue Taktflanke an (OLVCLK).
Synchronisieren sich die Displays auf diese Taktflanke oder werden eh
alle Signale mit einer festen Frequenz abgetastet?.
Falls ersteres, dann kommen wir wieder zu meinem Verständnisproblem.
Braucht das Display einfach nur das Muster "1100011" oder benötigt es
die Taktflanke und dann ein Muster nach "1111000"? Dann müsste ich die
Daten-SerDes ja quasi 2*(TClk/7) später starten.
Tut mir Leid, ich weiß leider nicht, wie ich es besser beschreiben soll.
Vielleicht stelle ich es mir auch viel zu kompliziert vor.
Viele Grüße
Laut dem Bild wechselt der Takt den Pegel zum gleichen Zeitpunkt wie die
Daten. Dazu ist extra der senkrechte Strich 2 Flanken vor dem Ende des
Pixels da eingezeichnet. Durch die /7 Frequenz kann der auch gar nicht
zum Abtasten der Daten herangezogen werden. Ich vermute eher, im Display
wird damit eine PLL gespeist und das "Taktsignal" wird als eine Art
Framesync für jeweils ein Pixel benutzt. Genau so machen das auch z.B.
serielle ADCs wie der LTC2174 o.ä.
Du kannst also den Takt genauso wie die Daten behandeln, nur dass der
ein statisches Muster hat. 1100011 ist schon richtig dann.
Super, vielen Dank für die Erklärung. Und ich habe mir von Anfang an
Gedanken darüber gemacht, warum da diese Phasenverschiebung ist und wie
man das dann bei der Datenerzeugung berücksichtig. Wenn dem Display
wirklich nur das Bitmuster "1100011" genügt, dann passt alles.
Vielen Dank!
Eine eigene Frage?
Dieser Thread ist über 10 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
Blockdiagramm.png
(2,6 KB)
timing.png
(21 KB)
