mikrocontroller.net

Forum: FPGA, VHDL & Co. PLL und Jitter - mal etwas allgemeiner


Autor: Matthias F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Matthias F. (flint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Matthias F. (flint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias F. (flint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.