Ich möchte die PLL eines FPGA-Systems ziehen, um einen Softcore und sein Interface auf den Bustakt eines Microcontrollers zu synchroniseren. Aus verschiedenen Gründen ist es nicht möglich, mit der üblichen Vorgehensweise asynchron ein zu takten und zu sampeln, weil die Unsicherheit die Buszyklen verlängern würden. Der FPGA muss den Bus im Rythmus des Controllers belegen und freigeben und das mit etwa 2ns Genauigkeit. D.h. der FPGA muss mit 180 Grad PHasenverschiebung die Strobes sampeln und exakt reagieren, was nur klappt, wenn der Takt nicht wegläuft. Das Problem besteht darin, dass das FPGA-System keinen Mastertakt bekommt, sondern einen runtergeteilten Takt, selber aber einen eigenen Oszillator hat, der auch nicht geändert werden kann, weil schon Module verkauft sind. Die Konstellation ist die: Microcontroller mit 16 MHz Quarz + 200ppm, arbeitet auf 4MHz Bus-Interface mit SDRAM. Die 4 MHz sind absolut phasenstabil gegen die 16, springen also nicht. Einmal "eingerastet" kommen exakt Buszyklen im 250 ns Raster mit 4 Zyklen. Die Zyklen selbs können springen, d.h. es können Pausen ohne Aktivität entstehen. Der Buszyklus kann dann irgendwie wieder einsetzen, aber immer immer 4MHz Raster. FPGA bekommt diesen 4 MHz Bus und soll sich aus den Strobes 4 MHz-Signale erzeugen und daraus einen internen Takt von einem Vielfachen von 4MHz ableiten. Momentan läuft der FPGA intern auf 32MHz, was ja schon gut passen könnte. Der Quarz ist in einigen Baugruppen 40MHz und in anderen 30MHz, d.h. man könnte es mit einer PLL immer günstig hinstellen, z.B. auf 32MHz. Dieses Quarz / die PLL würde Ich jetzt gerne so einstellen, dass die Flanke exakt auf den Busstrobes liegt, damit man mit einer 1/8 Teilung schcön in die Mitte der Takte kommt und es gelingt, das Strobe einzutakten und im nächsten Takt was aus den Registern zu holen und schon im nächsten Takt auf den Bus zu legen, damit es im übernächsten Takt abgeholt werden kann. Danach muss der Bus wieder auf Tristate. Siehe das rote Rechteck. Kann man das mit der PLL direkt machen mit dem feedback? Oder wie bekomme Ich es hin, dass die PLL genau so schwingt, dass das Signal geteilt durch 8, also die 4MHz intern zu denen extern passen?
Angehängte Dateien:
-
taktucinf.gif
58 KB
Markus W. schrieb: > Der Buszyklus kann dann > irgendwie wieder einsetzen, aber immer immer 4MHz Raster. Wenn ich das recht verstehe, willst Du die PLL mit einem Takt versorgen, der vielleicht mal da ist und vielleicht auch mal nicht? Ich kann mir nicht vorstellen, wie das funktionieren soll. Bei Altera z.B. gibt's zwar einen "Reference Clock Switchover", der den Ausfall des Taktes erkennt und auf eine Backup Clock umschaltet, das wird aber immer mit mit einer Neusynchronisation bestraft.
Markus F. schrieb: > Ich kann mir nicht vorstellen, wie das funktionieren soll. Ich auch nicht, aber man sollte da wenigstens wissen, wleches FPGA verbaut ist. Markus W. schrieb: > Das Problem besteht darin, dass das FPGA-System keinen Mastertakt > bekommt, sondern einen runtergeteilten Takt Der ist dann aber phasenstarr zum Controllertakt? > selber aber einen eigenen Oszillator hat, der auch nicht geändert werden > kann, weil schon Module verkauft sind. Das bedeutet nach Murphy aber auch, dass keines der potentiellen "Taktsignale" auf einem Takteingang liegt. Richtig? > Der FPGA muss den Bus im Rythmus des Controllers belegen und freigeben > und das mit etwa 2ns Genauigkeit. Warum brauchst du bei einem überschaubaren 250ns Buszyklus eine so schnelle Reaktionszeit? > Momentan läuft der FPGA intern auf 32MHz, was ja schon gut passen > könnte. Naja, die asynchronen 32MHz sind dann fast die schlechteste Frequenz, weil du schlimmstenfalls immer die größte Verzöderung hast... Warum machst du das Handshake für das Businterface nicht einfach mit einem daraus multiplizierten Takt deutlich schneller? 2ns Reaktionszeit an den Pins erreichst du damit aber auch kaum...
:
Bearbeitet durch Moderator
Welcher FPGA überhaupt? Welcher µC? Nimm den Takt und fütter diesen in eine PLL mit internem Feedback. Dann kannst du den Takt intern multiplizieren. Danach sollte man sich die Delays und Taktzyklen anschauen. Dein Takt muss aber permanent anliegen. Sonst kannst du das vergessen. Ich hatte auch schon mal ein µC-FPGA-Projekt mit Strobes. Ohne richtigen Takt wird das nur eine lahme Ente.
Markus W. schrieb: > der auch nicht geändert werden kann, weil schon Module > verkauft sind. Ohje und du darfst das jetzt ausbaden ... mein Beileid!
Du könntest im FPGA die Phase der PLL an den 4 MHz Takt synchronisieren. Also den Phasenversatz erhöhen / verringern, wenn der Takt vor oder nach dem Takt des FPGAs kommt. Wie du im FPGA dann die 500 MHz für 2ns Reaktionszeit bekommen willst, weiß ich aber nicht...
Du brauchst die 4MHz µC im FPGA, vergiss den 30-40MHz Oszillator am FPGA erst einmal für dein Problem...
Also, es wird ein Artix 7 werden und dessen Oszillator liegt fest. Es gibt keinen dauerhaften Takt mit 4 MHz oder den 16. Ich kann aber die Pulse erzeugen, wenn z.B. ein strobe kommt. Ich kann dann auch einen Zähler resetten, der dann darauf basierend weitere Takte mit 4MHz Abstand erzeugt, so wie man sich bei einer UART auf das fallende Bit synchronisiert. Was Ich brauche, ist im Prinzip die Taktrekonstruktion der 16 MHz anhand der Pulse. In einer Applikation wird beschrieben wie man das mit einer freilaufenden PLL machen kann, die das Signal sampelt und dann einen ungefähren 4MHz-Takt abgibt, der die fehlenden Impulse erzeugt. Den muss man nur noch glätten. Das Problem aber ist, dass der Artix mindestens 10MHz Eingang haben will, um eine Pll zu Steuern. Deshalb geht das so einfach nicht. Ich möchte jetzt auf einen Phasenvergleicher hinaus, der rausbekommt, wie die Phase der internen 4MHz ist, wenn es eine externe gibt. Wenn die interne zu früh ist, müsste die PLL etwas gebremst werden. Ich hatte die Hoffnung, dass Ich irgendwie den feedback-Pfad der PLL nehmen kann, indem Ich einfach ein Viertel der Eingangsfrequenz verwende. Wenn das nicht geht, müsste es eben per Hand gehen, also eine hochgetaktete PLL, die ohne Eingang auskommt und den Sampler macht. Eigentlich sollte es so möglich sein, mit 200MHz einzulesen und einen auf 5ns genauen Zähler auf den 4MHz-extern zu loggen und einen manuellen 16 MHz-Takt zu bekommen.
Ich hänge immer noch an dem Thema: Ich habe jetzt einen Impulsanalysator, der auf Basis eines angeommenen Taktes selber taktet und immer wieder durch den Input resettet wird. Das erzeugt mir einen ununterbrochenen Takt, den Ich als PLL Eingang nehme. Leider logged die PLL sich immer wieder aus, weil sie nicht tolerant genug ist, den entstehenden Jitter zu verarbeiten. Wie könnte man das lösen?
Ziemlich knifflige Sache. Eins steht fest: eine robuste Lösung gibts da nicht! Kleine Spinnerei: - Taktsignal mit ISERDES, 1GBit samplen - Taktlänge tiefpassfiltern für Sub-Gbit-Genauigkeit - Über OSERDES, 1 Gbit, eine Sequenz rausgeben, welche im Mittel (+1ns/-1ns) der Gewünschten Taktrate entspricht - Über nen CC-Pin wieder rein in die PLL - Phaseshift entweder über OSERDES oder MMCM bis es passt. Wär halt eine echt ätzende Frickelei, sollte es überhaupt funktionieren ;). Viel Spaß!
Beitrag "FPGA auf Microcontroller synchronisieren" Knuff schrieb: > Ziemlich knifflige Sache. Eins steht fest: eine robuste Lösung gibts da > nicht! Ich hatte hier mal eine Lösung publiziert, die einem externen Takt per Regelung folgt: http://www.96khz.org/oldpages/frequencyconversion444896.htm Es wird aber eine interne PLL verwendet, die aus einem geglätteten Takt kommt, welcher gefiltert wird. Wenn das mit einer modernen PLL im FPGA richtig präzise funktionieren soll, muss man die Schaltung um einen externen Filter erweitern und den Takt entsprechend runtersetzen, dass der Jitter nichts ausmacht.
Ohne jetzt die Gründe für deine Anforderungen zu kennen würde ich aus dem Bauch heraus sagen, dass dieser Ansatz vermutlich nicht optimal ist und es vermutlich einen anderen Ansatz geben könnte, der einfacher zu beherrschen ist. 250ns Zugriffszeiten klingen jetzt nicht so, als könne man da nicht ganz "klassich" asynchron arbeiten. Woher kommt die Anforderung, dass die Ausgangsdaten innerhalb von 2ns anliegen müssen? Das passt doch irgendwie nicht so recht zu den 250ns Zugriffszeit. Und abgesehen davon: 2ns Delay an den Pins kann echt schon sportlich werden.
Die 2ns sind sind im FPGA kein Problem, hin zu bekommen. Auch ohne Delaytricks treten da über Banken hinweg nicht mehr als +/-200ps auf. Die Anforderung des geringen Jitters kommt meistens aus dem Umstand, dass dieser Takt extern für andere Bauteile weiterverwendet werden soll. Da hilft dann wahrscheinlich nur, ihn mit einer parallelen Schaltung mit eigener PLL zu betreiben und die entsprechend zu regeln und diesem Takt die Daten per aFIFO zu übergeben. Eine Phasenregelung, die so genau ist, dass sie sich wirklich auf genau die richtige Flanke einklinkt, ist schwierig. Die muss schon träge genug sein. Die FPGA-PLLs haben da auch nur begrenzte Möglichkeiten. Wahrscheinlich ist eine externe einfacher. Man kann z.B. einen DDS-Generator-Chip nehmen und die Phase dynamisch umprogrammieren. Die rennen intern mit 2GHz und haben eine Phasenauflösung von z.B. 32 Bit.
Jürgen S. schrieb: > Die 2ns sind sind im FPGA kein Problem, hin zu bekommen. Auch ohne > Delaytricks treten da über Banken hinweg nicht mehr als +/-200ps auf. Ich war Gedanklich beim Delay und nicht mein Jitter (Mein Fehler)
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.