Xilinx Spartan 6, mehrere DCMs

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.

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.

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.

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.

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.