Hallo! Wie auf meiner Skizze zu sehen ist, lese ich DDR-Signale ein und speichere diese in einem FIFO ab. Der DDR-Takt wird über ein clockfähigen Pin (aber kein Global Clock Pin) eingelesen. Damit ich die IDELAYs und IDDRs ansteuern kann, benutze ich den Buffer "BUFIO". Von diesem Buffer aus gehe ich dann auf einen "BUFR" Buffer, der dann zur FPGA Fabrik gehen kann - folglich nutzt er das Regional Clock Netzwerk. Solange mein FIFO eine gewisse Größe nicht überschreitet, kommt keine Fehlermeldung, da alle Block Rams noch in der gleichen oder angrenzenden Clock Region liegen - sobald ich ihn dann aber größer mache gibt es einen Routing Fehler. Ich habe testweise den FIFO mal mit einem bestehenden Global Clock Netzwerk betrieben und da hat alles funktioniert!!! FRAGE: - Wie bekomme ich es hin, dass die Clock Leitung zum FIFO über das global Clock Netzwerk geroutet wird - Ich habe bereits ein BUFG hinter der IBUFDS gesetzt und wollte damit ein DCM ansteuern und als Feedback Input den BUFIO Ausgang nutzen und den Clock Out Ausgang des DCMs für den FIFO Write Clock nutzen - aber kein Erfolg - ist diese Strategie richtig? Wenn ja, was mache ich falsch?
Angehängte Dateien:
-
Taktnetzwerke.GIF
18 KB
Hallo Simon D. Du schreibst nicht welchen FPGA Du benutzt. Beim Virtex4 wird es so gemacht, wie Du beschreibst: INPUTPIN - BUFIO - BUFR, beim Virtex5 hingegen werden BUFIO und BUFR direkt am INPUTPIN connectiert. Zur "Richtigen" Vorgehensweise waere es wichtig zu erfahren, wie schnell dein Input laeuft. Das Problem ist, das Du von einem nicht global Clock faehigen Pin nur langsam zum BUFG kommst. Die Globalclockpins liegen alle in der Naehe der BUFGs und koennen ohne Hops innerhalb der Switchmatrixen an jene geroutet werden. Von IO-Clockpins dauert es a) eine halbe Ewigkeit und b) kann das Delay nicht mehr automatisch von den Tools korregiert werden (und ist ueberdies kaum noch genau zu definieren)... Wie Du schon selbst erkannt hast, koennen Regionalclocks nur eine bestimmte Anzahl an Rambloecken erreichen. Wenn es das Design nun zulaesst, so wuerde ich vorschlagen Du gehst mit dem Regionalclock auf ein kleines RAM. Vom (Clock)Inputpin dann auf einen BUFG und diesen dann an die sekundaere RAM Seite. An diesen kleinen FIFO kannst Du nun einen groesseren Anschliessen und bist von nun an synchron und in Phase mit dem BUFG gepufferten Clock... Gruss
Reversionierer schrieb: > Du schreibst nicht welchen FPGA Du benutzt. ich benutze einen Virtex 4 FPGA (wie du bereits vermutet hattest)... Reversionierer schrieb: > wie schnell dein Input laeuft. mit 250 MHz Reversionierer schrieb: > Du gehst mit > dem Regionalclock auf ein kleines RAM. Vom (Clock)Inputpin dann auf > einen BUFG und diesen dann an die sekundaere RAM Seite. An diesen > kleinen FIFO kannst Du nun einen groesseren Anschliessen und bist von > nun an synchron und in Phase mit dem BUFG gepufferten Clock... den ganzen Sachverhalt verstehe ich nicht so richtig... Ich habe ein globales Taktnetzwerk, das aber nur mit 200 MHz getaktet ist (und die DDR Daten kommen mit 250 MHz)... Ich habe mir gedacht, dass ich mit dem Regional-Clock-Input Pin irgendwie eine PLL betreiben könnte und zur Phasenanpassung das Feedback Signal der PLL mit dem Regional-Takt-Signal verbinden könnte... aber mein Vorhaben funktioniert nicht...
Also PLL gibts im Virtex 4 ja nicht. Nimm einen DCM, dann kannst du die Taktverzögerung auch einstellen. An dessen Ausgang einen BUFG aktivieren und dann landet der Input CLK auf einem globalen CLK-Netz. Der V4 hat ja genügend. Die IDELAY an den Eingängen sind auch OK so, kann man noch etwas Feintuning machen. Auf jeden Fall passende Constraints für die Eingänge setzen. Im PlanAhead gibts ja einen schönen GUI Editor dafür, der macht für die DDR auch gleich die passenden Vorlagen für OFFSET IN.
Angehängte Dateien:
-
Taktnetzwerke.GIF
21 KB
Christian R. schrieb: > Also PLL gibts im Virtex 4 ja nicht. Nimm einen DCM gebe ich dir recht, aber die PLL ist ein Bestandteil des DCM Christian R. schrieb: > An dessen Ausgang einen BUFG aktivieren > und dann landet der Input CLK auf einem globalen CLK-Netz. Der V4 hat ja > genügend. ich hatte das ganze auch so ähnlich vor - siehe Skizze im Anhang. Der DCM sollte mit dem DDR-Clock über einen BUFG und den IBUFDS mit dem DDR-Clocks versorgt werden (Leitung 1 und 2) -> das funktioniert auch schon. Der Ausgang des DCMs landet ja automatisch auf dem Global Clock Network... wie gewollt. Um die verschiedenen Signalverzögerungen zu kompensieren hätte ich gerne das Ausgangssignal (Leitung 4) der IO Logic genommen und dieses dem DCM als Feedback gegeben, so dass er die 250 MHz in Phase generiert... und gerade das funktioniert nicht... Das ist doch ein intelligenter Ansatz?? Warum funktioniert er aber nicht??
Im DCM ist eine DLL, keine PLL. Das ist ein Unterschied. Wieso willst du das so machen? Den Feedback legt man höchstens extern, wenn man damit Laufzeiten auf der Leiterplatte ausgleichen will. Und so geht es sowieso nicht, du kannst dort keinen Abzweig machen. Jedenfalls nicht, wenn es sauber sein soll. Am besten ist es, den DCM direkt an den externen CLK-Eingang anzuklemmen, im Wizzard dann auf external und Differential stellen, dann macht der automatisch das, was er soll. Laufzeiten zwischen den Takt und den Daten gleicht man, wenn nötig mit den IDELAY ab, oder wenn der CLK intern nur an diesen FIFO geht, mit dem Phase Shift des DCM.
Christian R. schrieb: > Im DCM ist eine DLL, keine PLL. Das ist ein Unterschied. Das ist mir bekannt, jedoch kenne ich bis jetzt keine Möglichkeit mit einer DLL die Frequenz zu erhöhen... Wird dann über eine Delay Strecke ein Oszillator aufgebaut? Aber nun zur Hauptfrage: Ich habe mein Design geändert: DDR-Clock -> BUFG -> DCM (internal Feedback) -> FIFO | | IO-Logic habe dann verschiedene Phase Shiftings ausprobiert (alle Zeiten in ns): bei 0 Phaseshifting Setup 0.014 Hold -3,282 bei 10 Phaseshifting Setup 0.024 Hold -3,157 bei 50 Phaseshifting Setup 0.084 Hold -2,693 bei 100 Phaseshifting Setup -0.01 Hold 0,037 bei 95 Phaseshifting Setup 0.000 Hold 0.002 also funktioniert es bei 95 -> aber Setup von 0 und Hold von 2 fs sind nicht sehr toll... Habe dann den FIFO vergrößert und dann kommt schon wieder ein Timing Error, dass Setup und Hold verletzt werden... und da hilft auch kein Drehen am Phaseshifting mehr :-< Da ich in der DCM den Mode "Duty Cycle Correction" nutze gehe ich auch davon aus, dass ein 250 MHz Signal mit ca. 2 ns high und 2 ns low erzeugt wird. Dementsprechend müssten doch das Signal so verschoben werden können, dass diese vollkommen in Phase sind und die Timing Constraints großzügig eingehalten werden wie in der Konfiguration ohne DCM... Gibt es da irgendwelche Möglichkeiten das Ganze zu Verbessern??? Ideal wäre eine Constraint Anweisung mit der man zwei Signale synchronisieren könnte und der Router dann selber Zeitdelays setzen würde... gibt es so etwas???
Das mit der IO-LOGIC im "Bild" oben versteh ich nicht. Welche Constraints hast du denn jetzt gesetzt? Was passiert denn, wenn du nur für den DDR-CLK die PERIOD setzt? 250MHz müsste bei einem V4 ohne viele Klimmzüge drin sein, erst recht, wenn da keine Kombinatorik dazwischen ist... Die Phase der Daten zum CLK kannst du ja dann noch über die IDELAY einstellen...
Angehängte Dateien:
-
Design.png
36 KB
Christian R. schrieb: > Welche > Constraints hast du denn jetzt gesetzt? Ich habe den DDR-Clock mit Period und die DDR-Daten mit Offset und Valid spezifiziert. Mein Design läuft jetzt auch - siehe Skizze... Dennoch habe ich ein paar Fragen: 1) Die Offset In, Valid und Period Spezifikation sorgen mir doch dafür, dass der Router weiß, wie schnell der DDR Clock ist und wann die Daten für wie lange gültig sind... Das heißt doch, dass er dafür sorgt, dass der Weg 1 und 3 entsprechend geroutet wird, oder? Wenn ich den Takt nicht vorher abzweigen würde und wie vorher hinter den BUFIO einen BUFR schalten würde und damit den FIFO takten würde, würde er auch dann alle dahinter liegende Logik kontrollieren?? Ich Frage mich halt, warum ich "nur" die Delays am Eingang setzen muss - kann der Router geringe Delays mitten im Netzwerk selber setzen und so für die Synchronität sorgen?? 2) Bezgl. der Skizze von diesem Beitrag: Der Datenfluss geschieht über den WEg 1 und 3 - das heißt die Offset und Valid Spezifikation wird auch nur bis zu den IDDRs genutzt - ab dann entscheidet der Takt über Leitung 2 ja wie die Daten weitergeschoben werden... stimmt das? Ich zweige den Takt jetzt ja direkt nach dem IBUFDS ab und gehe den Weg 1 und 2 - der Weg 1 wird schneller sein als Weg 2 - das heißt die Daten an den IDDRs können schon ungültig sein, wenn der Takt über Weg 1 kommt --> wird deswegen auch die Hold Violation angezeigt wenn ich die Phase nicht verschiebe?? 3) Zur DLL und PLL... Mir ist der Unterschied wohl bekannt - habe aber nicht gewusst, dass man mit DLLs auch die Frequenz anheben kann? Werden dann die Delay Elemente auf die Hälfte der ankommende Frequenz (Perioden Zeit) gestellt und diese Timer Kette immer mit ankommender positiver RefClockFlanke gestartet? Im DCM müssten aber auch PLLs verfügbar sein für die komplizierteren Frequenzanhebungen... ???
Lass mal den Abzweig weg und versorge die IDDR mit dem CLKOUT des DCM. Sonst betreibst du ja deinen FIFO und die IDDR mit unterschiedlichem Takt, das ist ja nicht sinnvoll. Dann kannst du nämlich auch den Sample-zeitpunkt der Daten in das IDDR mit dem DCM-Delay festlegen und kannst auf die IDELAY verzichten. Ist meist nur sinnvoll, wenn du den DCM nur für diese Eine Sache nimmst. Wenn du damit noch andere Logik-Teile versorgen willst, solltest du das mit dem IDELAY anstatt dem DCM-Delay machen. Weil sonst alle Takte im FPGA gegenüber dem Eingang verschoben sind. Innerhalb des FPGA brauchst du solche Tricks dann nicht, denn per Design ist garantiert, dass Daten dir mit steigender Flanke an einem FF übernommen werden, auch mit der nächsten steigenden Flanke des gleichen Taktes ins nächste FF oder halt BlockRAM übernommen werden können.
Christian R. schrieb: > Lass mal den Abzweig weg und versorge die IDDR mit dem CLKOUT des DCM. wusste gar nicht, dass das möglich ist - aber genau so wollte ich es auch. Mir hat die Idee mit dem DCM von Anfang an gefallen, aber nicht so, dass es zwei "parallel" zu taktende Netzwerke gibt. Wenn ich nun mit dem DCM auch die IDDRs takte und die IODELAYs all auf null setze, meldet ISE ein Timing Error: Setup 5,869 ns und Hold -6,069 ns -> das heißt die Daten stehen 5,869 ns vorher an und sind 6,069 ns zu früh weg ??? Alle Phase Shifting Einstellungen bringen nichts, obwohl die Phase ja um 360 Grad gedreht werden kann müsste doch eine Einstellung dabei sein mit der es funktioniert - ich müsste ISE halt mitteilen, dass er mit einer verzögerten Flanke takten darf ?? Bei -200 -> -3,125 ns resultiert ein Setup von 2,744 und Hold von -2,944 ns Bei -255 -> -3,984 ns resultiert ein Setup von 1,885 und Hold von -2,085 ns Was nun?? Noch ein DCM in Serie??? Habe auch mal versucht die IODELAYs einzusetzen, aber kein Erfolg.
Hm, seltsam. Mal versucht, die OFFSET IN Constraints rauszunehmen? Was passiert dann? Dann geht der Router meines Wissens zunächst mal davon aus, dass du dich extern drum kümmerst, die Daten passend zur Flanke anzulegen und betrachtet die als synchron zur CLK-Flanke. Was ja beim ADC auch so sein sollte.
Christian R. schrieb: > Hm, seltsam. Mal versucht, die OFFSET IN Constraints rauszunehmen? Was > passiert dann? dann bleibt der Timing Error konstant bei -1,215 / 0,514, egal wie ich bei dem DCM oder IO Delay die Parameter verstelle... Ich denke, dass die Offset In Constraints drin bleiben sollten, damit der Router weiß, in welchem Zeitraum diese gültig sind... (wenn sie wegfallen bleibt ja nur der Zeitraum zur aufsteigenden bzw. abfallenden Flanke) Ich werde mal die Frage im Xilinx Support Forum stellen und falls ich das Problem gelöst bekomme, die Lösung hier posten...
Jetzt möchte ich das Rätsel doch lösen: Die beste Methode ist der Einsatz eines asynchronen FIFOs, der auf der Schreibseite mit dem "Regional Clock" und auf der Leseseite mit dem "Global Cock" betrieben wird... Beispiele dazu findet man, wenn man nach "Crossing clock domains" sucht... Damit wäre dieser Thread abgeschlossen!!! Danke an die Beteiligten!!!
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.