Hallo, ich habe jetzt an verschiedenen Stellen gelesen, dass der GTX/GTH Transceiver (im Falle von Xilinx) ein besseres Jitter-Verhalten für ein Signal erzeugt. Laut [1] ist der Quad-based LC tank PLL (QPLL) dafür zuständig. Was wäre, wenn man auf den GTX/GTH Transceiver verzichtet und man die Funktionalität auf dem FPGA implementiert. In [2] werden Gründe für den Jitter gegeben und auf Seite 15 schematisch dargestellt wie ein Jitter auf einem Signal verringert werden kann. Meine Fragen dazu sind: Macht Sinn eine PLL auf einem FPGA nachzubauen? Laut [3] ist es möglich, ist es aber auch sinnvoll für die Jitter Reduktion? Gibt es noch weitere Verfahren für die Jitter Reduktion als in [2] beschrieben? VG [1] https://www.xilinx.com/support/documentation/user_guides/ug476_7Series_Transceivers.pdf [2] https://www.all-electronics.de/wp-content/uploads/migrated/article-pdf/123784/an687.pdf [3] https://www.mikrocontroller.net/articles/PLL
Andre schrieb: > ich habe jetzt an verschiedenen Stellen gelesen, dass der GTX/GTH > Transceiver (im Falle von Xilinx) ein besseres Jitter-Verhalten für ein > Signal erzeugt. Ein besseres Jitter Verhalten im Vergleich zu was? Andre schrieb: > Was wäre, wenn man auf den GTX/GTH Transceiver verzichtet und man die > Funktionalität auf dem FPGA implementiert. Das wirst du nicht hinbekommen. Der Transceiver hat unter anderem einen einen analog Teil, welchen du nicht in Logik nachbauen kannst. Z.B. den RX Equalizer mit welchen die hohen Signalraten erst moeglich werden. Andre schrieb: > Macht Sinn eine PLL auf einem FPGA nachzubauen? Laut [3] ist es > möglich, ist es aber auch sinnvoll für die Jitter Reduktion? Es gibt Faelle da macht das durchaus Sinn. Z.B. wenn du ein Signal via MGT reinbekommst, die Clock recoverst und das Signal mit der recoverten Clock auf den naechsten MGT ausgeben willst ohne dabei die Clock aus dem FPGA zu routen und ueber einen Jitter Attenuator wieder in den FPGA zu speisen. Gibt von Xilinx auch eine Application Note dazu XAPP589. Funktioniert astrein. Andre schrieb: > Gibt es noch weitere Verfahren für die Jitter Reduktion als in [2] > beschrieben? Kann ich aktuell nicht beantworten, dazu muss ich erstmal [2] lesen. ;-)
> Gibt es noch weitere Verfahren für die Jitter Reduktion Ohne jetzt [2] gelesen zu haben: Du musst "nur" dafuer sorgen, dass der Jitter keinen Einfluss auf deine Empfangsdaten hat. Wenn du z.B. mit der 20 fachen Frequenz dein Signal einlesen kannst, kannst du die eingelesenen Daten recht bequem an deine reale Taktdomaene anpassen. Nach dem Eintakten ist der Jitter nicht mehr relevant. Wenn dein FPGA dieses 20 fache Oversampling nicht unterstuetzt, dann bist du auf die im FPGA ja vorhandene "analoge" Loesung angewiesen.
Kann man bei den GTX-Transceivern etc den Sender- und den Empfänger-Pfad eigentlich getrennt benutzen? Die Clock könnte von mir aus gemeinsam sein oder auch überhaupt lokal synchron. Die Absicht ist, möglichst viele ADCs und DACs mit JESD-204B anzuschließen. Mit 2 Transceivern pro ADC/DAC-Paar brauche ich ein viel zu großes FPGA. Gruß, Gerhard
Gerhard H. schrieb: > Kann man bei den GTX-Transceivern etc den Sender- und den Empfänger-Pfad > eigentlich getrennt benutzen? Die Clock könnte von mir aus gemeinsam > sein oder auch überhaupt lokal synchron. Jep, das sollte gehn. Du kannst RX/TX sogar jeweils eine eigene PLL und sogar eine eigene externe Refclock spendieren. Aufpassen musst du nur, dass du halt innerhalb eines Quads (Xilinx fasst immer 4 RX/TX Paare zu einem Quad zusammen) nur einen gemeinsame PLL Teil hast (die QPLL), welche eben von den beiden Refclocks gespeist werden. Innerhalb der Transceiver haben dann die RX/TX wieder ihre eigene Channel PLL (CPLL) welche von der QPLL gespeist werden. Die QPLL direkt verwenden geht allerdings auch UG476 hat dazu fuer die 7 Series alle noetigen Infos. Eine gute Uebersicht bietet Figure 1-2. Wenn du dein Ziel genauer formulierst, kann ich dir etwas bessere Infos geben. Sieht aber gut aus, dass das was du moechtest funktioniert.
Danke für die Antworten. Ich würde es an folgendem Bespiel zum Testen einfach halten. Ein Clock-Signal des PS würde direkt an ein GPIO Pin geführt werden. Diese würden ein Rechteck-Signal am Oszi sichtbar machen mit der ca. eingestellten Frequenz im PS. Dabei würde sich ein Jitter mit x ns ergeben. Vergleichbar dazu würde man ein PLL zwischen Clock und GPIO schalten und den Jitter vergleich. Die Grundfrage ist, mit welchem Signal-Jitter kann man ein Xilinx der Zynq-Serie betreiben, wenn man keinen GTX Transceiver verwenden? Nur um einen Bereich anzugeben: Mir ist ein Projekt bekannt, das einen Zynq 7030 mit GTX Transiver verwendet, welches einen Jitter von ca. 500 ps hat. In [4] auf Seite 15 ist die Anzahl der PLLs der verschiedenen Zynqs angegeben (auch ohne Transceiver). Diese können mit dem Clock-Wizard [5] in ein Design integriert werden. Gibt es dazu Messungen um eine Aussage über den Signal-Jitter machen zu können? In [6] werden 3% von FCLK angegeben. Kann das jemand bestätigen? [4] https://www.xilinx.com/support/documentation/data_sheets/ds190-Zynq-7000-Overview.pdf [5] https://www.xilinx.com/support/documentation/ip_documentation/clk_wiz/v6_0/pg065-clk-wiz.pdf [6]https://www.xilinx.com/support/answers/56156.html
Gerhard H. schrieb: > Die Absicht ist, möglichst > viele ADCs und DACs mit JESD-204B anzuschließen. Mit welcher Datenrate soll JESD204B laufen? Wenn die nicht zu hoch ist, geht es auch über normale IOs... Duke
Tobias B. schrieb: > Wenn du dein Ziel genauer formulierst, kann ich dir etwas bessere Infos > geben. Sieht aber gut aus, dass das was du moechtest funktioniert. Das soll ein SDR-artiges Gebilde werden mit mindestens 4 ADCs und GHz-Abtastrate + wenigstens 2 Sendekanälen. Die richtig schnellen ADCs haben heute aber schon einen Downconverter / Filter, da tut man sich wohl keinen Gefallen mehr wenn man versucht, Transceiver zu sparen. Die 10 GHz++ Datenrate stört mich nicht. Das ist alles noch etwas schwammig / im frühen Brutstadium. Für niedrige Frequenzen habe ich mein Phasenrauschmessproblem erst mal mit einem Timepod erschlagen. Gruß, Gerhard
:
Bearbeitet durch User
Andre schrieb: > Die Grundfrage ist, mit welchem Signal-Jitter kann man ein Xilinx der > Zynq-Serie betreiben, wenn man keinen GTX Transceiver verwenden? Deine Signal duerfen soviel Jitter haben wie du magst. In dem Constraints gibts du diesen Jitter Wert an und die Timings werden entsprechend angepasst, bzw. beim P&R gibt es weniger Marge und die Timings failen schneller. Die Frage ist was genau willst du denn "betreiben"? Logik, den ARM Prozessor, IO/s, ...? Andre schrieb: > Dabei würde sich ein Jitter mit x ns > ergeben. Ich hoffe der Jitter liegt nur im ps Bereich, sonst ist da echt was faul. ;-)
Tobias B. schrieb: > Die Frage ist was genau willst du denn "betreiben"? Logik, den ARM > Prozessor, IO/s, ...? In erster Linie will ich nur ein "sauberes" Signal auf einen Gpio legen und schauen wie hoch man die Frequenz drehen kann. Als Nächstes wäre dann festzustellen, was die limitierenden Faktoren sind und ab wann man auf einen Zynq mit einem GTX/GTH Transceiver wechseln müsste. > Andre schrieb: >> Dabei würde sich ein Jitter mit x ns >> ergeben. > > Ich hoffe der Jitter liegt nur im ps Bereich, sonst ist da echt was > faul. ;-) Kommt nur darauf an wie weit man das Komma verschiebt :P
Andre schrieb: > In erster Linie will ich nur ein "sauberes" Signal auf einen Gpio legen > und schauen wie hoch man die Frequenz drehen kann. Das steht -- etwas verklausuliert -- im Datenblatt (DC and AC Switching Characteristics) des FPGAs. Bei Spartan7/Zynq geht aktuell irgendwas ca. 1 GHz. Duke
Ein paar pdfs : guurgel "ADC jitter requirements" https://www.analog.com/media/en/reference-design-documentation/design-notes/dn1013f.pdf http://www.ti.com/lit/an/slyt705/slyt705.pdf https://www.electronicdesign.com/technologies/analog/article/21789742/adc-performance-whats-jitter-got-to-do-with-it https://ieeexplore.ieee.org/document/1400385 https://www.eetimes.com/understanding-the-effect-of-clock-jitter-on-high-speed-adcs-part-1-of-2/ https://asl.epfl.ch/wp-content/uploads/publications/conferences/iscas_2010_b.pdf https://www.dsprelated.com/showarticle/1160.php
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.