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
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:
1 | Global Maximum Fanout : 100000 |
2 | |
3 | ... |
4 | |
5 | | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)| |
6 | +--------------+--------------+------+------+------------+-------------+ |
7 | | 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
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.
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.
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!
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.