Hallo, ich möchte verschiedene LVDS-Quellen mit dem Spartan3AN auf eine Senke schalten und versuche mich fürs Erste daran, ein LVDS-Signal (clock plus 4 Kanäle) einfach durch das FPGA durchzuschleifen. An den Eingängen habe ich IBUFDS für die Datenleitungen und IBUFGDS für den Takt eingesetzt. Takt und Daten gebe ich dann per OBUFDS wieder aus. Die Ausgangssignale der Eingangsbuffer habe ich schlicht mit den Eingangssignalen der Ausgangsbuffer verdrahtet. Am FPGA habe ich natürlich LVDS-Pins benutzt und diese im UCF entsprechend auf LVDS_33 gesetzt und die Terminierung für die Eingänge aktiviert. Ich habe das Ganze angeschlossen und sehe an meinem Display ein Bild, jedoch mit einem guten Satz von Pixel- und Syncfehlern. Ich weiß, dass das Display einwandfrei funktioniert und ebenso die LVDS-Quelle. Ich denke mir, dass ich mir die Sache VHDL-mäßig vielleicht zu einfach gemacht habe und hoffe dass der Fehler in meiner VHDL-Beschreibung liegt. Kann mir da jemand weiterhelfen und einen Tipp geben?
Ich vermute eher, dass die Fehler in den Timing Constraints liegen. Wie sehen die bei dir aus?
Verstehe ich das so richtig: Du willst LVDS-Signale eines TFTs (wenn auch ein "Kleiner") einfach so durch einen FPGA leiten? Das wird so nicht gehen, da der Spartan3 dafür bzgl. IO->IO zu langsam ist, d.h. die Signale werden zu langsam transportiert, bei z.B. 1024x768 hast du schon >=400MHz-500MHz. Und ob das Clock-Signal per BUFGDS oder "nur" per BUFDS rein/rausgeleitet wird ist irrelevant.
Vielen Dank für Eure Antworten! Ich bin auf dem LVDS-mit-FPGA-Gebiet noch Anfänger und hatte ehrlich gesagt gar nicht an die Timing Constraints gedacht. Ich mache mich da grad dran. Die Bilddaten sind ja auf vier Kanäle aufgeteilt. Und dafür dass ich noch keine Constraints eingefügt habe sieht das Bild aber schon erstaunlich gut aus.
Daniel M. schrieb: > Die Bilddaten sind ja auf vier Kanäle aufgeteilt. Und dafür dass ich > noch keine Constraints eingefügt habe sieht das Bild aber schon > erstaunlich gut aus. Das überrascht mich ein wenig, aber je nach Abstand zwischen Input- und Output-Zellen kann schon ein erkennbares Bild rauskommen. Von Pin zu Pins hast du schonmal ein paar ns, kritisch ist nur der Versatz der LVDS-Signal untereinander. Da die Signale nur durchgeschleift werden, ist vermutlich auch das Taktverhältnis eines Signals ungestört. Was heisst "erstaunlich"? Sind Zeilen oder das ganze Bild teilweise verschoben, gibt es Fehlfarben?
Ich habe etliche sich bewegende grüne und blaue Striche im Bild und das Bild springt vertikal zwischen zwei leicht versetzten Positionen hin und her. Wie bekomme ich denn das mit dem Versatz der LVDS Leitungen untereinander am besten in den Griff?
Daniel M. schrieb: > Wie bekomme ich denn das mit dem Versatz der LVDS Leitungen > untereinander am besten in den Griff? Spontan würde ich sagen, durch Timing-Constraints. Du sagst dem Router, wie viel Zeitdifferenz maximale zwischen den Signalen liegen darf und er versucht das hinzukriegen. Entweder es klappt oder er sagt dir, dass es nicht klappt.
Dussel schrieb: > Daniel M. schrieb: >> Wie bekomme ich denn das mit dem Versatz der LVDS Leitungen >> untereinander am besten in den Griff? > Spontan würde ich sagen, durch Timing-Constraints. Du sagst dem Router, > wie viel Zeitdifferenz maximale zwischen den Signalen liegen darf und er > versucht das hinzukriegen. Entweder es klappt oder er sagt dir, dass es > nicht klappt. Vermutlich gar nicht so einfach. Denn es liegt nicht an der absoluten Laufzeit durch den Chip, sondern an dem Versatz der Signale untereinander. Und diesen Skew zu constrainen ist nahezu nicht möglich. Und wenn du dann den Multiplexer dazu baust, wird das Ganze noch hässlicher. Denn dann sind auf den Pfaden auch noch LUTs, durch die deine Signale durch müssen. Ich würde mal sagen: Wenn es dir gelingt, dann hast du einfach nur zufällig Glück gehabt.
Mit Timing-Constraints kriegst du wahrscheinlich keine besseren Ergebnisse hin, denn die beziehen sich ja auf Sample/Hold-Zeiten bzgl. Clock-Flanken. Und die gibt's in deinem Ansatz nicht. Eine einfach Lösung: Die Signale decodieren und dann zum Senden wieder encodieren. Leg dazu dein Clock-Signal auf einen Clock-fähigen Eingang. Dieser Treibt dann eine PLL/DCM. Die DCM generiert dann ein Sample-Clock-Signal mit 7-facher Frequenz (bei 1024er Auflösung etwa 350MHz, was bei einem Spartan3 noch geht) und eine Logic-Clock mit 3.5-Facher Frequenz (175 MHz). Damit werden dann die 4 LVDS-Signale gesampelt, auf 175MHz runtertransformiert, decodiert und am Ausgang wieder encodiert und hochtransformiert, anschliessend ausgegeben. Fehlt nur noch das Clock-Ausgangssignal. Aber das läss sich auch relativ einfach generieren. Vorteil: Du hast Zugriff auf die Farbvektoren und kannst sie beliebig ändern, oder du kannst zwischen verschiedenen LVDS-Eingängen hin- und herschalten etc. Hättest du einen Virtex4/Höher, dann könnte die komplette De/Encodierung entfallen.
Ich hatte befürchtet, dass Decodieren und wieder Encodieren die Lösung werden würde. Nur komme ich da dann leider nicht mit der Auflösung hin, die ich gerne hätte. Es gibt also keine Möglichkeit, das ordentlich zu constrainen und ich sollte am besten einen anderen Ansatz wählen?
Welche Auflösung willst du haben? Ich habe mal mit einem Spartan3 ein TFT mit 1366er Auflösung angesteuert, vom Timing her nach Oben hin noch reichlich Platz. 1920er Auflösung ist aber nur mit dem höchsten Speed-Grade möglich (plus keinen Tricksereien). Und was man bein Spartan nich vergessen darf: er hat sowohl beim Eingang als auch beim Ausgang DDR-FFs, d.h. du must nur mit der halben Frequenz arbeiten.
Sigi schrieb: > Und was man bein Spartan nich vergessen darf: er > hat sowohl beim Eingang als auch beim Ausgang > DDR-FFs, d.h. du must nur mit der halben Frequenz > arbeiten. Wie verwendete man diese Funktion in der Praxis? Wie verarbeitet der/das FPGA dann die Daten intern? Doppelt, parallel?
FPGA-Neuling schrieb im Beitrag #4130813: > Wie verwendete man diese Funktion in der Praxis? Wie verarbeitet der/das > FPGA dann die Daten intern? Doppelt, parallel? Jeder Hersteller mach das anders. Bei Xilinx z.B. sind alle FPGA-internen Komponenten dokumentiert, schau mal in UG607 (auf der Xilinx-Doc-Seite) "Spartan-3 Libraries Guide for HDL Designs", sowas gibt's für jede Familie.
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.