Moin, in einem Spartan 6 gibt es netterweise mehrere DCMs (Digital Clock Manager), die jeweils 6 (!) Ausgangstakte erzeugen können, einstellbar zB in Frequenz und Phase im Verhältnis zum Eingangssignal. Ich benötige zur Erzeugung von 8 Clocks (aus einer) nun 2 dieser DCMs, habe aber das Problem, dass in jeder von mir getesten Konfiguration 2 globale Clock Buffer hintereinander entstehen. Diese werden scheinbar bei der Synthese erzeugt, das Translate liefert dann den Fehler "Clock Buffer in Serie darf nicht". Meine gescheiterten Versuche, das zum umgehen waren bisher folgende: 1) Eingangsclock an 2 DCMs, Fehler: scheinbar gibt's am DCM Eingang einen Buffer, und den GCK-Buffer am Clock IO. Lösungsversuch: in den Synthese-Optionen das "auto IO buffer" ausschalten. Problem: alle IO-Buffer weg Ach ja, und man braucht einen Buffer, um 2 DCMs zu treiben. Okay, das könnte man evtl umgehen und alle anderen IO Buffer per Hand im ucf setzen. Aber geht das dann wirklich? 2) DCM1 so eingestellt, das ein Takt-Ausgang ohne BUFG erzeugt wird. Dieser soll dann DCM2 Eingangstakt sein. Geht auch nicht, meckert wieder, dass 2 BUFs hintereinander sind. Das verstehe ich leider auch nicht. Irgendwelche Ideen? Danke, X
X- Rocka schrieb: > Ich benötige zur Erzeugung von 8 Clocks Bist Du Dir sicher so viele zu brauchen? Was willst Du denn damit machen? Welche Anforderung stehen denn an die Takte? Evtl. kannst Du Dir Clock Enables erzeugen und damit arbeiten. Ich bin bisher immer mit max. fünf Takten ausgekommen (1xSDRAM, 3xVGA/SVGA gemuxt, Systemtakt). Duke
Duke Scarring schrieb: > Bist Du Dir sicher so viele zu brauchen? Ähem, nein! Ich habe dann auch festgestellt, dass ich mit 1 DCM und 5 Clocks auskomme. :-) Hast du trotzdem eine Idee, wie dieses DCM / Multi-Buffer Problem zu lösen wäre? Es sind relativ hohe Takte, die in fester Phase zueinander sein müssen, deswegen DCMs.
X- Rocka schrieb: > Hast du trotzdem eine Idee, wie dieses DCM / Multi-Buffer Problem zu > lösen wäre? Welche Verhältnisse hast du zwischen den Takten?
Lothar Miller schrieb: > Welche Verhältnisse hast du zwischen den Takten? Ich bräuchte Augänge zB alle 200MHz, und dann je +22.5° (1/16 von 360° ist wohl Minimalauflösung) zur nächsten. (0, 22.5°, 45°, 67.5°... 157.5°) Keiner dieser Takte wird je nach außen geführt, alles nur zur internen Verwendung.
X- Rocka schrieb: > Ich bräuchte Augänge zB alle 200MHz, und dann je +22.5° (1/16 von 360° > ist wohl Minimalauflösung) zur nächsten. Immer gleichzeitig? Was willst Du denn damit machen? Vielleicht hilft es Dir ja auch, wenn Du einen Takt erzeugst und bei diesem daan von Deinem Design aus die Phase hin- und herschiebst... Duke
Duke Scarring schrieb: > Immer gleichzeitig? Was willst Du denn damit machen? Frequenzen messen. > Vielleicht hilft es Dir ja auch, wenn Du einen Takt erzeugst und bei > diesem daan von Deinem Design aus die Phase hin- und herschiebst... Da bin ich mir sicher, dass das der DCM deutlich besser und genauer kann. Bei 200MHz sind 200ps Gatterlaufzeit ja schon ~15°. Ja, es ist ein etwas grenzwertiges Design, da werden die schnellen Pfade mit den entscheidenden FFs auch von Hand platziert. Aber das scheint mir sicherer, als eine auf Gatterlaufzeiten (und somit noch mehr Temperatur- und Spannungs-abhängig) basierende hohe Auflösung. Vielleicht werde ich aber mal aus Neugierde eine Tapped Delay Line mit den hübschen CARRY4s testen.
X- Rocka schrieb: > Da bin ich mir sicher, dass das der DCM deutlich besser und genauer > kann. Bei 200MHz sind 200ps Gatterlaufzeit ja schon ~15°. Du kannst auch mit dem DCM die Phase schieben: Schau Dir mal die Pins PSEN, PSINC und PSDONE an. DUke
Ich brauche das aber dauerhaft und konstant, nicht variabel. Wenn ich mein Eingangssignal mit meiner 0°-Clock synce, muss ich parallel mit den anderen Clocks das auch tun.
Wie gesagt, wahrscheinlich reicht mir die 45° Auflösung, 22.5° wird mit den Laufzeiten dann eh kritisch. Trotzdem wurmt es mich, dass ich nicht die DCM parallel oder seriell zum laufen bekommen habe.
X- Rocka schrieb: > Trotzdem wurmt es mich, dass ich nicht die DCM parallel oder seriell zum > laufen bekommen habe. Da schau Dir nochmal genau den Abschnitt zur DCM im Datenblatt an. Da stehen dann auch die Einschränkungen bzgl. der globalen Buffer dazu. Ich hab gerade auch das hier noch gefunden: Spartan-6 FPGA Clocking Resources UG382 http://www.xilinx.com/support/documentation/user_guides/ug382.pdf Duke
Jau, danke. Den hatte ich schon "gesearched" und überflogen, muss aber wohl nochmal genauer ran.
Ich hab auch gemerkt, dass der S6 da einige blöde Einschränkungen hat. Ich verwende in meinem Design auch 45° Takte, die sind auch nötig, und müssen gleichzeitig anliegen und für einen Teil des Designs umschaltbar sein (geht auch nach außen dann an einen ADC). Beim S3E geht das problemlos und mit erstaunlich wenig Jitter. Für die nächste Revision wollte ich den S6 einsetzen, da geht sowas erst mal gar nicht. Der hat da viel weniger globale Clocking-Ressourcen, sowas blödes aber auch...
Christian R. schrieb: ... > problemlos und mit erstaunlich wenig Jitter. Für die nächste Revision > wollte ich den S6 einsetzen, da geht sowas erst mal gar nicht. Der hat > da viel weniger globale Clocking-Ressourcen, sowas blödes aber auch... Ich hatte nur den alten S3-original verwendet, da bin ich mit dem S6 und den 2+ DCMs ganz zufrieden. Was meinst du mit "da geht sowas erst mal gar nicht"?
X- Rocka schrieb: > Was meinst du mit "da geht sowas erst mal gar nicht"? Ich hab für den Takt nach außen einen BUFGMUX und dann das ODDR Element, damit ich nicht 3 BUFGMUX für die 4 Takte brauche. Allerdings will das nicht in den S6, weil dann (wie im S3 auch) 2 BUFGMUX hintereinander sind (der am DCM Ausgang zählt auch). Und da das ganze 2 mal im FPGA ist, gehen dem die Ressourcen aus. Hab dann aber auch noch keine Zeit gehabt, da weiter zu probieren, wie man das am besten umschifft. Im S3E klappt das wunderbar. Der einzige Vorteil für ein Redesign mit dem S6 wäre für uns das Golden Image beim SPI Multiboot.
Christian R. schrieb: > Ich hab für den Takt nach außen einen BUFGMUX und dann das ODDR Element, > damit ich nicht 3 BUFGMUX für die 4 Takte brauche. Allerdings will das > nicht in den S6, weil dann (wie im S3 auch) 2 BUFGMUX hintereinander > sind (der am DCM Ausgang zählt auch). Und da das ganze 2 mal im FPGA > ist, gehen dem die Ressourcen aus. Hab dann aber auch noch keine Zeit > gehabt, da weiter zu probieren, wie man das am besten umschifft. Ich treffe nächste Woche einen Xilinx FAE, vielleicht kennt der den Kniff. > Der einzige Vorteil für ein Redesign mit dem S6 > wäre für uns das Golden Image beim SPI Multiboot. Das ist schon mal eine gute Sache und auch bei uns angedacht, aber soweit sind wir auch noch nicht.
Das ist das Code-Stück:
1 | Mux_0 : BUFGMUX |
2 | port map ( |
3 | O => CLK, -- Clock MUX output |
4 | I0 => CLK0, -- Clock0 input |
5 | I1 => CLK90, -- Clock1 input |
6 | S => CLK_SEL_0 -- Clock select input |
7 | );
|
8 | |
9 | Mux_1 : BUFGMUX |
10 | port map ( |
11 | O => CLK_n, -- Clock MUX output |
12 | I0 => CLK180, -- Clock0 input |
13 | I1 => CLK270, -- Clock1 input |
14 | S => CLK_SEL_0 -- Clock select input |
15 | );
|
16 | |
17 | Sel_1_n <= not CLK_Sel_1; |
18 | |
19 | OutDDR : ODDR2 Port map(Q => CLK_Out, C0 => CLK, C1 => CLK_n, CE => '1', D0 => Sel_1_n, D1 => CLK_SEL_1, R => '0', S => '0'); |
Mit den 2 Bits CLK_SEL_0 und CLK_SEL_1 kann man den CLK-Ausgang 0°, 90°, 180°, 270° umschalten. Wie gesagt auf dem S3E1200 klappt das prima. Hab mich oben übrigens verschrieben, sind 90° Taktabstände, nicht 45°. 45 wäre natürlich noch besser, aber dann bestand schon beim S3 das Problem mit den vielen DCMs bzw. BUFGMUX.
Lassen die sich eigentlich parallel betreiben, also eine DCM mit 8 Takten und die andere ebenfalls, welche um einen 1/16 Takt verschoben ist?
Theoretisch ja, aber mit Einschränkungen. Die FPGAs haben intern nur eine begrenzte Anzahl Takt-Netzwerke. Es kann also sein, dass nicht alle Ausgänge mit einem BUFG auf die globalen Netze gehen können. Das kann man aber je nach Anwendung eventuell durch BUFR ersetzen und nur regionale Logik versorgen.
Ist das nun eigentlich gelöst? Ich meinte mich zu erinnern, dass die 14er Xilinx Version die Bufg ausdrücklich zuschaltbar machen und damit die Doppelinstanziierung vermieden wird.
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.