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.
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?
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).
