Hallo, Ich habe einen Referenz-Takt von ca. 80MHz. Von diesem Takt leite ich dann im FPGA Design mehrere Signale ab (einen haufen Zähler und andere Sachen). Jetzt kann es allerdings passieren, dass der Referenz-Takt auf einmal verschwindet. Ist das FPGA Design gerade dabei einen Satz von Signalen zu erzeugen würde, da der Takt fehlt, alles hängen bleiben, was dann zu Problemen in der Elektronik führt, welche die erzeugten Signale verarbeitet. Ein Teil der Informationen steckt in der Verzögerung welche die erzeugten Signale zueinander haben. Ist es möglich mit der internen PLL im Spartan6 das Referenz-Signal per PLL zu "buffern". Die PLL wird ja hoffentlich ohne Referenz-Input noch eine Zeitlang weiter laufen, bis der Takt zuweit davon driftet und die PLL nicht mehr gelockt ist. Lässt sich abschätzen wie schnell das passiert? Wenn genügen Zeit da ist, kann der Signal-Erzeugungzyklus sicher abgebrochen werden und gewartet werden, bis lock detect wieder sicher anliegt. Habe derzeit nicht die Möglichkeit dies zu Testen. Deshalb die Frage. Wäre vielleicht ein externen PLL Baustein alla ADFxxxx besser dafür geeignet? Danke, Stefan
In Festplatten z.b. gibt es ja PLL Schaltungen mit einer Sample and hold Schaltung sozusagen, die die Referenzspannung hält, sobald sie eingerastet ist, guck mal vielleicht kann diese PLL das auch.
Nee, sobald kein Input mehr da ist, rsstet die PLL im S6 nach 1...2 Takten aus und setzt das Lock bit zurück und außerdem das entsprechende Bit am Status Ausgang für fehlenden Eingangstakt. Dann muss die PLL im S6 auch per RST zurück gesetzt werden.
Man braucht entweder einen externen Takt, der stabil ist, der auf die 80MHz umgesetzt wird um ihn dann auf den Ref-Takt zu synchen, oder man muss sich mit einem freilaufenden Oszillator, den man auf z.B. 80x4 MHz steuert (nicht regelt!) manuell niederfrequent auf die Taktquelle synchen. Den selbstlaufenden OSC muss man über variabel einstellbare LUTs-Ketten einmal auf die benötigte Frequenz bringen und ihn dann langsam im ms-Takt nachregeln, bzw das Nachregeln unterlassen, wenn der REF-Takt ausfällt. Mit einem Spartan 6 bekommt man die 320MHz sicher hin, vielleicht auch 400 MHz. Allerdings ist das stark mit jitter behaftet. Genutzt habe ich das aber bisher nur mit dem S3 und dem V4, mit denen bis zu 900MHz/3 bzw. 1050MHz/3 zu erzielen waren. Der Dritteltakt aus den rückgekoppelten LUTs war dann stabil genug, um einen Buffer zu treiben und als Takt zu arbeiten, z.B. für ChipScope. Beim V4 ging das sogar mit anschließender PLL - allerdings über einen externen Loop auf einen ccIO. Wenn Du es richtig und stabil machen willst, brauchst Du eine externe programmierbare PLL, die einen Synch-Eingang hat. Solche Sachen sind eigentlich nur sinnvoll, um irgendwelche Überwachungsschaltungen im FPGA laufen zu lassen, die selbsttätig Resetten können und den Totalausfall des Mastertaktes vermelden können. Xilinx hat selber solche Spielchen drin, um z.B. JTAG zu bedienen. DAzu gibt es im Userforum einen thread. Man kann sich sogar an den dranhängen, indem man den JTAG Core / BSCAN ausdrücklich instanziiert.
:
Bearbeitet durch User
Hallo, Danke für die Vorschläge. Habe mich heute wieder ein bisschen mit dem Thema beschäftigt und festgestellt, dass die DCMs das können. Die haben einen freeze Eingang den man die DCO in den freerunning mode bringt. Das reicht mir (theoretisch). Muss mir jetzt noch das passende Equipment besorgen um dies zu testen. lg
Stefan S. schrieb: > Danke für die Vorschläge. Habe mich heute wieder ein bisschen mit dem > Thema beschäftigt und festgestellt, dass die DCMs das können. Die haben > einen freeze Eingang den man die DCO in den freerunning mode bringt. Das > reicht mir (theoretisch). Muss mir jetzt noch das passende Equipment > besorgen um dies zu testen. Dann brauchst Du aber dennoch eine Takterkennung, um später wieder auf das Original umschalten zu können. Wie ist das gedacht? Wie wird das Glitchfrei? Jürgen Schuhmacher schrieb: > Xilinx hat selber solche Spielchen drin, um z.B. JTAG zu bedienen. DAzu > gibt es im Userforum einen thread. Man kann sich sogar an den > dranhängen, indem man den JTAG Core / BSCAN ausdrücklich instanziiert. Davon sollte man lieber die Finger lassen. Im Spartan6 mag es gehen, beim Artix fällt man da auf die Nase. In den Thema im xilinx forum steht auch was von der Frequenz: 25MHz --- 75MHz na danke.
Thomas Ulrich schrieb: > Davon sollte man lieber die Finger lassen. Im Spartan6 mag es gehen, > beim Artix fällt man da auf die Nase. In den Thema im xilinx forum steht > auch was von der Frequenz: 25MHz --- 75MHz na danke. Naja, ist halt ein RC Oszillator. Kritisch ist das bei Flash booten, wenn man die CCLK Frequenz zu nah an die Grenze des Flash Chips stellt. Aberzum Beispiel zum Starten des MGT im Artix 7 reichts aus. Da braucht man ja dummerweise einen Hilfstakt.
Thomas Ulrich schrieb: > Dann brauchst Du aber dennoch eine Takterkennung, um später wieder auf > das Original umschalten zu können. Wie ist das gedacht? Wie wird das > Glitchfrei? Nachdem ich alle Signale zum sauberen Abschalten erzeugt habe ist erstmals dieses Clock-Signal egal. Ich kann also getrost das DCM resetten und warten bis LOCK wieder da ist. Muss aber wie gesagt das ganze erstmal in der Praxis probieren.
Stefan S. schrieb: > Nachdem ich alle Signale zum sauberen Abschalten erzeugt habe ist > erstmals dieses Clock-Signal egal. Ich kann also getrost das DCM > resetten und warten bis LOCK wieder da ist. Diesen Moment meinte ich. Wie schaltest Du dann ohne glitch auf den neuen Takte um? Per BUFGMUX(_1) im SYNCH-MODE, nehme ich an? Ich bräuchte nämlich eine Lösung, die DCM so hinzuziehen, dass es ohne wesentlichen Jitter funktioniert. Und zwar unabhängig vom FPGA Type.
Thomas Ulrich schrieb: > Ich bräuchte nämlich eine Lösung, die DCM so hinzuziehen, dass es ohne > wesentlichen Jitter funktioniert. Und zwar unabhängig vom FPGA Type. Wenn es wirklich unabhängig sein soll, würde ich mir eine externe Lösung (a lá PLL) überlegen. Duke
Stefan S. schrieb: > dass die DCMs das können. Die haben > einen freeze Eingang den man die DCO in den freerunning mode bringt. Hast Du einen Tipp wo man den findet? Im CoreGen ist da nichts von zu sehen.
Angehängte Dateien:
-
dcm_clkgen.png
9 KB
Klaus L. schrieb: > Hast Du einen Tipp wo man den findet? Im CoreGen ist da nichts von zu > sehen. CoreGen ist für Weicheier. Schau mal im UG615, dem Libraries Guide. Auch den UG382 (Clocking Resources) sollte man sich genauer anschauen. Duke
Der CoreGen ist in der letzten ISE ohnehin nicht zu empfehlen, wenn es um PLLs geht, weil er Unfug zusammenbaut. Einmal gebaut und geändert fehlen Leitungen wie Res und die Benamungen stimmen nicht mehr. Ich habe die auch per Hand drin.
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.