FPGA Takt-Teilung

[Nasenmann (Gast)]

Guten Morgen,

Ich diskutiere gerade mit einem Kollegen die Erzeugung eines halbierten 
Taktes. Wir haben einen Takt vom externen Quarz (Clock_Quarz) und wir 
wollen daraus einen synchronen Takt mit halber Frequenz (Clock_Half) 
erzeugen. Zwischen beiden Takt-Domains sollen Daten ohne 
Synchronisierungsaufwand ausgetauscht werden können.
Wir haben verschiedene Möglichkeiten besprochen und sind an einen Punkt 
gekommen, wo wir eine Meiungsverschiedheit haben.
Und zwar geht es um folgendes Konzept:

CLOCK_HALF_IBUFG_INST : BUFG
  port map (I => Clock_Half_In,
            O => Clock_Half);
(...)
process (Clock_Quarz) 
begin
  if (rising_edge(Clock_Quarz)) then
    Clock_Half_In <= not Clock_Half_In;
(...)
process (Clock_Half) 
begin
  if (rising_edge(Clock_Half)) then
(...)

Meine Meinung: Geht nicht, weil zwischen Clock_Quarz und Clock_Half eine 
Phasenverschiebung auftreten wird (verursacht durch die 
FlipFlop-Laufzeit von Quarz_Half_In) und der Datenaustausch ohne 
Synchronisierungsaufwand nicht gesichert ist.
Seine Meinung: Geht.

PS: Uns ist klar, daß es bessere Alternativen gibt und wir werden dieses 
Konzept auch nicht verwenden. Es geht hier nur ums Verständnis.

Wer hat Recht?

[DuArte (Gast)]

http://www.mikrocontroller.net/articles/Taktung_FPGA/CPLD

[Joe (Gast)]

Ich glaube zu wissen, dass die statische Timinganalyse nur abgeleitete 
Takte berücksichtigen kann, wenn man die Ableitung über eine PLL 
bewerkstelligt.

Was spricht gegen eine PLL?

[Franke (Gast)]

Da die Takte statisch zu einander sind (werden ja vom gleichen 
abgeleitet) und die Gatterlaufzeit dich aus der Setup- und Hold-Time 
rausbringt, würde ich sagen geht.


Synronisieren musst du doch eigentlich immer nur zwei "freilaufende" 
Takte.


Cheers.

[Joe (Gast)]

>a die Takte statisch zu einander sind (werden ja vom gleichen
>abgeleitet) und die Gatterlaufzeit dich aus der Setup- und Hold-Time
>rausbringt, würde ich sagen geht.

Aber wie garantierst du, dass der abgeleitete "Logik"-Takt ein
Takt-Routing und nicht Logik-Routing erfahren wird?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Nasenmann schrieb:
> Meine Meinung: Geht nicht, weil zwischen Clock_Quarz und Clock_Half eine
> Phasenverschiebung auftreten wird (verursacht durch die
> FlipFlop-Laufzeit von Quarz_Half_In) und der Datenaustausch ohne
> Synchronisierungsaufwand nicht gesichert ist.
> Seine Meinung: Geht.
Meine Meinung (und die der Tools, wenn man sich die Warnungen ansieht): 
Geht. Meistens. Ist aber Murks, wenn dieser abgeleitete Takt weit 
verstreut im FPGA verwendet wird, weil der "Takt" keinen Weg in ein 
Taktnetz findet und höchstwahrscheinlich über "normale" 
Routingressourcen verteilt wird. Ein unkalkulierbarer Skew ist die 
Folge.
Für lokale Anwendungen (z.B. 40 Flipflops eines SPI-Schieberegisters) 
könnte man bei großer Not sowas schon mal ins Auge fassen. Aber wehe, 
man gewöhnt sich so einen Designstil an...

[Bronco (Gast)]

Lothar Miller schrieb:
> weil der "Takt" keinen Weg in ein
> Taktnetz findet und höchstwahrscheinlich über "normale"
> Routingressourcen verteilt wird.

Wieso das?
Er hat doch extra einen "BUFG" dazwischen geschaltet, damit müßte der 
Takt doch ins Taktnetz gehen, oder nicht?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Bronco schrieb:
> Er hat doch extra einen "BUFG" dazwischen geschaltet
Uuups... tatsächlich. Das geht allerdings nicht bei jedem FPGA. Wenn 
dann ein Taktnetz verwendet wird, bleibt nur noch der erhöhte Jitter 
durch den Umweg über ein normales Flipflop.

[Franke (Gast)]

>Das geht allerdings nicht bei jedem FPGA

Kurze Frage, interessiert mich,
bei welchen geht das nicht ?

Danke

Gruß

[Christian R. (supachris)]

Was genau spricht denn gegen einen DCM? Keine mehr verfügbar? Da hast du 
eine starre Phasenkopplung und weniger Jitter als bei der Frickelmethode 
oben.

[Edi M. (Gast)]

Ich verstehe das Problem nicht. Entweder, man arbeitet komplett über 
denselben Takt mit enables und nimmt den zusätzlichen Strombedarf hin, 
oder man arbeitet mit zwei voll synchronen Takten aus einer PLL.
Diese sind zwar nicht 100% so entspannt wie ein einzelner Takt, aber die 
Synthesetools können das am Einfachsten berücksichtigen. Die Synthese 
nimmt für beide den Jitter an und rechnet damit sehr pessimistisch. Das 
ist der einzige echte Nachteil.

Der reale Jitter ist zwischen den Takten nahezu Null, WENN sie vom 
selben Oszillator kommen, was hier da sicher der Fall sein wird/kann. 
Wenn es jittert, jittern aber beide dynamisch in sehr ähnlicher Weise. 
Übrig bleibt nur das Routing-Delay an unterschiedlichen Stellen des 
Designs und die Tatsache das 2 Takte nicht so blastet sind, wie einer, 
was zu anderen Ergebnissen führt.

Alle Zwischenlösungen, die ich bisher gesehen und getestet habe sind 
schlechter.

[Nasenmann (Gast)]

Zuerst vielen Dank für die Beiträge.

Joe schrieb:
> Was spricht gegen eine PLL?
Christian R. schrieb:
> Was genau spricht denn gegen einen DCM?
E. M. schrieb:
> Ich verstehe das Problem nicht.

Nicht falsch verstehen: Wir werden ein DCM benutzen.
Bei der Frage geht es nur um das Verständnis bzw. die Klärung der 
unterschiedlichen Meinung zwischen meinem Kollegen und mir.
Wir tun manchmal Dinge, von denen wir denken, sie verstanden zu haben, 
und nachher stellt sich raus, daß es doch nicht so war...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Franke schrieb:
> bei welchen geht das nicht ?
Ich meine behaupten zu können, dass es bei den alten Xilinx-FPGAs nicht 
ging (kann aber auch sein, dass ich mir nur an der Ecke die Finger 
verbrannt habe und deshalb weit davon weg bleibe...), ab S3 geht das 
offenbar problemlos. Und ich hatte das sogar schon mal probiert, da wird 
ab einer bestimmten Anzahl getakteter Flipflops sogar ein Taktnetz 
verwendet, obwohl nicht explizit ein BUFG angegeben wird:

   signal cnt : unsigned(23 downto 0);
   signal clk2_In, clk2: std_logic := '0';
   
begin

------  1  ------
  CLOCK_HALF_INST : BUFG
  port map (I => clk2_In,
            O => clk2);
  clk2_In <= not clk2_In when rising_edge(clk);
-----------------

------  2  -----
  clk2 <= not clk2 when rising_edge(clk);
-----------------


  cnt <= cnt+1 when rising_edge(clk2);
  Output <= std_logic_vector(cnt);

Beide Male kommt das selbe raus. Nur wenn wenige FFs zu takten sind, 
dann wird im zweiten Fall direkt ohne Taktnetz und doppelten Boden 
gearbeitet... ;-)

[Edi M. (Gast)]

(Wo) ist denn das zweckmässig solche eine Beschreibung einzusetzen. Was 
machen den Quartus und die anderen Tools daraus?

[Klakx (Gast)]

im ASIC-Entwurf sind solche Taktteiler gar nicht so unüblich. Synopsys 
bietet dafür auch constraints an. Dann werden beide Clock-Netzwerke auch 
synchron ausgerichtet. Für Xilinx FPGAs bin ich mir nicht sicher, ob 
diese generated-constraints unterstützt werden.

Richtig aufpassen muss man jedoch in der Simulation. Beide Clocks 
sollten auf das selbe Delta-Delay geschoben werden. Unconstrained sollte 
man diesen Teiler jedoch vergessen.

Wie gesagt, für den reinen FPGA-Entwurf PLL/DCM, Spezialkomponenten oder 
Clock-Enable. Dafür sind diese Tools ausgelegt.

[Edi M. (Gast)]

Also eher was für die Schiene "experimental". Ich frage mich ohnehin, ob 
es in soliden Designs zweckmässig ist, sonderbare Tricks wie diesen 
einzusetzen. Muss ja alles lesbar und prüfbar sein.