Clock Buffer Verstaendnisfrage

[Guenther (Gast)]

Hallo,

ich arbeite mich derzeit in VHDL und Xilinx' Virtex7-Serie ein und hätte 
da eine Frage:
Bei den Language-Templates habe ich eine Kategorie "Clock-Buffers" 
gefunden. Ich habe auch folgenden Thread gelesen:
Beitrag "Verständnisfrage zu Clk Buffern & Clk Netzen im FPGA"
Aber ich verstehe leider trotzdem nicht, wann genau ich jetzt einen 
global clock buffer, HROW clock buffer, I/O clock buffer, multi-Region 
clock buffer oder einen regional clock buffer wirklich brauche.
Wenn ich also eine Entity habe, die den Clock auf mehrere Components 
verteilen soll, ab wann kann ich denn davon ausgehen, dass der Fanout zu 
hoch wird?
Bzw. was ist, wenn ich z.B. die OSerDes eines Pins benutzen möchte? In 
dem obigen Thread steht, dass man dann stärker auf die Nutzung von Clock 
Buffern achten müsste.


Viele Grüße

[Duke Scarring (Gast)]

Guenther schrieb:
> Aber ich verstehe leider trotzdem nicht, wann genau ich jetzt einen
> global clock buffer, HROW clock buffer, I/O clock buffer, multi-Region
> clock buffer oder einen regional clock buffer wirklich brauche.
Nimm einen BUFG bzw. IBUFG für Deinen Eingangstakt.
Das Tool wird Dir schon sagen, wenn es damit nicht mehr klarkommt.
Dann kannst Du Dich immer noch um die spezielleren Buffer kümmern.

> Wenn ich also eine Entity habe, die den Clock auf mehrere Components
> verteilen soll, ab wann kann ich denn davon ausgehen, dass der Fanout zu
> hoch wird?
Beim Spartan6 von Xilinx steht sowas im Report:

Global Maximum Fanout              : 100000

...

| Clock Net    |   Resource   |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
+--------------+--------------+------+------+------------+-------------+
|          clk | BUFGMUX_X3Y13| No   | 5899 |  0.721     |  2.374      |

Da ist also noch jede Menge Luft...

> Bzw. was ist, wenn ich z.B. die OSerDes eines Pins benutzen möchte? In
> dem obigen Thread steht, dass man dann stärker auf die Nutzung von Clock
> Buffern achten müsste.
Genau.
Willst Du denn die SerDes verwenden?
Was ist denn Dein konkretes Problem?

Duke

[Christian R. (supachris)]

Wenn du den Takt ausschließlich korrekt verwendest, also mit 
rising_edge() oder interne Primitiven anschließt die einen Takteingang 
haben, dann wird der passende IBUFG oder BUFG automatisch eingefügt, 
ebenso wenn du eine PLL oder DCM per Wizzard parametrierst. Anders sieht 
das bei speziellen Konstrukten wie den SERDES oder MGT aus, die brauchen 
ganz spezielle Buffer und wie die verschaltet werden müssen steht dann 
im jeweiligen User Guide.

[berndl (Gast)]

Guenther schrieb:
> Wenn ich also eine Entity habe, die den Clock auf mehrere Components
> verteilen soll, ab wann kann ich denn davon ausgehen, dass der Fanout zu
> hoch wird?

Das funktioniert nicht so. Dein Clock-tree geht ja sowieso an jedes FF 
des Chips. Auch im Clock-tree sind weitere Buffer fest eingebaut. 
Deshalb hast du z.B. lokal links oben (fast) keinen skew, zwischen 2 FFs 
links-oben vs. rechts-unten aber sehr wohl einen groesseren skew.

Also: Fuer deine FFs brauchst du dich da um nix kuemmern, das hat der 
Hersteller schon gemacht.

[Guenther (Gast)]

Vielen Dank für eure Hilfe. Das macht das ganze jetzt schon mal etwas 
klarer.

Christian R. schrieb:
> Wenn du den Takt ausschließlich korrekt verwendest, also mit
> rising_edge() oder interne Primitiven anschließt die einen Takteingang
> haben

Wird genau so gemacht.

berndl schrieb:
> Deshalb hast du z.B. lokal links oben (fast) keinen skew, zwischen 2 FFs
> links-oben vs. rechts-unten aber sehr wohl einen groesseren skew.

Verstanden. Danke!

Christian R. schrieb:
> Anders sieht
> das bei speziellen Konstrukten wie den SERDES oder MGT aus, die brauchen
> ganz spezielle Buffer und wie die verschaltet werden müssen steht dann
> im jeweiligen User Guide.

Dann werde ich mir den User Guide zu den SERDES nochmal genauer 
anschauen und ggf. nochmal fragen, falls doch noch etwas offen sein 
sollte.

Vielen Dank!