Forum: FPGA, VHDL & Co. Artix 7 / Vivado Problem mit Clock-Routing/Placement von 2PLLs über BUFs an einem PIN


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 Matthias (Gast)


Lesenswert?

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.
1
  IBF_sys/IBUF_inst (IBUF.O) is locked to IOB_X1Y76
2
   ddr3_ctrl_inst/clk_100_to_166_200/inst/plle2_adv_inst 
3
         (PLLE2_ADV.CLKIN1) is provisionally placed by clockplacer on
4
         PLLE2_ADV_X1Y1
5
   uart_tx_inst/clk100_to_120/inst/plle2_adv_inst 
6
         (PLLE2_ADV.CLKIN1) is provisionally placed by clockplacer on    
7
         PLLE2_ADV_X0Y1
8
9
  The above error could possibly be related to other connected 
10
        instances. Following is a list of 
11
  all the related clock rules and their respective instances.
12
13
  Clock Rule: rule_pll_bufg
14
  Status: PASS 
15
  Rule Description: A PLL driving a BUFG must be placed on 
16
        the same half side (top/bottom) of the device
17
   ddr3_ctrl_inst/clk_100_to_166_200/inst/plle2_adv_inst 
18
         (PLLE2_ADV.CLKFBOUT) is provisionally placed by clockplacer on 
19
         PLLE2_ADV_X1Y1
20
   ddr3_ctrl_inst/clk_100_to_166_200/inst/clkf_buf (BUFG.I) is 
21
         provisionally placed by clockplacer on BUFGCTRL_X0Y31
22
23
  Clock Rule: rule_pll_bufg
24
  Status: PASS 
25
  Rule Description: A PLL driving a BUFG must be placed on 
26
        the same half side (top/bottom) of the device
27
   uart_tx_inst/clk100_to_120/inst/plle2_adv_inst 
28
        (PLLE2_ADV.CLKFBOUT) is provisionally placed by clockplacer on 
29
        PLLE2_ADV_X0Y1
30
   and uart_tx_inst/clk100_to_120/inst/clkf_buf (BUFG.I) is 
31
        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

von Christian R. (supachris)


Lesenswert?

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.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Hannes (Gast)


Lesenswert?

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.

von Klartexter (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von Klartexter (Gast)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.