Clock to Pad Delay Xilinx Virtex 5

Schau dir mal xapp585 an 
(https://www.xilinx.com/support/documentation/application_notes/xapp585-lvds-source-synch-serdes-clock-multiplication.pdf)

Das ist prinzipiell genau dein Problem fuer Input und Output, nur fuer 
7-Series FPGAs. Fuer den Output wird fuer Daten UND Clock ein OSERDES im 
7:1-mode genutzt, der mit clk und clkdiv versorgt wird. Dieser hat ein 
recht geringes und konstantes Delay zu seinem Buffer, da das nicht ueber 
normale Routing-Resourcen geht.

Clock geht dann einfach durch einen OLERDES mit dem Pattern 1100011 und 
bleibt damit zu den Daten aligniert.

Die restlichen Delays (Buffer -> Pad -> Ball) weichen auch von Ball zu 
Ball ab. Wenn die noch relevant sind, muessen sie im PCB ausgeglichen 
werden.

So wie ich dich verstehe wäre ein OSERDES angebracht zu benutzen.
Der ist bei mir auch in Planung.

Aber nur aus Interesse würde ich gerne wissen wie ich in meinem Design 
die clk to PADs delays geregelt bekomme.

Denn mein aktuelles Design lief in einem Vorprojekt mit einer 
niedrigeren Takt einwandfrei. Da war es halt nicht so ein Problem mit 
dem to pad delays. Nun bin ich schneller und habe eine Periode unter 3ns 
und würde gerne den kompletten Output samt Clock mit dem gleichen Delay 
versehen, soweit es geht.

Hannes schrieb:
> Clock geht dann einfach durch einen OLERDES mit dem Pattern 1100011 und
> bleibt damit zu den Daten aligniert.

Was meinst du hier mit dem Pattern? Kann man das am OSERDES einstellen?
Das Pattern ist in meiner Clock schon vorhanden, das müsste doch reichen 
für den OSERDES.

Der OSERDES wird mit 2 Clocks versorgt - clk und clkdiv. Dabei sollen 
beide aus der gleichen PLL kommen, und clk um deinen 
Serialisierungsfaktor schneller sein als clkdiv.

Hier also: clk @ 350MHz, clkdiv @ 50MHz.

Die Daten muessen mit der gleichen Clockingtopologie durch die OSERDES 
gehen wie auch das Clockpattern. Das Clockpattern wird uebertragen als 
Datum mit dem konstanten Wert 1100011. Da es durch die gleichen 
Strukturen mit gleicher Clock uebertragen wird wie die Daten, wird auch 
der Phasenversatz ueber PVT (Process, Voltage, Temperature) der gleiche 
bleiben.

Wenn die Clock jetzt aus einem normalen Flipflop (oder noch schlimmer - 
Kombinatorik) ausgegeben wird, wird das Signal noch ueber normales 
Routing geschickt, bevor es zur Aussenwelt geht. Das ist sehr variabel 
von build zu build. Beim OSERDES gibt es dagegen pro Ball genau eine 
Moeglichkeit, das zu routen, deswegen verhaelt es sich auch bei jedem 
Build gleich. Varianz gibt es nur bis zum SERDES.

Hoffe, das etwas besser erklaert zu haben.
Mein Wissen beschraenkt sich auf die SERDES ab 7-Series, ob dein Virtex 
5 noch andere Eigenarten hat weiss ich nicht.

Hallo Tobias,

Tobias B. schrieb:
> Nur kurz ob ich es verstanden habe: Du suchst Timing Constraints damit
> das Output Timing der einzelnen Signale eines parallel Datenbus einen
> von dir vorgegebene minimalen zeitlichen Versatz zueinander haben?

Genau das suche ich :-)

Das Whitepaper habe ich auch schon gesehen.

Das was ich versuche zu verstehen ist, dass die clk to PAD delay zur 
Clock "CLK" referenziert wird, welches die 100MHz Eingangsfrequenz zur 
PLL ist.
Die Daten und Clocks sind aber mit dem Ausgang des PLLs (350MHz) 
generiert worden. Finde grad keinen Bezug zum "CLK" (100MHz). Daher 
suche ich nach einer Antwort :-)

Tobias B. schrieb:
> Du solltest dir auf jedenfall mal Gedanken machen, ob du die 50 MHz
> Clock nicht mit deiner PLL generieren moechtest und via ODDR Buffer
> ausgeben. Das ist der von Xilinx empfohlene Stil.

Ich habe das versucht, allerdings ist der delay von clock to pad größer 
geworden.

Wie meinst du das mit dem ODDR, da habe ich doch als Output ein DDR 
Single ended. Wascheinlich ist hier ja ein OSERDES angebrachter.

Irgendwo müsstest du eine Option finden um das Ausgaberegister in den 
IO-Buffer zu schieben. Dadurch hast du sehr niedrige und vor allem 
konstante und ähnliche Delays auf allen Ausgängen. Eventuell bekommst du 
dadurch aber Probleme beim Holdtiming.

Möchte mich hier an alle beteiligten bedanken.

Als Fazit kann ich sagen, dass über die ODDR die clk to pad delays 
zueinander sehr klein wurden. Das ist schonmal ein korrekter Ansatz 
gewesen.

Habe aber nun OSERDESe in meinem Design eingebaut, die auch sehr kleine 
clk to pad delays aufweisen.

Letztendlich war mein Hauptproblem, das mein Timing mit 350MHz einfach 
an manchen stellen zu hart war. Daher habe ich das Konzept geändert und 
mittels der 7fach kleineren 50MHz Clock das Design abgeändert.
Nun werden sowohl die Daten als auch das Pattern "1100011" (Sync-Clock 
CameraLink) mittels OSERDESe zu den Ausgängen mit geringen clk to Pad 
delay zueinander geführt.

Mein Problem bei der ODDR Variante war das ich mit dem richtigen duty 
cycle die Daten in der 350MHz Taktdomain aufarbeiten musste, sodass das 
Timing eng wurde.
Nun übernehmen die OSERDESe diese Aufgabe und mein Design kann gechilled 
:-) die 50MHz Taktdomain verwenden.

Hier gilt noch zu beachten, dass (zumindest bei der 7-Series) die 
OSERDES und die ODDR und die IOB-FDs Teil des OLOGIC sind und daher alle 
die gleichen Routing-Delays aufweisen.

Wenn man jetzt also ein ODDR oder OSERDES benutzt, um eine regenerierte 
Clock auszugeben, kann man oft mit sehr begrenztem Aufwand die 
Setup/Hold-Zeiten feintunen, in dem man eine phasenverschobene Clock an 
den Clock-ODDR gibt, aber bei den restlichen Outputs mit Offset 0 
arbeitet.

Genauso koennte man ein ODDR mit einer 4/7 Duty-Cycle Clock mit Phase 45 
Grad verwenden. Ist aber deutlich schwieriger hinzubekommen, als der 
OSERDES.