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?
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...
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.
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...
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)
taktucinf.gif
(58 KB)
