Forum: FPGA, VHDL & Co. Xilinx Spartan 6, mehrere DCMs


von X- R. (x-rocka)


Lesenswert?

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

von Duke Scarring (Gast)


Lesenswert?

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

von X- R. (x-rocka)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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?

von X- R. (x-rocka)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von X- R. (x-rocka)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von X- R. (x-rocka)


Lesenswert?

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.

von X- R. (x-rocka)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von X- R. (x-rocka)


Lesenswert?

Jau, danke.
Den hatte ich schon "gesearched" und überflogen, muss aber wohl nochmal 
genauer ran.

von Christian R. (supachris)


Lesenswert?

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...

von X- R. (x-rocka)


Lesenswert?

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"?

von Christian R. (supachris)


Lesenswert?

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.

von X- R. (x-rocka)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von BiBi (Gast)


Lesenswert?

Lassen die sich eigentlich parallel betreiben, also eine DCM mit 8 
Takten und die andere ebenfalls, welche um einen 1/16 Takt verschoben 
ist?

von Christian R. (supachris)


Lesenswert?

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.

von Selbi (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.