Hallo zusammen,
ich stehe vor einem Rätsel mit dem Routing, bzw. der Plazierung von
2-PLL's welche ihrem Tackt von einem 100MHz Eingangssignal erhalten
sollen.
Board ist das Arty A7.
Konkret habe ich folgende Konfiguartionen versucht:
PIN --> PLL1 + PLL2
PIN --> IBUF --> PLL1 + PLL2
PIN --> (IBUF1 --> PLL1) + (IBUF2 --> PLL2)
PIN --> IBUF0 --> (IBUF1 --> PLL1) + (IBUF2 --> PLL2)
Ich hoffe es ist so verständlich.
Konkret bekomme ich die Message:
[Place 30-172] Sub-optimal placement for a clock-capable IO pin and PLL
pair.
Demnach kann er die CLK Erzeugung/IBUF nicht auf die selbe Seite des
Chips, wie die Instanzen des Codes, welcher die CLKs verwenden soll,
bringen.
Sollte das nicht grade durch die BUF's entkoppelt werden können?
Ganz sicher ist es möglich, wäre super wenn jemand eine Idee hat, wie
man da ran geht? Brauche ich bestimmte BUF's?
Grüße,
Matthias
Probier mal einen BUFG nach dem Pin und stelle beide PLLs auf "No
Buffer" am Eingang. Aber auch das muss nicht klappen.
Du kannst mal den Clocking User Guide angucken, da ist für jeden Artix
ein Bild drin, welche CMTs und Routing dazwischen es gibt. Es ist nicht
alles möglich.
Da du DDR3 verwendest, ist die Clock-Verteilung oben, die nur den
Eingangspfad bis zur PLL zeigt, nur die 'halbe' Wahrheit, bei DDR3 gibt
meines Wissens der FPGA auch einen Takt an den Speicher aus.
Dann gibt es eine Unterschied zwischen IBUF und IBUFG. Das G steht für
global und meint das der IBUFG eines der wenigen globalen Netze treibt,
ein Netz das an an viele FF geht (aber nicht notwendigerweise an alle).
Für Takte möchte man BUFG verwenden, nicht BUF.
Die Meldung
" A PLL driving a BUFG must be placed on the same half side (top/bottom)
of the device"
weisst IMHO schon auf das Problem hin, das das netzwerk am BUFG nicht in
jede Ecke des FPGA 'reicht'. Und nicht jede PLL kann auf jeden BUFG
geschaltet werden, Stichwort "Clock region".
Jetzt gibt es aber (wieder bei DDR3) Fälle, wo der (vom DDR kommende
Lese-) Takt nur auf die (DDR-) IOPAD-PORT FF geht. Dafür hat Xilinx
wieder eigene BUF* erfunden. Ohne Blick in die Doku
https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf
wird man da keinen rechten Überblick erhalten. Ich hab mal eines der
Schemen aus dem Dokument hier angehangen um die Komplexität anzudeuten.
Du scheinst hier auch einen generierten memorycontroller zu verwenden.
IMHO ist es gut, erst ein Design nur mit dem memorycontroller zu bauen,
das (weitgehend) warnungsfrei durchläuft. Dann der Rest vom Design, auch
wenn es erfordert, das du weitere PLL's und Taktübergänge (i.e. FIFO's)
einführen musst.
Das sollte aber der Memorycontroller leisten können -ein
Speicherinterface für Datenströme aus unterschiedlichen Taktdomänen zur
Verfügung zu stellen.
Doku dafür:
https://www.xilinx.com/support/documentation/ip_documentation/ug586_7Series_MIS.pdf
In einer Clock Region befindet sich in einem FPGA der 7er Serie nur 1
PLL und 1 MMCM. In der Regel wirst du beide davon in deinem
DDR3-Controller brauchen. Wenn du jetzt die Clock auf eine PLL oder MMCM
in einer anderen Region bekommen willst, musst du die ueber einen BUFG
dorthin bekommen.
Ich rate stark davon ab, den BUFG vor den Eingang der PLL des
Speichercontrollers zu packen, da hier zusaetzlicher Noise im FPGA die
Zuverlaessigkeit stark beeintraechtigen wird.
Wofuer werden mehrere PLLs hier benoetigt? Normalerweise hat man an im
DDR3-Controller noch ein paar Abgriffe frei, die man frei verwenden
kann. Wenn wegen VCO-Frequenz die gewuenschte Frequenz nicht erzeugt
werden kann, kann man darueber zumindest die Original-Frequenz
regeneriert wieder ausgeben und dann via BUFG in einer anderen PLL/MMCM
verarbeiten.
Weitere Details finden sich im Dokument ug472.
Hannes schrieb:> da hier zusaetzlicher Noise im FPGA die> Zuverlaessigkeit stark beeintraechtigen wird.
Sorry, aber das klingt nach ungequirlter Bullenscheiße.
Wie definierst Du hier 'Zuverlässigkeit' ? Gehst Du davon aus, das der
FPGA seine Config-daten vergisst? Oder Physischen defekt erleidet?
Und wo lokalisierst du den angeblichen Extra-'Noise'?
Wie breitet er sich im FPGA aus?
'Leitungsgebunden' ?
'Kapazitiv'? Oder beziehst Duch Dich auf Phasenrauschen auf einer
Taktleitung? Dessen Auswirkungen werden aber durch die STA betrachtet
und haben bei entsprechenden Constraining keinerlei Einfluß. Und ich
bezweifle, das durch einen BUFG die Phase sonderlich beeinflußt wird,
zumal die bei dir nachgeschaltete PLL auch als jitter-filter arbeiten
kann.
Vielleicht meint er das Phasenrauschen. Es gibt durchaus unglückliche
Konfigurationen, der Artix ist bei vielen Sachen an der Kante, z.B. bei
5GBit/s MGT oder DDR3 muss man schon sehr genau aufpassen, da gibts auch
Fälle wo eine blöde Platzierung oder Auswahl der Clocking Komponenten
dann dazu führt dass was nicht klappt. Gerade beim MGT gibts ja da
einige seltsame Workarounds...PLL im Power Down halten damit keine
Ripple auf der Versorgung entstehen und sowas...DDR3 MIG ist je nach
Geschwindigkeit auch hart an der Grenze.
Christian R. schrieb:> Gerade beim MGT gibts ja da> einige seltsame Workarounds...PLL im Power Down halten damit keine> Ripple auf der Versorgung entstehen und sowas...DDR3 MIG ist je nach> Geschwindigkeit auch hart an der Grenze.
Hm, das würde ich jetzt nicht 'Zuverlässigeit' nennen sondern
Bitfehlerrate (beim MGT) - BER - an der man auch noch mit etlichen
anderen Parameter und ECC drehen kann. MGT halte ich da jetzt auch für
kritischer wegen der Taktrückgewinnung und höhren Baudraten etc.,
während es beim DDR mit rd- und wr-strobes noch 'redundanzen' gibt.
Und jetzt klang das bei 'Hannes' so, das auch andere Teile des FPGA's
beeinträchtigt werden, auch wenn sie mit 'niedrigen' Takt von einer
anderen PLL/MMCM betrieben werden. Da wäre eine klare Ansage, wie groß
dieses 'Extra-rauschen' (in picosekunden) tatsächlich ist, hilfreich und
zielführend. Ein pauschales 'Abraten' wegen 'starker Beeinträchtigung'
ist es IMHO nicht.
Klartexter schrieb:> m, das würde ich jetzt nicht 'Zuverlässigeit' nennen sondern> Bitfehlerrate (beim MGT) - BER - an der man auch noch mit etlichen> anderen Parameter und ECC drehen kann.
Das äußert sich erst einmal nicht in Bitfehlern, sondern einfach nur in
größerem Jitter und veringertem Timing Budget, d.h. er kriegt es
routingtechnisch nicht in den Griff. Theoretisch, wie praktisch.
