Forum: FPGA, VHDL & Co. Clock Distribution per FPGA


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Hanno S. (Gast)


Lesenswert?

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.

von tja (Gast)


Lesenswert?

natürlich bekommst du zusätzlichen Jitter. Aber ob du dir deswegen Ärger 
einfangst entscheidet deine Applikation/Anforderungen.

von Hanno S. (Gast)


Lesenswert?

Ich finde nur beim Spartan 3 nirgendwo wie viel Jitter zusätzlich 
erzeugt wird wenn ich einfach nur route.

von Gerd E. (robberknight)


Lesenswert?

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.

von Uhrwerkschmierer (Gast)


Lesenswert?

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.

von Dorian D. (Gast)


Lesenswert?

Ja skew ist hier nebensächlich. Jitter ist wichtiger.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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?

: Bearbeitet durch Moderator
von Hanno S. (Gast)


Lesenswert?

Es geht um 10MHz und Jitter sollte +-10ps zusätzlich nicht 
überschreiten.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Fpgakuechle K. (Gast)


Lesenswert?

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

von Fpgakuechle K. (Gast)


Lesenswert?

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

von Techniker (Gast)


Lesenswert?

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

von Klakx -. (klakx)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

Ist hier überhaupt eine PLL/DCM/MMCM gefordert? Nur weiterleiten was 
über einen IO reinkommt sollte auch rein über Taktnetze gehen.

von Fpgakuechle K. (Gast)


Angehängte Dateien:

Lesenswert?

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.

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
Noch kein Account? Hier anmelden.