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:
1
CLOCK_HALF_IBUFG_INST:BUFG
2
portmap(I=>Clock_Half_In,
3
O=>Clock_Half);
4
(...)
5
process(Clock_Quarz)
6
begin
7
if(rising_edge(Clock_Quarz))then
8
Clock_Half_In<=notClock_Half_In;
9
(...)
10
process(Clock_Half)
11
begin
12
if(rising_edge(Clock_Half))then
13
(...)
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?
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?
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.
>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?
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...
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?
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.
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.
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.
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...
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:
1
signalcnt:unsigned(23downto0);
2
signalclk2_In,clk2:std_logic:='0';
3
4
begin
5
6
------ 1 ------
7
CLOCK_HALF_INST:BUFG
8
portmap(I=>clk2_In,
9
O=>clk2);
10
clk2_In<=notclk2_Inwhenrising_edge(clk);
11
-----------------
12
13
------ 2 -----
14
clk2<=notclk2whenrising_edge(clk);
15
-----------------
16
17
18
cnt<=cnt+1whenrising_edge(clk2);
19
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... ;-)
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.
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.
