Hallo, ich habe eine Ansteuerung für ein TFT auf einem Spartan-6 entworfen. Das Display wird nicht über LVDS sondern "diskret" über HSYNC, VSYNC, DATA etc. angesteuert. In der Simulation sieht es gut aus. Jetzt habe ich das Design im FPGA synthetisiert und habe das Problem, dass die Daten nicht vor der Taktflanke anliegen. Siehe den Screenshot vom Logikanalyzer im Anhang: - Das Display taktet mit der steigenden Flanke ein (DOTCLK) - HSYNC kommt zu spät - ENABLE kommt gerade so rechtzeitig - Der BUS1 schaltet genau auf der Flanke Wie ziehe ich das gerade? Ich habe folgende Ideen: 1) Über Constraining des FPGA. Der einzige Constraint, der passen könnte, wäre der OFFSET OUT Constraint. Das Problem hierbei ist, dass er sich wohl eher auf die Verzögerung durch den FPGA bezieht. Er bezieht sich also auf einen Takt am Eingang. Der interessiert mich aber überhaupt nicht, da der Takt am Eingang doppelt so schnell ist wie mein Displaytakt und die Daten aufgrund interner Verarbeitung mit den Daten am Ausgang nichts mehr zu tun haben. 2) Ich könne über die PLL, die meinen Takt generiert, versuchen, eine Phasenverschiebung einzubauen. 3) Ich könnte den Taktausgang über IODELAY so verzögern, dass es passt. 3) Ich könnte das Display so umstellen, dass es auf die fallende Flanke von DOTCLK triggert. Das sind momentan ziemlich viele Optionen und ich würde mich über einen Hinweis freuen, welche ich davon weiter verfolgen sollte. Schönen Gruß, Christian
Reicht es evtl., wenn Du den Takt invertiert ausgibst? Duke
> Reicht es evtl., wenn Du den Takt invertiert ausgibst? Irgendwie schon. Ich habe jetzt dem Display gesagt, es soll auf der fallenden Flanke von DOTCLK einlesen. Gibt's da echt keine andere Handhabe am FPGA? Christian
Christian W. schrieb: > fallenden Flanke von DOTCLK einlesen. Gibt's da echt keine andere > Handhabe am FPGA? Doch, du könnstest die IO-delay Elemente des S6 zur feingranularen Signalverschiebung benutzen. Gruß
Christian W. schrieb: > Gibt's da echt keine andere Handhabe am FPGA? Natürlich, Du kannst IO Timing Constraints setzen. In Deinem Fall wären das Hold-Zeiten für die Sync und Daten relativ zum Output-Clock (welchen Du mit einem DDR-IO-Register ausgibst). Die Krux ist dabei, dass Du etwaige Laufzeitunterschiede auf dem Board mit einberechnen musst. Für "langsame" Interfaces (vermutlich taktest Du mit 27MHz?) ist es aber durchaus üblich (wie von Duke Scarring vorgeschlagen), auf die inaktive Flanke des Empfängers anzulegen.
P. K. schrieb: > Natürlich, Du kannst IO Timing Constraints setzen. Haben dir wirklich Einfluss auf das Timing? Oder wird von der STA nur geprüft, ob die Contraints eingehalten werden und um das passende Delay muss man sich doch selber kümmern? Ich sorge bisher mit FSMs für das richtige Timing. Die Togglerate am Ausgangspin ist dann maximal f_clk / 2. Und die Granularität beträgt natürlich auch nur 1 / f_clk. Duke
Duke Scarring schrieb: > Haben dir wirklich Einfluss auf das Timing? Klar habe die Einfluss, es werden z.B. IO-Delays gesetzt oder die FFs in die IO-Zellen gelegt, soweit möglich. Liegen die Constraints aber ausserhalb der Delay-Bereiche, dann wird eine Warnung ausgegeben. So wie ich aber obiges Problem einstufe ist es wahrscheinlich besser, die generierte Clock zu invertieren statt zu versuchen, die H/S Timings des TFTs bei nichtinverter Clock einzuhalten.
Wenn man die Daten (wo wie es korrekt ist!) mit dem Takt ausgibt, den man auch zur Verfügung stellt, dann reicht es, die Daten über IO-FFs zu führen. Das sollte in der Regel reichen. Dabei kann es höchstens zu einem minimal zu kurzen Delay des Taktes kommen und dann gibt man einfach einen dazu passend verschobenen Takt raus. Eine DCM x 8 und dann mit 1/8 Verzögerung raus. Wenn es gernicht geht, eine PLL mit einigen Grad Verzögerung. Oft reicht es auch, am Eingang die PLL wegzulassen und damit intern mit einem verzögerten Takt zu arbeiten, und den eigentlichen Takt um den FPGA herumzuführen. Der FPGa hängt dann im Timing hinter, so wie es ein ordentlicher Chip auch machen würde.
Sigi schrieb: > Klar habe die Einfluss, es werden z.B. IO-Delays > gesetzt oder die FFs in die IO-Zellen gelegt, > soweit möglich. Zumindest bei Xilinx werden die IO-Delays nur wirksam, wenn man die entsprechenden Elemente auch instanziiert. Auch die IO-Zellen FlipFlops müssen global oder per Attribut aktiviert werden.
Sigi schrieb: > Liegen die Constraints aber > ausserhalb der Delay-Bereiche, dann wird eine > Warnung ausgegeben. Damit das nicht passiert, sollte der Datenbus auf dem PCB einigermassen "length matched" sein. Wenn nun noch darauf geachtet wird, dass keine Datenlinie kürzer als der Clock ist, sollte mit dem fast IO-Register kein Problem aufkommen. Aber wie schon gesagt: Es fällt dir (TO) keine Zacke zur Krone heraus, wenn Du auf die inaktive Flanke anlegst.
P. K. schrieb: > Aber wie schon gesagt: Es fällt dir (TO) keine Zacke zur Krone heraus, > wenn Du auf die inaktive Flanke anlegst. Damit vergibt man aber gfs schon Reserve. Vom Prinzip her sollten Takt-synchrone Daten auch so ausgegeben werden, weil die Daten am Ende des Taktes am wahrscheinlichsten stabil sind. Gfs addiert man etwas Taktverschiebung um 1/8 um sicherzustellen, dass das PCB nichts ungutes veranstaltet.
Bitte 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.