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