Hallo, ich bin relativ neu auf dem Gebiet der FPGA-Programmierung und habe in einem Design ein Spartan-3-Derivat, nebst einem ATmega128, sitzen... Der Spartan-3 wird mit maximaler Geschwindigkeit (und Oszillator nach Appnote) betrieben - nun frage ich mich, ob es nicht sinnvoll wäre, das Clock-Signal (16MHz) für den AVR mittels des FPGAs zu realisieren - um mir so weitere Bauteile für den ATmega128 zu sparen. Die beiden müssen nicht synchron getaktet sein o.ä., hauptsache der AVR bekommt stabile 16MHz, keine erweiterten Anforderungen... Die Kommunikation zwischen dem FPGA und diesem Controller läuft ohnehin asynchron. Wie gehe ich denn bzgl. des Clock-Signals am besten vor? Einfach einen Modulo-n-Zähler aufbauen und auf einen beliebigen Ausgangspin das FPGAs legen? Oder gibt es elegantere Lösungen? ...das ganze Clockmanagement beim Spartan habe ich noch nicht wirklich durchschaut. Ich danke für jeden Hinweis Sascha
> Der Spartan-3 wird mit maximaler Geschwindigkeit > (und Oszillator nach Appnote) betrieben Die maximale Geschwindigkeit eines FPGA-Designs hängt erst in zweiter Linie vom Baustein ab. In erster Linie begrenzt dein Design die Taktfrequenz. > Wie gehe ich denn bzgl. des Clock-Signals am besten vor? Einfach einen > Modulo-n-Zähler aufbauen und auf einen beliebigen Ausgangspin das FPGAs > legen? Ich würde das so machen. Und auf jeden Fall den Ausgangstakt registrieren (also als letztes Glied ein FF setzen), damit der garantiert glitchfrei ist. > ...das ganze Clockmanagement > beim Spartan habe ich noch nicht wirklich durchschaut. Das ist eigentlich nur für Singale/Takte innerhalb des FPGAs interessant. Natürlich kann man mit DCMs und externen Loops auch Laufzeiten auf der LP korrigieren, aber das ist in deinem Fall unnötig.
Wäre zu beachten, dass der Takt erst da ist, wenn der FPGA geladen ist. Manchmal kann das stören, dass der Prozessor erst dannn anläuft.
Danke für Eure Hilfe! Den Oszillator des AVRs zur Takterzeugung zu nutzen ist natürlich die beste Idee - so benötige ich gar keinen zusätzlichen Quarzoszillator als Taktgeber, sondern nur einen schnöden Quarz und eben den im AVR integrierten Oszillator. Der Spartan-3 hat ja PLL und wasweißich-noch-alles (nützliches für genau diesen Zweck) integriert, ich muss mir das direkt einmal im Detail ansehen; jedenfalls scheint dieser Ansatz optimal, danke! Beste Grüße Sascha
arno nyhm schrieb: > Danke für Eure Hilfe! > Der Spartan-3 hat ja PLL und wasweißich-noch-alles (nützliches für genau > diesen Zweck) integriert, ich muss mir das direkt einmal im Detail > ansehen; jedenfalls scheint dieser Ansatz optimal, danke! Nein, der Spartan 3 hat keine PLL, nur DCMs mit DLL für die Delays. Du kannst aber andere Frequenzen aus deinem AVR-Takt erzeugen, das geht.
> Nein, der Spartan 3 hat keine PLL, nur DCMs mit DLL für die Delays.
Na, dann lies dir mal die Beschreibung der DCM mal etwas genauer durch.
Ich habe die dort vorhandenen PLL-Dinger bisher gut gebrauchen können.
Gute Besserung!
Bernd G. schrieb: >> Nein, der Spartan 3 hat keine PLL, nur DCMs mit DLL für die Delays. > > Na, dann lies dir mal die Beschreibung der DCM mal etwas genauer durch. > Ich habe die dort vorhandenen PLL-Dinger bisher gut gebrauchen können. > Gute Besserung! Eine PLL ist aber was anderes als der DFS im DCM. PLL gibts beim Spartan 6 und Virtex 5 dann. Die Funktionsweise ist allerdings ähnlich. Den DCM mit dem DFS und der DLL nutze ich ebenfalls täglich.
Hmm...mag der Atmega es, wenn sein Reset schon freigegeben ist und noch kein Takt anliegt? Eventuell sollte der FPGA dann auch die Gewalt über den Reset bekommen....
PLL - eine Definitionsfrage. Ich sehe das im Spartan 3 verbaute Teil nach landläufigem Verständnis als PLL an. Der Mitlaufbereich mag nicht unendlich groß sein. Technisch gesehen ist die DFS aber eine PLL-Schaltung. Was sonst?
Den Clock des AVR zapft man mit einem 74SZ04 ab dem Pin XTAL2 an. Dazu muss man den Oszillator des AVR auf grossen Amplitude stellen.
> Technisch gesehen ist die DFS aber eine PLL-Schaltung. Was sonst?
Na, eine Digital Locked Loop eben :-o
Dazu die XAPP174:1 | As shown in Figure 2, the fundamental difference between the PLL and DLL |
2 | is that instead of a delay line, the PLL uses a voltage controlled |
3 | oscillator, which generates a clock signal that approximates |
4 | the input clock CLKIN. |
Zu bachten wäre noch, das du mit den 16 Mhz keinen DCM benutzen kannst, die fangen erst bei 18 Mhz an zu arbeiten. Also kannst du deinen Takt nicht erhöhen, und bei nur 16 Mhz langweilt sich der Spartaner mit sicherheit.
@ Lothar Miller: Bisher war es mir eigentlich Wumpe, ob die PLL als Oszillator einen VCO oder einen Laufzeitgenerator hat, aber danke - jetzt weiß ich es :-). @ Michael Sauron: UG 331, Tabelle 3.8 - ganz so ist es nicht. Wenn die DFS allein benutzt wird, darf CLKIN_FREQ_FX_MIN beim S3 auf 1 MHz runtergehen, beim S3A und S3E sogar bis auf 200 kHz! Die von dir genannten 18 MHZ (Tabelle 3.10) gelten für den DLL-Betrieb des S3. Bei den Derivaten S3A und S3E lese ich aus Tabelle 3.9 den Wert von 5 MHz heraus. So, jetzt habe ich dem Oberlehrer in mir aber mal freien Lauf gelassen.
Ich war bisher immer der Meinung das zu einer Frequenzverdopplung der
PLL zwingend notwendig ist. Lässt sich wirklich nur mit dem DFS ein 10
Mhz Signal auf ein 20 Mhz Signal verdoppeln ?
> Bei den Derivaten S3A und S3E...
Ich bezog mich auf den "original" S3
> Lässt sich wirklich nur mit dem DFS ein 10
Mhz Signal auf ein 20 Mhz Signal verdoppeln ?
Ja. Warum benutzt du das Ding nicht, sind doch üblicherweise vier Stück
und mehr davon drin (beim 3S50... weiß ich es derzeit nicht genau, ob es
da bloß zwei gibt).
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.