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
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.