|
Anzeige
|
Clock Distribution per FPGA
Gast
#6867941
Mal eine generelle Frage. Auf einem FPGA Board möchte ich eine 1ppm Clock verteilen und diese dazu an einen Pin des FPGA anschließen und an 4 Pins verteilen. Der FPGA ist sowieso da. Bleibt durch diese Verteilung der Jitter stabil oder handle ich mir durch den FPGA ärger ein. Die Phase der 4 Ausgänge ist dabei nicht so wichtig.
Gast
#6867946
natürlich bekommst du zusätzlichen Jitter. Aber ob du dir deswegen Ärger einfangst entscheidet deine Applikation/Anforderungen.
Gast
#6867959
Ich finde nur beim Spartan 3 nirgendwo wie viel Jitter zusätzlich erzeugt wird wenn ich einfach nur route. Hanno S. schrieb: > Ich finde nur beim Spartan 3 nirgendwo wie viel Jitter zusätzlich > erzeugt wird wenn ich einfach nur route. Das ist nicht einfach eine Zahl xy ps im Datenblatt. Das hängt ganz davon ab wie das konkret geroutet ist und damit von der konkret verwendeten Konfigurationsdatei. Selbst wenn Du den selben VHDL/Verilog-Code ein weiteres mal synthetisierst und routen lässt, kommt evtl. etwas anderes raus. Diese Daten könnte man theoretisch aus den Timing-Werten extrahieren die entweder die Toolchain ausspuckt oder die man per Reverse-Engineering aus der Toolchain extrahieren kann. Wenn der Jitter kritisch ist, würde ich lieber einen dedizierten Clock-Treiber-IC verbauen.
Gast
#6868071
Hanno S. schrieb: > eine 1ppm > Clock verteilen > Bleibt durch diese Verteilung > der Jitter stabil. Die > Phase der 4 Ausgänge ist dabei nicht so wichtig. Haeh? skew ist wichtig aber Phase nicht und alles wird in ppm gemessen? Eventuell schaust du dir mal die Funktionsweise einer FPGA internen Taktaufbereitung wie die MMCM in Xilinx serie7 FPGA#san, die kann in gewissen Grenzen jitter Kompensieren. -> UG472 Ansonsten ist natürlich immer eindedizierter clock distributor zu empfehlen und das Experiment an einem Evalboard.
Gast
#6868079
Ja skew ist hier nebensächlich. Jitter ist wichtiger. Dorian D. schrieb: > Ja skew ist hier nebensächlich. Jitter ist wichtiger. Was sind denn deine Jitter Anforderungen, sprich mit welchem Jitter gehts in den FPGA rein und wieviel darf da maximal drauf kommen? Hanno S. schrieb: > Auf einem FPGA Board möchte ich eine 1ppm Clock verteilen Bei 1Hz Taktfrequenz absolut nicht problematisch. Spielt sich dann ja im geruhsamen Mikrosekundenbereich ab. Das kann jedes FPGA... Ach, wie? Du willst eine höhere Taktfrequenz? Welche denn?
Gast
#6868144
Es geht um 10MHz und Jitter sollte +-10ps zusätzlich nicht überschreiten. Hanno S. schrieb: > Es geht um 10MHz und Jitter sollte +-10ps zusätzlich nicht > überschreiten. Dann wuerde ich die Clock nicht durch nenn FPGA jagen. ;-) Hanno S. schrieb: > Ich finde nur beim Spartan 3 nirgendwo wie viel Jitter zusätzlich > erzeugt wird wenn ich einfach nur route. Im Synthgesereport wird das als Max-Wert angegegen. Er nutzt dazu das, was zu bei dem OSC eingetragen hast, oder das, was in der PLL als Eingangsjitter gezeigt wurde, meistens 15ps oder so - und "addiert" dann den Regelfehler der PLL (was von der PLL-Einstellung abhängig ist) oder den multiplizierten Fehler bei einem DCM (der kleiner ist, sofern der Taktgernerator gut ist). Berücksichtigt wird (bei ISE nur teilweise!) inwiefern weitere PLLs oder gar Schaltungen an einem BUFG nuckeln, bzw über einen IBUFG verteilt wurden. Und dann kommt das Schaltverhalten, das eben leider nicht im Detail analysiert wird, sondern eben als MAX-Wert einfliesst. Siehe "fan out". DIESE Unsicherheit, dass er mal weniger und mal mehr verzögert (weil je nach Schaltungszustand) mal weniger und mal mehr in der Schaltung passiert und Strom gezogen wird, ist genau der Jitter! Leider können die FPGA-Tools meines Wissens das noch nicht nachbalancieren, indem sie Schaltungen invertieren und damit die Äste in der Belastung homgenisieren. Auch technischer Ebene ist das wohl nicht vorgesehen. Das können nur einige ASIC-Compiler. Beim FPGA musst du damit leben, dass du ohne Weitere Massnahmen erst einmal nicht weisst, wann innerhalb das Taktfensters (Periode-Budget) der Takt tastsächlich kommt und wann er wirkt. Tobias B. schrieb: > Dann wuerde ich die Clock nicht durch nenn FPGA jagen. ;-) Genau! FPGAs eignen sich nur sehr bedingt für die Taktverteilung, weil am Ende eher etwas mit 100ps rauskommt, wenn man 10ps reingesteckt hat. Richtig sauber arbeitet man so, dass man eine sehr tolerante PLL baut, die Eingänge mit 1-2 FF-Stuffen puffert, damit er routen kann und alle Ausgänge mit FIFOs puffert, damit der FPGA eine weitgehend ruhige und träge Clock hat. Hinten an den FIFOs übernimmt dann eine speziell von aussen in den FPGA geführte Clock aus einem Clock-Refresher, oder z.B. aus einem Wandler. Hanno S. schrieb: > Jitter sollte +-10ps zusätzlich Das sind im Kehrwert 100GHz. Diese Zahl passt für mich in keinster Weise zum Begriff "FPGA". Du musst woanders suchen.
Gast
#6868401
tja schrieb: > natürlich bekommst du zusätzlichen Jitter. Aber ob du dir deswegen Ärger > einfangst entscheidet deine Applikation/Anforderungen. Naja, eigentlich hat die Applikation, resp. deren Eingangsstufe' auch einen erheblichen Anteil an der Enstehung des Jitters. Es ist egal, wie gleichzeitig die Takte am clock driver losgeschickt werden, wenn auf Empfangsseite Stufen mit unterschiedliche (parasitäre) Kapazität (beeinflußt Flankensteilheit des Taktes) und Schaltschwelle sitzen. Deren zeitliches Verhalten ist auch noch von der lokalen Temparatur und der Spgs.-Versorgung am Empfänger abhängig, so das die jeweiligen empfangenen Takte nicht anders können, als immer ein paar Picosekunden in ihrer Auswirkung zu schwanken. Und man könnte sich mal anschauen, welche Möglichkeiten ein FPGA bietet wenigstens dass Zentrum (mittleres ETA) des jitters zu justieren, um die Auswirkungen des schwankenden (Abtast-)zeitpunktes zu optimieren: Beitrag "ODELAY für Spartan 7? Oder nich?" Und da Treiberstärke und Slewrate einen Einfluß auf den Jitter haben, kann man vielleicht über die IO-Settings SLEW und DRIVE der FPGA-Pins was drehen. Terminierung (on-board wie on die) wäre auch ein Thema bzgl. jitter: https://www.electronicdesign.com/technologies/boards/article/21789965/control-jitter-and-interference-during-clock-distribution
Gast
#6868414
Hanno S. schrieb: > Ich finde nur beim Spartan 3 nirgendwo wie viel Jitter zusätzlich > erzeugt wird wenn ich einfach nur route. Na, dann wirste wohl an einem Evalboard messen müßen. Und wenn bei Messung oder Testschaltung nichts relevantes ermitteln kannst, dann wird dich der zusärtzliche jitter auch nicht stören. Da der jitter ohnehin viel von der Schaltungsumgebung (Bufferung der Spannungsversorgung, Temperatur, fanout, parasitics auf PCB) abhängig ist, ist ohnehin fragwürdig wie zutreffend diesbezüglich Datenblattangaben in der Realität sind. Aber auch die Messung an einem einzelnen Evalboard hat nur begrenzte Aussagekraft wie es dann in Serie bei einem selbstgestrickten Board ausschaut. *Deshalb ist es auch dringend nötig zu ermitteln, welcher maximale jitter/skew 'verkraftbar' resp. f. die Anwendung akzeptabel ist.* Bei einen Design mit 100 ns Periode, verschwinden ein paar nanosekunden locker in den timing margins (setup, hold). Eine designvorgabe wie "sowenig jitter wie möglich" ist nicht hilfreich und zeigt lediglich, das der Autor der Spezifikation zu dumm oder zu faul, ist eine Fehlerabschätzung o.ä. durchzurechnen. Aber spätestens die quality assurance braucht solche Angaben zu 'akzeptablen Toleranzabsweichungen'.
Gast
#6869055
Lothar M. schrieb: > Hanno S. schrieb: >> Jitter sollte +-10ps zusätzlich > Das sind im Kehrwert 100GHz. Diese Zahl passt für mich in keinster Weise > zum Begriff "FPGA". Du musst woanders suchen. Er meint ja "zusätzlich", also z.B. 20ps vom Oscillator und 10ps durch den FPGA. Das hat mit der Frequenz direkt noch nichts zu tun. (Indirekt natürlich schon, weil die FPGAs aus gutem Grund nicht mit 1GHz zu takten sind.) Bei Clock und ppm denke ich eher an Frequenzstabilität. Da wären die Jittereffekte eigentlich nicht so wichtig. Nach mehreren Stufen könnte man einen Regelkreis schalten (Jitter Attenuator) um den Jitter wieder zu verringern. Wenn es aber wirklich um Jitter geht, dann wäre ppm eine untypische Einheit. Und wenn es wirklich um +-10ps Jitter geht (der Takt ist dann eigentlich egal), dann darf man das Signal nur über wenige spezielle digitale Treiber bringen. Eine FPGA-DCM erzeugt selber schon 200 bis 400 ps Clock-Jitter. Mir ist noch ein Rätsel wofür man so etwas benötigt. Vielleicht muss die Anforderung gar nicht so stark sein. Ist hier überhaupt eine PLL/DCM/MMCM gefordert? Nur weiterleiten was über einen IO reinkommt sollte auch rein über Taktnetze gehen.
Gast
#6869428
Gustl B. schrieb: > Ist hier überhaupt eine PLL/DCM/MMCM gefordert? Nur weiterleiten was > über einen IO reinkommt sollte auch rein über Taktnetze gehen. Unwahrscheinlich, weil wohl das Layout schon feststeht und nicht jedes routing über die clock trees möglich ist, es hat da dedicated clock eingang pins. Natürlich ist das auch von jeweiligen FPGA-typ abhängig. Und eine DCM kann auch als jitter cleaner/ clock deskewer benutzt werden. Aber natürlich kann man an dem Clock resources Blockbild wie im Anhang schauen, ob das gewünschte Routing möglich ist. Welche Wirkung es bezüglich des Jitters hat wird man aber in jedem Fall ausmessen müßen.
Angehängte Dateien:
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
