Artix 7 / Vivado Problem mit Clock-Routing/Placement von 2PLLs über BUFs an einem PIN

[Matthias (Gast)]

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.

  IBF_sys/IBUF_inst (IBUF.O) is locked to IOB_X1Y76
   ddr3_ctrl_inst/clk_100_to_166_200/inst/plle2_adv_inst 
         (PLLE2_ADV.CLKIN1) is provisionally placed by clockplacer on
         PLLE2_ADV_X1Y1
   uart_tx_inst/clk100_to_120/inst/plle2_adv_inst 
         (PLLE2_ADV.CLKIN1) is provisionally placed by clockplacer on    
         PLLE2_ADV_X0Y1

  The above error could possibly be related to other connected 
        instances. Following is a list of 
  all the related clock rules and their respective instances.

  Clock Rule: rule_pll_bufg
  Status: PASS 
  Rule Description: A PLL driving a BUFG must be placed on 
        the same half side (top/bottom) of the device
   ddr3_ctrl_inst/clk_100_to_166_200/inst/plle2_adv_inst 
         (PLLE2_ADV.CLKFBOUT) is provisionally placed by clockplacer on 
         PLLE2_ADV_X1Y1
   ddr3_ctrl_inst/clk_100_to_166_200/inst/clkf_buf (BUFG.I) is 
         provisionally placed by clockplacer on BUFGCTRL_X0Y31

  Clock Rule: rule_pll_bufg
  Status: PASS 
  Rule Description: A PLL driving a BUFG must be placed on 
        the same half side (top/bottom) of the device
   uart_tx_inst/clk100_to_120/inst/plle2_adv_inst 
        (PLLE2_ADV.CLKFBOUT) is provisionally placed by clockplacer on 
        PLLE2_ADV_X0Y1
   and uart_tx_inst/clk100_to_120/inst/clkf_buf (BUFG.I) is 
        provisionally placed by clockplacer on BUFGCTRL_X0Y28

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

[Christian R. (supachris)]

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.

[Fpgakuechle K. (Gast)]

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

[Hannes (Gast)]

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.

[Klartexter (Gast)]

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.

[Christian R. (supachris)]

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.

[Klartexter (Gast)]

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.

[Weltbester FPGA-Pongo (Gast)]

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.