Ich hab eine PLL in einem Spartan 6 verwendet um den Takt für eines DDS zu erzeugen (50MHz rein, x10, dann /5 also 200MHz - zum spielen). Das ganze klappt dann nur, wenn ich den Ausgang der PLL über einen BUFG Puffer an den DDS CLKIN anschließe (VHDL Instantation). Ist das so richtig oder mach ich dabei einen Fehler ? Bei einem einfachen Zähler brauche ich den BUFG nicht. Thomas
Der BUFG wird verwendet um ein Signal auf die globalen Clocking Ressourcen zu bringen. Dieser ist absolut notwendig, wenn dieser Takt im FPGA verwendet werden soll.
Thomas S. schrieb: > (50MHz rein, x10, dann /5 also 200MHz - zum spielen) Nur falls Du Dich wunderst, dass irgendwelche gemessenen Zeiten nicht stimmen... Gruß, Thomas
Hallo Thomas T., alles klar. Ist natürlich x20 gewesen. Dann passt es auch. Danke für den Hinweis.
:
Bearbeitet durch User
Thomas S. schrieb: >... Bei einem einfachen Zähler >brauche ich den BUFG nicht. Du meinst wohl ohne PLL brauchst du kein BUFG? In diesem Fall wird automatisch ein BUFG vom Synthesetool erzeugt. Schau einfach mal im FPGA-Editor nach.
Wie verhällt es sich dbei mit dem Problem, wenn Xilinx Synthese den Fehler meldet, dass es einen CLockpfad gibt, wo der BUFG nicht automatisch eingesetzt wurde und man ein constraint nachrüsten soll. Ist der Buffer dann drin oder nicht?
Mitleser schrieb: > Ist der Buffer dann drin oder nicht? Vermutlich nicht. Nachschauen im clock report.
Ich kapiere es irgenwie nicht, wann die Software den BUFG automatisch einfügt und wann nicht. Es gelingt mir auch nicht einen 2. Ausgang aus der PLL auf einen PIN zu legen. Die ISE meint ich solle einen weiteren BUFG instanziieren und wenn ich das mache wird gemeckert das der BUFG nicht für den Output auf einen PIN wäre. Das ganze ist doch etwas verwirrend ?
Thomas S. schrieb: > Ich kapiere es irgenwie nicht, wann die Software > den BUFG automatisch einfügt und wann nicht. Hängt ab von der Anzahl der angeschlossenen Flipflops. Thomas S. schrieb: > Die ISE meint ich solle einen weiteren BUFG instanziieren > und wenn ich das mache wird gemeckert das der BUFG > nicht für den Output auf einen PIN wäre. Der BUFG und das Taktnetz dienen dazu sicherzustellen, dass alle angeschlossenen Flipflops innerhalb des FPGA exakt zum gleichen Zeitpunkt schalten. Legt man den über BUFG gerouteten clock auch auf einen Ausgangspin, werden die aussen angeschlossenen Flipflops später als die internen Flipflops schalten, und das führt zu einer Warnung. Diese Warnung kann man ignorieren, wenn man sich sicher ist, dass dieses spätere Schalten nicht stört.
Es gibt bei mir dann einen Fehler und der Lauf wird abgebrochen. Wie würde man das ansonsten lösen ?
Vlt hilft folgende Erklärung: Die "global Buffer" BUFG, IBUFG, IBUFGDS dienen dazu, Signale ins Global Clock Network einzuspeisen. Bei den I-Varianten (I=Input) IBUFG etc. sind die Signalequellen Pins, bei BUFG (ohne I) sind die Signalquellen FPGA-intern (z.B. von DCMs). IBUFG bzw. IBUFGDS werden idR. automatisch vom Synthesetool erzeugt, BUFG dagegen muss "von Hand" erzeugt werden (ich hatte Oben "BUFG wird autom. erzeugt" geschrieben, war falsch und muss natürlich IBUFG heissen!). Das ganze ist in den Spartan3-Docs leider nur sehr knapp beschrieben, besser versteht man es, wenn man ein kleines Design aufsetzt und dann mittels FPGA-Editor auf die Suche nach den einzelnen Komponenten geht. Dafür ist ein kleiner Spartaner am Besten geeignet. Auch empfehlenswert ist die Generierung von DCMs per IP-Core. Im generierten Code kann man dann die Struktur und deren Komponenten ablesen.
Den BUFG braucht man, wenn man von einer Takterzeugenden Komponente auf das globale Taktnetzwerk gehen will. Bei PLL und DCM muss der an den Ausgang. Der Core generator macht das auf Wunsch automatisch. Zwei BUFG hintereinander geht nicht, zwei BUFG an einem Ausgang geht auch nicht. Eine Kette auf BUFG und IBUFG geht auch nicht. Wenn du den Takt von außen ohne PLL/DCM direkt als Takt intern verwendest, macht XST automatisch den IBUFG rein. Einen OBUFG gibts nicht, denn es gibt keinen direkten Weg vom Takt-Netzwerk auf den Ausgangs-Pin. Willst du einen Takt an einem FPGA Pin ausgeben, musst du ein ODDR FlipFlop verwenden (Clock forwarding). Machst du das nicht, sondern gehst mit dem Takt direkt auf einen Ausgang, müssen alle anderen FlipFlops ebenfalls vom schnellen Taktnetzwerk "runter" und der Takt wird dann nur noch über das normale Routing Netz geleitet, was zu undefinierbarem Timing führt. Das gibt einen Fehler im MAP, wenn du nicht per UCF festgelegt hast dass du das unbedingt so willst.
Vielen Dank für die Ausführungen. Eines meiner Teilprobleme: Takt für ADC/DAC. Entweder werden ADC/DAC von einem externen Takt direkt angesteuert über entsprechende Treiber (LVECL, LTC6957, Trafo), das sollte am wenigsten Jitter erzeugen, das FPGA müsste dann per Eingangstakt drauf synchronisiert werden - oder das FPGA nimmt den Eingangstakt und erzeugt dann die entsprechenden Takte für ADC/DAC. Bei letzterer Methode hätte ich meine Bedenken mit dem Rauschen durch die interne PLL. Taktquelle ist ein extrem rauscharmer 100MHz Oszillator (Axiom75-ULN). Ich hab es mal auf folgende Art probiert. myclkout1 ist clkout1 von einer PLL. myioclk ist der Ausgangspin. Ist das so gedacht ?
1 | U7: BUFG port map (I => myclkout1, O => myclk1); |
2 | |
3 | ODDR2_inst : ODDR2 |
4 | generic map( |
5 | DDR_ALIGNMENT => "NONE", -- Sets output alignment to "NONE", "C0", "C1" |
6 | INIT => '0', -- Sets initial state of the Q output to '0' or '1' |
7 | SRTYPE => "SYNC") -- Specifies "SYNC" or "ASYNC" set/reset |
8 | port map ( |
9 | Q => myioclk, -- 1-bit output data |
10 | C0 => myclk1, -- 1-bit clock input |
11 | C1 => not myclk1, -- 1-bit clock input |
12 | CE => '1', -- 1-bit clock enable input |
13 | D0 => '1', -- 1-bit data input (associated with C0) |
14 | D1 => '0', -- 1-bit data input (associated with C1) |
15 | R => '0', -- 1-bit reset input |
16 | S => '0' -- 1-bit set input |
17 | );
|
Ja so ist das gedacht. Aber für einen ADC nicht brauchbar, wie du ja selber schreibst. Die erste Variante ist da viel besser. So wirds überall gemacht, wo es auf rauscharme Ergebnisse ankommt.
Christian R. schrieb: > Machst du das nicht, sondern gehst mit dem Takt direkt auf einen > Ausgang, müssen alle anderen FlipFlops ebenfalls vom schnellen > Taktnetzwerk "runter" und der Takt wird dann nur noch über das normale > Routing Netz geleitet, Woher stammt diese Information? Das erscheint mir merkwürdig. Das würde heissen, dass das Taktnetz ausschließlich an Takteingänge von Flipflops angeschlossen werden kann. Nach meiner Erinnerung ist eine Herunterleitung vom Taktnetz auf lokale Leitungen durchaus möglich.
Die Fehlermeldung ist in dem Fall eindeutig, und besagt dass alle anderen FlipFlops dann ebenfalls nicht an das Taktnetz angeschlossen werden können.
Christian R. schrieb: >Einen OBUFG gibts nicht, denn es gibt keinen direkten Weg vom >Takt-Netzwerk auf den Ausgangs-Pin. Willst du einen Takt an einem FPGA >Pin ausgeben, musst du ein ODDR FlipFlop verwenden (Clock forwarding). OBUFG gibt es nicht, ODDR zu verwenden ist absolut vernünftig aber nicht notwendig, es geht auch anders. >Machst du das nicht, sondern gehst mit dem Takt direkt auf einen >Ausgang, müssen alle anderen FlipFlops ebenfalls vom schnellen >Taktnetzwerk "runter" und der Takt wird dann nur noch über das normale >Routing Netz geleitet, was zu undefinierbarem Timing führt. Das gibt >einen Fehler im MAP, wenn du nicht per UCF festgelegt hast dass du das >unbedingt so willst. Was meinst du mit "alle anderen FlipFlops .. runter"? Ein Takteingang (Pin) hat intern einen INBUF, der den eingehenden Takt weiterleitet in eine locale Netzmatrix. Von der kann man dann den Takt weiterleiten zu einem IBUFG als auch zum globalen Logiknetz (nicht globales ClockNetz!), und zwar gleichzeitig. Von da kann dann der Takt in eine Slice (z.B. LUT4) oder in eine IO-Slice (als Output-Pin) weitergeleitet werden. Das alles kann man sich leicht mithilfe des FPGA-Editors klarmachen.
Dann ist das wohl auch architekturabhängig. Ich hatte Designs, da hat er mir angezeigt, dass alle FlipFlops an diesem Netz dann nicht über das Clock Netzwerk angeschlossen werden konnten. Beim Spartan 6 kommt da direkt ein Fehler (PLACE-1205 und PLACE-1136) und selbst wenn man das CLOCK_DEDICATED_ROUTE setzt kommt der in den allermeisten Fällen zu einer "unroutable situation". Aber das liegt wohl an der Beschränktheit des Clock Netzes am S6. Beim Spartan 3 kriegt man das so wie du beschrieben hast hin, allerdings hat der Taktausgang dann nach jedem Durchlauf ein anderes Skew zum internen Takt, bei höheren Frequenzen nicht brauchbar, hab eben mal getestet, da wars laut STA schon 3ns Skew.
heute unangemeldet schrieb: > Christian R. schrieb: >> Machst du das nicht, sondern gehst mit dem Takt direkt auf einen >> Ausgang, müssen alle anderen FlipFlops ebenfalls vom schnellen >> Taktnetzwerk "runter" und der Takt wird dann nur noch über das normale >> Routing Netz geleitet, > Das erscheint mir merkwürdig. > Das würde heissen, dass das Taktnetz ausschließlich an > Takteingänge von Flipflops angeschlossen werden kann. > Nach meiner Erinnerung ist eine Herunterleitung vom > Taktnetz auf lokale Leitungen durchaus möglich. Es gibt ein local clock routing in IO-Bereich beim Virtex-6 und Co, bei anderen wieder nicht. Das ist stark typabhängig. Wenn P&R sagt es geht nicht, dann gehts nicht. Ggf. kann man einen Toggle-FF selbst einen solchen Übergang nachbauen - die Qualität des signals "leidet aber. MfG,
Thread beobachten
Seitenaufteilung abschaltenBitte 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.