Hallo,
ich will noch mal ein Thema hervorholen, das ich sowohl hier als auch im
Xilinx Forum gepostet habe, das wenig Resonanz erzeugt hat aber mich
sehr beschäftigt.
Ich hatte ein System, in dem zwei PLLs in Serie geschalten waren, die
erste war im Xilinx IP Core für PCIe, die zweite in meinem Userdesigen.
Ich habe dann auf der Hardware seltsame Effekte erlebt, die nur aus
Timing Problemen heraus erklärbar sind, die State Machine hat einfach
verrückt gespielt.
Jetzt weiß ich, dass PCIe eine Spread Spectrum Clock erzeugt. Meine
Erklärung für das beobachtete Verhalten ist die, dass die erste PLL
etwas Jitter der Spread Spectrum Colck heraus genommen hat und due
zweite noch mehr und auf einmal war der Jitterunterschied zwischen den
beiden Clocks so groß, dass dass von der zweiten zru ersten Clock Domain
hin Timing Probleme auftraten.
Andererseits lese ich hier (und auhc an anderer Stelle) dass die PLL die
Jitterprobleme erst erhöht. Jetzt bin ich verwirrt.
Lösung für mein Problem war übrigens eine DLL statt einer PLL, damit hat
es wunderbar funktioniert, hat allerdings mein inzwischen leider aus der
Firma ausgeschiedener Chef sich einfallen lassen, umso besser dass ich
jetzt ohne ihn weiterarbeiten muss :( .
lg
Matthias
> Jetzt bin ich verwirrt.
Das kommt von so verallgemeinerten Aussagen gerne... PLLs taugen zur
Jitterdämpfung, aber sie produzieren auch immer selber einen. Es geht da
nur um die Verhältnisse und in welchem Anwendungsbereich das
stattfindet. Bei synchroner Digitaltechnik ist der Jitter i.A. egal,
solange alle FFs mit identischem Takt/Phase laufen, für die EMV hilft er
ja sogar... Ein Funkfritze dagegen wird die PLL und den Schleifenfilter
sehr lange streicheln, damit sie minimal jittern und auch die "Spurs"
verschwinden.
> Lösung für mein Problem war übrigens eine DLL statt einer PLL,
Hätte ich dir auch sagen können ;) DLLs übernehmen den Eingangsjitter,
bauen aber selber noch einen (Definierten) dazu, das könnte einen evtl.
auch beissen. Peter Alfke hat mal davon abgeraten aus kaskadierten
Vervielfacher-DLLs das Gesamtsystem voll synchron zu betreiben, also zB.
Daten von CLK*4 mit CLK "einfach so" zu übernehmen. Hängt aber wohl vom
genauen Anwendungsfall ab, ob einem da der unkorrelierte Jitter aller
DLL-Takte das Setup/Hold-Fenster stört. Mich hats bislang nicht
gestört...
Georg A. schrieb:
> Hätte ich dir auch sagen können ;)
Mich hats damals einiges an Zeit gekostet, weil ich den Fehler an einer
ganz anderen Stelle vermutete. Die STA hat damals ja keinen Fehler
gemeldet, ich denke ich habe dann auch versucht, bei den Constraints den
Jitter der Eingangsclock höher zu setzen, um das Spread Spectrum
irgendwie abzubilden, hatte aber auch keinen Erfolg. Kann die STA die
DLL vom Jitter her besser berechnen?
Irgendwie bin ich jetzt wieder etwas verunsichert, ob da nicht doch noch
ein Fisch drinnen ist, der sich halt jetzt nicht mehr bei jedem zehten
sondern nur bei jedem 10^10ten Zugriff zeigt. Dann müsste ich wohl
größere Umbauten vornhemen.
lg
Matthias
> Kann die STA die DLL vom Jitter her besser berechnen?
Kennst du das da?
http://www.xilinx.com/support/answers/20828.htm
Ich bin mir aber ehrlich gesagt nicht ganz sicher, ob das dein Problem
wirklich "von selbst" erkennen kann. Das liegt ja am Übergang der
Clockdomains und nicht daran, dass durch den Jitter innerhalb einer
Domain die Periode "zu kurz" wird. Und was timingan/trce als Übergang
erkennt oder nicht, ist IMO manchmal etwas arg fragwürdig... Auf jeden
Fall wirst du da mit etwas mehr Constraints nachhelfen müssen.
Wenn jetzt alles per DLL/DCM dranhängt, sollte das aber prinzipiell
keine Probleme mehr machen.
Danke für den Link, inzwischen bin ich mit meinen Überlegungen soweit:
Ich habe eine PLL (im GTP_DUAL Tile und fix im IP Core, wohl nicht
wegzubekommen) und danach eine DCM. Zwischen den beiden Clock Domains
gibt es Kommunikation. Wenn ich jetzt mit FROM-TO Constraints von der
einen zur anderen Taktdomäne als maximale Laufzeit die 8 ns
Periodendauer minus dem größtmöglichen Abstand durch Jitter einstelle,
dann sollte ich das Problem erfasst haben. Ich kann natürlich auch den
PERIOD Constraint entsprechend erhöhen, es ist dann aber fraglich, ob
ich das Timing noch schaffe.
Außerdem komme ich von den Berechnungen her noch nicht ganz hin: Für die
PLL ist ein maximale Input Jitter von 40 ps und ein maximaler Output
Jitter von 0.3 UI angegeben, ich hoffe mal, dass das 0.3% und nicht 30%
heißt. Bei einem Referenztakt von 100 MHz nehme ich damit 30 ps Jitter
am PLL Output an. Dann geht das ganze in die DLL, die hat ca. 160 ps
laut Core Generator. Wenn ich das geometrisch addiere komme ich auf
knapp über 160 ps Jitter auf dem Takt, den die DCM ausspuckt.
Aber mich interessiert ja der maxmiale Unterschied zwischen den beiden
Taktdomänen, wären das dann 30 + 160 ps? Ganz unkorreliert sind die
beiden ja auch nicht, evtl ist da die Bedingung auch wieder zu streng.
lg
Matthias
Allerdings, so ganz mit dem PERIOD Constraint komme ich wohl auch nicht
dorthin, wo ich hin will, denn anscheinend waren die Fehler, die
auftraten, Hold Timing Verletzungen und nicht Setup Timing. Gegen
zweitere hilft das mit PERIOD Constraint, gegen ersteres aber wohl
nicht.
lg
Matthias
