Forum: FPGA, VHDL & Co. CLOCK-DATA Verhältnis am Ausgang vom FPGA festlegen


von Christian W. (christian_w79)


Angehängte Dateien:

Lesenswert?

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

von Duke Scarring (Gast)


Lesenswert?

Reicht es evtl., wenn Du den Takt invertiert ausgibst?

Duke

von Christian W. (christian_w79)


Lesenswert?

> 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

von Drin Stecker (Gast)


Lesenswert?

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ß

von P. K. (pek)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Sigi (Gast)


Lesenswert?

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.

von Weltbester FPGA Pongo (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von P. K. (pek)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.