Forum: FPGA, VHDL & Co. FPGA auf Microcontroller synchronisieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Markus W. (elektrowagi78) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Klakx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> der auch nicht geändert werden kann, weil schon Module
> verkauft sind.

Ohje und du darfst das jetzt ausbaden ... mein Beileid!

von RB (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von uwe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du brauchst die 4MHz µC im FPGA, vergiss den 30-40MHz Oszillator am FPGA 
erst einmal für dein Problem...

von Markus W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Knuff (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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ß!

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Schlumpf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Schlumpf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.