Ich habe eine Verständnisfrage zum DLL eines DCMs: Warum braucht man ein DLL? Ein DLL hat die Eingänge CLKIN (zu synchronisierender Takt) und CLKFB (vormals ausgegebener Takt der durch das Taktnetzwek des FPGAs geleitet wurde und mit Verzögerung zum DCM zurück kommt). Außerdem den Ausgang CLKOUT (synchronisierter Takt der ans Taktnetzwerk des FPGAs rausgeht). Was das DLL macht ist den Takt der über CLKIN reinkommt soweit verzögert auf CLKOUT auszugeben, dass die CLKOUT-Taktflanken synchron zu denen aus CLKFB sind. Im Endeffekt wird CLKIN also um CLKIN_Periode - Signallaufzeit_durch_Tanknetzwerk verzögert bei CLKOUT ausgegeben (max. eine knappe CLKIN-Taktperiode). Wenn dann beides synchron ist Locked das DLL dann, wenn es den endgültigen Verzögerungswert gefunden hat. Soweit so verständlich. Aber warum braucht man diesen synchronisierten Takt der bei CLKOUT rauskommt? "Man sagt" er wird gebraucht um Clock Skew zu minimieren (also Unterschiede bei den Laufzeiten des Taktsignals zu den FFs). Warum verhindert ein DLL einen Clock Skew? Und wie kann man sich das Clock Distribution Network ungefähr vorstellen? Sind das Leitungen die einmal im Kreis laufen (über die FPGA Chipfläche)? Und warum kann der Delaywert überhaupt konstant festgelegt werden? Wenn man den Takt von CLKIN verzögert auf CLKOUT ausgibt und dann über den Eingang CLKFB das verzögerte Signal von CLKOUT empfängt, dann verzögert sich doch auch der bei CLKFB empfangene Takt. Das Ganze müsste sich endlos immer weiter verschieben... Ich würde mich sehr freuen, wenn mir das jemand plausibel machen könnte.
Eine DLL braucht man um einen definierten Delay zu erzeugen. Als Zeitreferenz benötigt man einen Takt. Manche DLLs können nur ein Delay erzeugen das kleiner ist als die Referenztaktperiode, mache können ein delay erzeugen dass grösser ist. Wozu man das braucht: nun, ist doch egal, man braucht es sonst gäbs die Dinger nicht. Hängt vom Einzelfall ab.
Martin schrieb: > Wozu man das braucht: nun, ist doch egal, > man braucht es sonst gäbs die Dinger nicht. :D Man kann DLL z.B. dazu gebrauchen, um eine exakte Phase wiederherzustellen: Will man Daten mit ihrem Takt annehmen, ist der Takt mitunter nicht so eingestellt, dass er mitten im Auge sitzt. In einem FPGA unterliegt der Takt zudem zusätzlichem Delay durch Routing und einen buffer. Mittels der DLL-Funktion lässt sich der Takt nun automatisch so hinschieben, dass er den eingehenden Taktflanke entspricht und im anderen Fall wiederum davon ausgehend so hinschieben, das er optimal sitzt. Das ist bei HF-Schaltungen oft unumgänglich. Der eingehende Takt wird damit "geglättet" und auf den statisch besten Zeitpunkt gesetzt. Allerdings muss man aufpassen, dass durch den so vorrausschauend erzeugten Takt der Bezug zwischen Daten und Original verloren prinzipiell verloren geht, was bei stark schwankenden Takten, bei denen die Daten eigentlich korrekt mitschwingen, u.U. zu Fehlern führt. Dies gilt z.B. bei Chips, die exzessives frequency speading betreiben.
Jürgen S. schrieb: > > Dies gilt z.B. bei Chips, die exzessives frequency speading betreiben. Gerade mit SSC (spread spectrum clocking) ist die DLL stabiler als der Umweg über eine PLL eine phasenverschobene Clock zu erzeugen. Was bezeichnest du als exzessive?
Lattice User schrieb: > Gerade mit SSC (spread spectrum clocking) ist die DLL stabiler als der > Umweg über eine PLL eine phasenverschobene Clock zu erzeugen. Ich verglich nicht DLL und PLL sondern DLL und nicht-DLL. Exzessiv wäre es, wenn die Frequenz von Takt zu Takt so schnell wechselt, dass die entstehenden Periodenänderungen im Bereich des timing budgets liegen. Den Fall hatte ich schon.
> Warum verhindert ein DLL einen Clock Skew?
So ein Clocknet hat eine von den angeschlossenen Komponenten abhängige
Lastkapazität. Die Struktur ist ein verästelter Baum, sodass die
Leitungswege zu allen Orten gleich lang sind. Aber 1 Flipflop belastet
weniger als tausende. Wenn der darüber laufende Takt immer
phasensynchron zu einem externen sein soll, muss man die Verzögerung
variabel halten. Die muss ja um einen Takt minus der Verzögerungszeit
von Clockbuffern und Clocknet verschieben. Könnte man entweder vorher
ausrechnen und ins Design hart codieren, passt nur bei veränderten
Umgebungsbedingungen (Spannung, Temperatur, anderer Chip) nicht mehr.
Da ist eine automatische Regelschleife wie sie in der DLL drin ist,
praktischer. Die Delays über die Rückkopplung sind bekannt (bzw.
identisch zum Weg Pin->DLL-CLKIN designed), damit wird dann dynamisch
jede Unregelmässigkeit ausgeglichen.
Danke für die Antworten. Mir leuchtet nur nicht ein, warum der verzögert ausgehende CLKOUT nicht dazu führt, dass auch der zurückkommende CLKFB verzögert wird. Dadurch ist CLKFB dann nicht mehr synchron zu CLKIN und CLKIN muss noch weiter verzögert werden, das wiederum zu einer weiteren Verzögerung von CLKOUT führt und so würde es sich immer weiter verzögern. Warum ist diese Vorstellung falsch?
Das "ist nicht mehr synchron" ist keine Einbahnstrasse. Der Phasendetektor erkennt, ob die steigende Flanke von CLKIN vor oder nach der steigenden von CLKFB kommt. Geht halt bis +-180Grad. Damit wird solange an der Phasenverschiebung durch die zig hunderte internen Delaystufen rauf- oder runtergeschraubt, bis die Abweichung +-0 ist.
Georg A. schrieb: > Damit wird > solange an der Phasenverschiebung durch die zig hunderte internen > Delaystufen rauf- oder runtergeschraubt, bis die Abweichung +-0 ist. Naja aber wenn diese +-0 Abweichung gefunden ist, wird die Delaystrecke gelockt und bleibt dann so. Gibt es vielleicht ein Bild davon, wo man sieht wie das Clocknet beim DLL rausgeht und dann durch den FPGA und wieder zurück zum DLL? Ich kann mir einfach nicht vorstellen wie die Verdrahtung genau aussieht.
> Naja aber wenn diese +-0 Abweichung gefunden ist, wird die Delaystrecke > gelockt und bleibt dann so. Nein, das wird kontinuierlich nachgeführt. > Gibt es vielleicht ein Bild davon, wo man sieht wie das Clocknet beim > DLL rausgeht und dann durch den FPGA und wieder zurück zum DLL? Ich kann > mir einfach nicht vorstellen wie die Verdrahtung genau aussieht. Hast du zufälligerweise das Xilinx-Webpack installiert? Da sieht man das im fpga-editor sehr schön. Aber prinzipiell wird das am Einspeisepunkt des Clocktrees abgegriffen und über einen Buffer wieder in die DLL geführt. Der Abgriff ist nicht am Ende des Clocktrees, weil es *das eine* Ende gar nicht gibt. Es reicht, wenn man die Gesamtbelastung feststellt.
Georg A. schrieb: > Hast du zufälligerweise das Xilinx-Webpack installiert? Da sieht man das > im fpga-editor sehr schön. Ja hab ich. Das würde bestimmt helfen. Wie komme ich denn genau zu der Ansicht?
Produzier einfach so ein Simpel-Design, wie es in den Appnotes zur DLL/DCM steht. Also 2*BUFG, 1*DCM und damit nichts wegoptimiert wird, ein FF am Takt, das ein Signal eintaktet und wieder ausgibt. Spartan3E sollte schon reichen... Dann das geroutete Design (.ncd) in den FPGA-Editor laden, reinzoomen und nach der einsamen Leitung suchen ;)
Danke. Das probier ich aus. Abgesehen davon, bezogen auf meinen Anwendungsfall: was ich eigentlich haben will ist ja " nur" ein taktteiler. Und eigentlich reicht es für sowas ja sich ein derived clock Signal bzw clock enable zu bauen ( zählschleife). Hätte ich in dem Fall mit Kanonen auf Spatzen geschossen wenn ich stattdessen einen dcm verwende? In welchen Fällen ist ein dcm einer zählschleife vorzuziehen?
:
Bearbeitet durch User
> Abgesehen davon, bezogen auf meinen Anwendungsfall: Den du leider nicht beschrieben hast ;) Wenn das runtergeteilte Signal wirklich dein allereinziges Taktsignal ist und auch absehbar bleibt und die tatsächliche Phase zu äusseren I/O-Signalen absolut piepegal ist (eher selten...), kannst du natürlich auch mit einem Zähler runterteilen. Zweierpotenzen sind dabei trivial (Abgriff eines FF-Ausgangs), alles andere braucht etwas Vorsicht, damit da keine Glitches rauskommen. So Pfusch/Tricks mit Decodern nach dem Zähler hat man früher gern bei TTL gemacht, das ging da meistens noch gut. Bei FPGAs aber gehts gut daneben... Bleibt es nicht dein einziger Takt oder ist dann doch irgendwas mit Setup/Hold nach aussen hin einzuhalten (bzw. überhaupt im Timinganalyzer rauszubekommen), muss es eigentlich eine DCM werden. Das Runterteilen kann man im Prozess explizit machen, wenn man gleich mehrere Phasen auf einmal braucht und es keine schwer zu erreichenden Timing-Constraints gibt:
1 | process(clk) |
2 | begin
|
3 | if rising_edge(clk) then |
4 | cnt<=cnt+1; |
5 | if cnt(0)='0' then -- halber Takt |
6 | ...
|
7 | end if; |
8 | if cnt(3 downto 0)="0000" then -- 1/16tel |
9 | ...
|
10 | end if; |
11 | cnt1<=cnt1+1; |
12 | if cnt1=41 then -- 1/42tel |
13 | cnt1<=0; |
14 | ...
|
15 | end if; |
16 | end if; |
17 | end process; |
Der Vorteil der Methode ist, dass man absolut synchron bleibt, weil alles nur an dem einen Takt hängt. Man kann auch verschiedene DCMs mit Teilfaktoren (und auch Multiplikatoren!) nehmen und trotzdem über alle Clockdomains synchron bleiben, dann muss man aber schon sehr genau wissen, was man macht und das auch mit diversen Constraints und tw. Extralogik sicherstellen. Bleib lieber erstmal bei einem Takt für alle Prozesse ;)
Vielen Dank für die ausführliche Antwort. Was ich vor hab ist, grob gesagt, ein eingehendes Signal in ein Schieberegister zu schieben und so aufgetretene Pulse (inkl. Dauer) im Signal zu erkennen. Dabei wollte ich die sampling-rate variieren können, um die Breite des Schirberegisters begrenzen zu können. Ich habe also einen Takt zum Abtasten und einen zum Analysieren des SR-Inhalts. Für den DCM hatte ich mich entschieden, weil mir das als sicherste Lösung erschien. Außerdem liest man viel über die enthaltene DLL und deren Fähigkeit clock skew zu verhindern; was ja ein Feature ist, dass man eigentlich immer haben möchte (und ohne DCM nicht hat?). Ergreift ISE bei der Synthese und beim Routing Maßnahmen, die ein Derived Clock Signal von Clock Skew befreien? Ich meine gelesen zu haben, dass die BUFG eine ähnliche Wirkung haben wie die DLL im DCM, stimmt das?
Kann mir jemand sagen, ob ein Buffer, der an den Pins sitzt (z.B. ein BUFG oder ein IBUFG) eine DLL ähnliche Wirkung hat? Ich hab mal gelesen, dass ISE beim Routing "gewisse Maßnahmen" ergreift um zu gewährleisten, dass ein eingehendes Clock-Signal (jetzt mal angenommen ganz ohne DCM) möglichst gleichzeitig bei allen FFs eintrifft. Wie wird dies ohne Benutzung eines DCMs erreicht?
DLL und BUFG ist was ganz anderes. BUFG ist nur ein (starker/schneller) Treiber, der direkten Zugriff auf das dedizierte Taktnetzwerk hat. Ausgleichen kann der aber nichts. Damit kann man zwar alle dran hängenden FFs synchron versorgen, aber es gibt immer noch ein paar ns Differenz, wenn das Signal von aussen reinkommen würde. Das was du meinst, ist vermutlich die Erkennung im xst, ob das Signal ein Takt ist. Wenn das in einem rising/falling_edge steht, ist das ja auch recht wahrscheinlich... Dann wird ein BUFG zwischen Taktquelle und den FFs eingefügt, falls es noch keinen manuell instanziierten im Pfad dazu gibt.
Nochmal vielen Dank für die Antworten. Ich denke die Sache ist nun klar: Clock Skew innerhalb des FPGAs wird von Xilinx dadurch minimiert, dass es die Clock-Treiber (IBUFG etc.) gibt, welche ein starkes Clock-Signal erzeugen und dadurch, dass es ein Clock Net in Baumstruktur gibt. Das starke Clock Signal aus dem Treiber wird dann in das Clock-Net geleitet, wobei der Aufbau dieses Netzes die wichtigste Maßnahme gegen "internen" Clock-Skew ist. (Mit "internem Clock Skew" meine ich den Zeitunterschied zwischen dem ersten und letzten Eintreffen des Clock Signals an einem FF.) Der DLL eines DCMs kann nicht verhindern, dass es diese zeitlichen Unterschiede zwischen dem Eintreffen des Clock Signals an den versch. FFs gibt, aber er kann dafür sorgen, dass die Verzögerung, die durch das Clock Net (ungefähr) entsteht, wegoptimiert wird. Ich hatte fälschlicherweise angenommen, dass der DLL dazu da sei, dass das Clock Signal bei allen FFs gleichzeitig ankommt. Verwirrung entstand dadurch, dass dies mit nur einer Feedback-Leitung nicht möglich sein kann. Es bräuchte eine Feedbackleitung und einen DLL pro FF. Danke georga für den Hinweis sich die Feedbackleitung einfach mal anzusehen;) Das habe ich getan und bemerkt, dass diese nur durch ein Viertel des FPGA verläuft. (Ich benutze den oberen linken DCM meines Spartan 3E 500. Die Feedbackleitung läuft durch das obere linke Viertel des FPGA, meine Anwendungslogik sitzt im oberen rechten Viertel.) Ich nehme an, dass die Feedbackleitung von ISE verlängert werden würde, wenn sich meine Logik auch auf die unteren Bereiche erstrecken würde.
Georg A. schrieb: > DLL und BUFG ist was ganz anderes. Die Verwirrung kommt an dieser Stelle möglicherweise daher, dass man bei den Xilinx-Buffern einen Teiler mit Faktor 2 einstellen kann.
Jürgen Schuhmacher schrieb: > Georg A. schrieb: > dass man bei den Xilinx-Buffern einen Teiler mit Faktor 2 einstellen kann. Das wird dann wohl der Eingangstaktteiler sein, den man bei Erstellung eines DCM aktivieren kann (dort ist nur eine Teilung durch zwei oder gar keine Teilung wählbar).
Nee, das sind spezielle Buffer, die sowas können. BUFIO2 zum Beispiel kann einige Teiler und auch Verdopplung.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.