Ich kann nicht alle Takte aus einer PLL- und auch einige nicht einmal direkt aus dem Oszillator gewinnen, daher muss ich mit einer Zwischenfrequenz arbeiten. (Ein weiterer Oszillator / Quarz geht nicht, weil es ganzzahlig synchron bleiben muss). Kann ich davon ausgehen, dass die Taktunsicherheit, die vom Eingang in die erste PLL geht und welche durch selbe verstärkt wird, an die zweite weitergegeben wird und das berücksichtigt wird oder muss ich das gesondert beim Anlegen der zweiten PLL angeben? Ich habe bisher bei der ersten PLL den stardmäßigen Wert von 10ps auf 20ps angehoben, um sicher zu sein, dass das, was an deren Ausgang passiert, als "worst case" an die Folge-PLL weitergereicht wird. Aus den Daten entnehme ich daß die erste PLL ziemlichen Terz macht. Sollte man da "minimize output jitter" nehmen? Durch mein 20p-constraint sollte das auf der sicheren Seite sein, oder?
Messtechniker schrieb: > Sollte man da "minimize output jitter" nehmen? Ja. > Durch mein 20p-constraint > sollte das auf der sicheren Seite sein, oder? Nein. Im Zweifelsfall geht man davon aus, das die constraints erst dann von der toolchain gelesen werden, wenn schon alles zu spät ist. Ein timing constraint ist kein HW configuration string.
Tanga Flicker schrieb: > Im Zweifelsfall geht man davon aus, das die constraints erst dann > von der toolchain gelesen werden, wenn schon alles zu spät ist Wie ist das genau gemeint? Er muss doch beim Platzieren, die Timings einhalten und sie spätestens hernach prüfen. Dazu braucht er die Taktunsicherheit. Die berechnet er meines Erachtens aus den PLL-Eigenschaften und deren Einstellungen in Verbindung mit dem vorgebenen Jitter von Außen. Wenn der größer wird, sollte sich das nach innen fortsetzen. Oder nicht?
Und noch eine Frage hinten drauf, die sich genau auf das PLL-Verhalten bezieht: Ich habe eine Zwischenfrequenz von 100.000 MHz, die in einer einzigen PLL, die sonst nichts macht! auf 150.000 gebracht werden soll. Der Wizzard antwortet mit einem Clockdivider ":2", einem MUL von 19.875 und einem DIV von 6.625, also ziemlich krumm. OSC-Frequenz ist irgendwas über 900 MHz. Ich hätte ein simles 3:2-Verhältnis erwartet, oder eines von 9:6, um ähnlich hoch zu kommen. Warum tut der das? Macht es Sinn, das zu überschreiben? Der Jitter ist konkret mit 144ps und der phase error mit 157ps angegeben. Wenn ich es manuell einstelle, also :2, *18, /6 sind es 156ps/162 ps. Warum bringt der nichtganzzahlige Teiler trotzdem bessere Ergebnisse? Wegen der paar MHz mehr OSC-Frequenz? Oder ist es der DIV 2 vor der PLL, um den Takt zu symmetrieren (so "JK-mässig")? Komisch: Wenn ich den Clock-Div weglasse, sind es 127ps / 105ps also besser! Wozu also den Clock-Div? Hat das vorgeschlagene Verhältnis dann überhaupt noch einen Vorteil? Warum gibt der Wizzard solche Verhältnisse vor, wenn die einfache, naheliegende Version, nämlich :1, *9, /6 das beste Resultat liefert?
Messtechniker schrieb: > Die berechnet er meines Erachtens aus den > PLL-Eigenschaften und deren Einstellungen in Verbindung mit dem > vorgebenen Jitter von Außen. Wenn der größer wird, sollte sich das nach > innen fortsetzen. > > Oder nicht? Du hast uns die Tolchain nicht verraten, aber zumindest bei Xilinx ist es auch so. Du musst nicht manuell für den Ausgang der ersten PLL eine Unsicherheit angeben. Die Ausgangfrequenz der PLL wird ja auch automatisch als Constraint für das nachfolgende Clocknetz berechnet.
Messtechniker schrieb: > Er muss doch beim Platzieren, die Timings > einhalten und sie spätestens hernach prüfen. Njein, das timing steht erst nach dem Routing fest, nach der Platzierung hat man nur Angaben über das best-mögliche timing, aber nicht über das reale.
Die Berechung der PLL-Paramater erfolgt meistens nach einer Heuristik, die irgendwo anfängt und bei irgend einer passenden Lösung stehen bleibt, die muss nicht unbedngt die beste sein. Bei einfach zu ermittelnden Teilerverhältnissen nimm die offensichtliche Lösung wenn der Jitter passt, bei krummen Verhältnissen lass den Wizard tun, wofür er bezahlt wurde.
Vancouver schrieb: > zumindest bei Xilinx ist es auch so. Ja, es ist XI > Du musst nicht manuell für den Ausgang der ersten PLL eine > Unsicherheit angeben. Ich meinte den Eingang der ersten. Habe es ausprobiert: Wenn ich 20 statt 10 eintrage, kommen die additiv auf den ersten Wert drauf. Das finde ich spannend, weil eigentlich eine PLL etwas wegregeln sollte.
Welche Anforderungen hast Du an den Taktjitter? Und: Hast Du eine Möglichkeit den Jitter zu messen? Duke
Messtechniker schrieb: > Ich meinte den Eingang der ersten. Ah, ja das macht Sinn. Messtechniker schrieb: > Das > finde ich spannend, weil eigentlich eine PLL etwas wegregeln sollte. PLLs regeln einen Jitter nicht zwangsäufig raus, im Worstcase erzeugen sie sogar welchen (so wie es halt ist bei Regelkreisen: In manchen Fällen regeln sie alles glatt, in anderen Fällen zappeln sie herum). Deswegen ist Kaskadierung von PLLs manchmal eine heikle Sache. Ich vermute, die Tools nehmen als Worstcase an, dass die PLL den Jitter durchreicht und rechnen ihn daher am Ausgang drauf (aber ich weiß es ehrlich gesagt nicht).
Messtechniker schrieb: > Ich habe eine Zwischenfrequenz von 100.000 MHz, die in einer einzigen > PLL, die sonst nichts macht! auf 150.000 gebracht werden soll. Also aktuelle (series-7) Xilinx FPGA's haben beides: PLL und MMCM. Benutz doch den MixedModeClockManager, wenn die PLL es nicht bringt. Auch hinsichtlich jitter haben beide unterschiedliche Qualitäten: https://www.xilinx.com/content/dam/xilinx/support/documents/data_sheets/ds197-xa-artix7-overview.pdf
Ich glaube mich dunkel daran zu erinnern, dass man unter gewissen Konstellationen gewisse PLL-Implementierungen explizit nicht verketten darf (wie Vancouver erlaeutert hat), weil die erste so viel Jitter erzeugt, dass die nachfolgende nicht mehr richtig locken kann, das laeuft dann alles recht non-deterministisch. Die Core-Generatoren waren allerdings auch nicht auf Faktoren-/Teiler-Optimierung ausgelegt (>10 Jahre her ist das allerdings), Der Status quo bei Xilinx ist mir aber nicht bekannt, detailliertere Experimente habe ich nur mit der Lattice-Seite gemacht.
Duke Scarring schrieb: > Welche Anforderungen hast Du an den Taktjitter? Im üblichen Rahmen sollte es schon sein. Wenn ich die Werte von oben ansehe, dann macht es schon irgendwie Sinn darüber nachzudenken, das mit eigenen Eingaben klein zu machen. Um so leichter baut der FPGA. > Und: Hast Du eine Möglichkeit den Jitter zu messen? Ja :-) Vancouver schrieb: > PLLs regeln einen Jitter nicht zwangsäufig raus, im Worstcase erzeugen > sie sogar welchen (so wie es halt ist bei Regelkreisen: Das ist mir sehr wohl bewusst. Mich wundert es eben, dass das Werkzeug nicht fähig ist, allein schon durch das setup die günstigste Lösung anzubieten.
Angehängte Dateien:
Messtechniker schrieb: > Ich habe eine Zwischenfrequenz von 100.000 MHz, die in einer einzigen > PLL, die sonst nichts macht! auf 150.000 gebracht werden soll. Der > Wizzard antwortet mit einem Clockdivider ":2", einem MUL von 19.875 und > einem DIV von 6.625, also ziemlich krumm. OSC-Frequenz ist irgendwas > über 900 MHz. > > Ich hätte ein simles 3:2-Verhältnis erwartet, oder eines von 9:6, um > ähnlich hoch zu kommen. Warum tut der das? Macht es Sinn, das zu > überschreiben? Warum multiplizierst Du die 100 MHz nicht *3 und teilst dann durch 2? In einem 100 MHz - LVCMOS-Signal ist bis zu 1 GHz alles drinnen, muss man nur aussuchen und verstärken. Wenn die 900 MHz die eigentliche Quelle sind, warum nicht einfach durch 6 teilen?
Das tue ich ja, s.o. Das wundersame ist eben, dass: a) das tool nicht auch drauf kommt und krumme Werte vorschlägt b) diese angeblich besser ist obwohl sie es tatsächlich nicht sind
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.