Ich habe eine Entwicklungsplatine zum Test eines Trasmitter-Chips, der mit eigenem Quarz läuft, der hohen Datenrate wegen. Es handelt sich um einen 156.25MHz Quarz mit 25ppm. Diese Platine soll zum Testen dienen, bevor wir das Teil auf unser board bringen, muss also zum Austesten von draußen mit Daten beschickt werden. Leider klappt das externe Takten nicht, weil wir den Takt mit unserem FPGA nur über eine PLL herstellen können, was durch die Übertragung so stark verschlechtert ist, dass der Chip nicht arbeitet. Wir müssen uns also an den Quarz auf dieser Testplatine synchronisieren, oder das design des dortigen FPGAs so ändern, dass sich deren Takt auf den unseren anpasst. Ich habe also ziemlich genau 156.25 MHz von uns und fast das gleiche in gut von ihm. Kann man eine FPGA-PLL durch feedback oder wie auch immer so ziehen, dass sie durch den Quarz stabilisiert wird, ohne den Bezug zum Eingangstakt zu verlieren? Oder wie kann man alternativ den Quarz als Filter nutzen? Der ist als reiner Quarzoszillator mit Kapazitäten an 2 Eingangspins des Ziel-FPGAs und des Zielchips getackert. Den müsste man irgendwie auf unseren Takt ziehen. Reicht es mit einem weiteren Kondensator auf einen Pin zu gehen und unseren Takt mit aufzubringen? Gfs über einen Widerstand / mit Abschluss? Jemand eine Idee?
Welches FPGA und welche Transceiver sollen verwendet werden? Typischerweise füttert man denen einen genauen Takt, eben den den du da hast. Die Transceiver haben ihre eigene PLL im FPGA. Ja, extern ... mit nur diesem einen Taktgeber könntest du auf einen Clockbuffer mit zwei Ausgängen gehen, die sind dafür da. Und sonst kannst du den Takt vielleicht im FPGA ohne PLL wieder ausgeben. Also dort im FPGA abzweigen, einmal intern für die Transceiver und einmal ohne PLL direkt wieder ausgeben. Oder hat dein externer Chip einen Taktausgang über den er den Eingangstakt weiterreicht?
So sieht das in etwa aus: Die Quarz-PLL-Einheit auf der EVAL-Platine soll synchronisiert werden mit den Takt aus der PLL der derzeitigen Hauptplatine. Ziel ist ein besserer Takt für den DAC. Man kann leider den Takt von da hinten nicht nach vorn ziehen. Die Schwierigkeit besteht auch darin dass das Eingabe-System auch synchron laufen soll. Das muss von vorn gesteuert werden.
Grundsätzlich ist das System in Ordnung und wird auch später so aufgebaut, daß es einen Taktgeber gibt und alles auf einer Platine steckt. Zum Testen muss aber das EVAL-System so genutzt werden, wie es ist. Direkt den Takt von außen zu beaufschlagen führt zu einem zu schlechten Takt innen im Ausgabe-System. Es ist dort leider kein Clock-Refresher oder eine PLL drauf. Ich kann nur versuchen, den Quarz zu ziehen. Mit Transceivern im FPGA hat das nichts zu tun. Die stecken im Daten-Kanal mit dem dicken Pfeil. Der Takt dort ist ein anderer. Er wird auch im Zielsystem rekonstruiert und funktioniert. Der ist aber nicht als DAC-Takt zu gebrauchen. Es funktioniert zwar aus digitaler Sicht, hat aber zuviel jitter um ein sehr sauberes Signal zu liefern. Das Signal ist zu verrauscht.
Das wäre die Schaltung. Läuft als Piece-Oszillator. Ließe sich so umbauen.
A. F. schrieb: > Kann man eine FPGA-PLL durch feedback oder wie auch immer so ziehen, > dass sie durch den Quarz stabilisiert wird, ohne den Bezug zum > Eingangstakt zu verlieren? Hmm. Mir fallen auf Anhieb Jitter-Cleaner ein, z.B. sowas: https://holzworth.com/products/amplifiers/hx2410 Andererseits kann man eine (langsame) PLL auch in Software bauen. Dazu müsste man die Möglichkeit haben, den Takt im FPGA zu beeinflussen. Aber was davon bei Euch funktionieren könnte, kann man aus der Ferne schlecht beurteilen.
Eine Software-PLL geht gar nicht. Das muss möglichst exakt sein. Ich brauche schon die 156.25 oder mindestens die Hälfte davon. Im Schaltkreis rechts ist noch eine PLL die einen Divider-Eingang besitzt, der durch 2 teilt und überbrückbar ist.
A. F. schrieb: > Das muss möglichst exakt sein. Ich liebe solche Aussagen. Die bekomme ich hier auch immer von meinen Wissenschaftlern. Das der Unterschied zwischen 1 ns und 100 ps (Zeitauflösung/Jitter/whatever) im Aufwand nicht nur Faktor 10 beträgt, weil ggf. komplett andere Ansätze benötigt werden, wird geflissentlich ignoriert :-( So und nun Du: Wie groß ist der Jitter und wie groß darf er maximal sein? Habt Ihr Euch schon mal das Phasenrauschspektrum angeschaut? Vielleicht erkennt man da schon eine dominierende Störquelle und kann diese gezielt angehen...
Ich bezweifle ein wenig, ob das klappen kann. Solche Quarze lassen sich nur ziehen, wenn sie ein geringes Q haben. Auch funktioniert das nur bis zu einer gewissen maximalen Frequenz. Der FPGA-Ausgang muss da einiges treiben, um gegen den Quarz anzugehen, d.h. die Widerstände müssen so dimensioniert sein, dass die Verluste des Quarz stabil ausgeglichen werden und andererseits auch so, dass die Schaltung noch beeinflussbar bleibt. Ich habe so etwas schon genutzt, allerdings bei einem 25 MHz-Quarz und der musste nur um 10-15ppm gezogen werden. Der entstehende Jitter wurde dann mit einer internen PLL gefiltert. Es gibt dann trotzdem noch 2 Probleme: 1 ) Einen guten Takt bekommt man im FPGA nur mit einem CCI, d.h. so wie in der Zeichnung einen Inverter draufsetzen und dann als Takt zu benutzen, haut für > 100MHz kaum mehr hin und wenn es funktioniert, hat man eine minderwertige Taktleitung. Besser als PLL intern wird das nicht. Wenn das mit dem FPGA gemacht werden soll, muss der Taktabgriff nochmals extra erfolgen. 2) Es kann Probleme geben, den Takt der von vorn ankommt, überhaupt einzufangen. Man kann da nicht einfach hoffen, dass das funktioniert. Man braucht dann schon eine Schaltung, die den treibenden Ausgang langsam verschiebt, bis er einrastet. Das müsste auch gemessen werden. D.h. man braucht beide Takte, den zu synchronisierenden und den auf den aufsynchronisiert werden soll, beide im FPGA sichtbar.
Rick D. schrieb: > So und nun Du: Wie groß ist der Jitter und wie groß darf er maximal > sein? Möglichst klein, damit es zu guten Messungen kommt.
Die 156 MHz sind nun jetzt nicht so hoch, dass man sie nicht rueber ziehen koennte. Es muss leider derselbe Takt sein, ein aehnlicher genuegt nicht. Doof waer's wenn er phasengenau sein muesste, dann muesste noch eine Delay line her. Also einfach den Quarz durch ein Kabel ersetzen
Purzel H. schrieb: > Die 156 MHz sind nun jetzt nicht so hoch, dass man sie nicht rueber > ziehen koennte. Wo siehst du denn die Grenze? Was sagst du zu meiner Schaltung?
Frequenzen phasengenau zu teilen ist einfacher als zu vervielfachen. Kann man nicht die 156.25MHz auch als Takt für den Rest herunterteilen? Vielleicht mit einem DDS, der ist phasenstarr, wenn auch mit Jitter.
A. F. schrieb: > Wo siehst du denn die Grenze? > > Was sagst du zu meiner Schaltung? Handelt es sich um einen Grundton- oder Obertonquarz? Der Einrastfrequenzbereich über den injection locking funktioniert, hängt von der Amplitude des Oszillator, der Amplitude der Steuerquelle und der Betriebsgüte des Quarzes ab. Schließe einen geeigneten Steuersender über ein Koaxkabel an und mit einem 50 Ohm Shuntwiderstand am Ende ab und speise diesen über einen kleinen Kondensator (wenige pF) in den Eingang des Pierce Oszillator ein. Variiere dabei den Pegel und die Frequenz des Steuersenders um den nutzbaren Einrastbereich zu ermitteln.
:
Bearbeitet durch User
Robert M. schrieb: > Handelt es sich um einen Grundton- oder Obertonquarz? Das könnte ich mir aussuchen. Christoph db1uq K. schrieb: > Frequenzen phasengenau zu teilen ist einfacher als zu vervielfachen. > Kann man nicht die 156.25MHz auch als Takt für den Rest herunterteilen? Nein, die Freq wird so benötigt. Da sind auch noch CLK-Refresher drauf und allesmögliche. Runtergeteilt kann / soll werden, um zu synchen.
Bitte 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.