clock genauigkeit von fpgas

Detlef schrieb:
> Hallo Leute,
>
> ich habe mir vor einiger Zeit ein Mojo V3 Board zugelegt, welches ein
> Spartan 6 Fpga drauf hat. Bisher bin ich sehr zufrieden mit dem FPGA
> Board und komme auch ganz gut zu recht. Nur frage ich mich seit geraumer
> Zeit, wie der Spartan 6 das Clocksignal erzeugt ganz ohne Quarz und wo
> ich die Genauigkeit des Clocksignals ablesen kann, gemessen in PPM.

Da ist ein 50 MHz 50 ppm Oszillator auf dem Board, damit wird das 
gemacht.

Woran erkenne ich das? Bzw. wo kann ich das nachlesen?

Detlef schrieb:
> Woran erkenne ich das? Bzw. wo kann ich das nachlesen?

Schaltplan, Datenblatt Oszillator

https://cdn.sparkfun.com/datasheets/Dev/FPGA/mojov3-sch.pdf
https://www.mouser.de/ds/2/3/ASFLMB-24525.pdf

C. A. Rotwang schrieb:
> Schaltplan, Datenblatt Oszillator

Ok vielen Dank! Warst mir eine riesen Hilfe :)

Detlef schrieb:
> Nur frage ich mich seit geraumer
> Zeit, wie der Spartan 6 das Clocksignal erzeugt ganz ohne Quarz

Ich denke, es geht um den Fall "ohne" Quarz? Dann laufen die PLLs frei 
und so ungefähr. Genauigkeit liegt bei etwa 0,1% gefühlt.

Weltbester FPGA-Pongo schrieb im Beitrag #5346670:
> Detlef schrieb:
>> Nur frage ich mich seit geraumer
>> Zeit, wie der Spartan 6 das Clocksignal erzeugt ganz ohne Quarz
>
> Ich denke, es geht um den Fall "ohne" Quarz? Dann laufen die PLLs frei
> und so ungefähr. Genauigkeit liegt bei etwa 0,1% gefühlt.

Ich denke, es gibt diesen Fall "ohne" Quarz bei FPGA' nicht. Das 
erwähnte board hat einen Oszillator drauf, der geht auch an einen 
speziellen Takt-Eingangspin, hier P56.

Man könnte die Frage stellen, was die Maximal tolerierbare 
Taktabweichung ist, wenn man einen nicht quartzstabilisierten 
Taktgenerator verwendet.

Das ist aber IMHO nicht nach Datenblatt entscheidbar, sondern abhängig 
von den constraints und der Synthese. Das passende Stichwort für ne 
Suche in den Xilinx-Docs wäre dann "clock uncertainty" und die wird dann 
eher in einer Zeit bspw picoseconds angegeben und nicht als relative 
Größe wie parts per million.
--
Falls man ohne externe generator auskommen will (wovon ich absolut 
abrate), müsste man sich etwas in der Art rückgekoppelten Inverter bauen 
und dann alle Laufzeitvariationen im Generator aus den Propagation 
delays ermitteln, bspw durch eine post-P&R-Simulation und dann auch noch 
die Toleranz durch Tempeartur-einfluße und Corespannungsschwankungen 
raussuchen. Ich schätze beim spartan6 kommt da was im Bereich von 1..2 
nanosecond raus.

Den internen Generator (der rückgekoppelte Inverter) muss man jetzt aber 
so "basteln" das er nie schneller toggelt als der Rest des FPGA-design 
schalten kann. Das ist aber m.E. bei der aktuellen FPGA-Entwurfsmethode 
unmöglich, man kann nur eine "Minimalgeschwindigkeit" (maximale 
Laufzeit) vorgebenaber keine "Höchstgeschwindigkeit) (minimale 
Laufzeit).

Womöglich gibt es zwischen dem TE und mir unterschiedliche Ansichten was 
man mit den "clocking resourcen" im FPGA erreichen kann. Nach meinem 
Verständnis beziehen sich alle Angaben bzgl Taktgenauigkeit und 
maximaler Takt bei den DLL (Spartan6 hat nach meiner EWrinnerung keine 
PLL sondern eine DLL) auf die Nutzung zur Aufbereitung eines FPGA-extern 
erzeugten Taktes, bspw (Frequenzsynthese nach definierten Teilerfaktor 
aus einem ReferenzTakt), aber nicht auf die Verwendung als interner und 
unabhängiger Taktgenerator.

Das einzige was ich mir an interner Generierung halbwegs verlässlich 
vorstellen kann ist wie die in der XAPP 872 beschriebene (Löthar verwies 
bereits darauf: 
https://www.xilinx.com/support/documentation/application_notes/xapp872.pdf). 
Wobei dieses Design auch nicht ohne externen Clock läuft, da taucht 
immer ein Reference Clock "Refclk" auf. Also wieder nichts mit Verzicht 
auf einen "Quarz". Die XAPP872 scheint einen Weg aufzuzeigen, wie man 
bei der Frequenzsynthese aus den starren Korsett der Teiler der DLL's 
ausbrechen kann, aber nicht wie man komplett ohne externen 
Referenz-clock auskommt.

Lothar M. schrieb:
> C. A. Rotwang schrieb:
>> Ich denke, es gibt diesen Fall "ohne" Quarz bei FPGA' nicht.
> Doch, durchaus.
> Ich habe Designs mit dem Lattice MachXO2, da wird der interne
> RC-Oszillator verwendet, weil er ausreicht und mit dem FPGA ein
> Protokoll ausgewertet und verarbeitet wird, das "sein" Timing mit sich
> bringt. Weil laufend die "Baudrate" nachgeregelt bzw. neu ermittelt
> wird, läuft das auch bei Versorgungsspannungs- und
> Temperaturschwankungen absolut zuverlässig ohne jeglichen Fehler.


"Sag niemals Nie" - hät ich bloß .

Also das Thema nachregeln der Baudrate könnte man auch als externer 
Referenztakt bezeichnen. Bei serieller Datenübertragung ist 
"Taktrückgewinnung" ein Standardverfahren und beim Sender werden dann 
gern Quarze so wie die guten alten "Baudratenquartze" eingesetzt. Also 
wieder eine externe Takterzeugung und interne Taktaufbereitung. Den 
Lattice RC-Generator muss ich mir aber mal genauer anschauen, ich bin 
gespannt "wie RC der tatsächlich ist" also ob der Vergleich mit einem 
Atmel-RC-interner Takt hier sinnvoll ist. Aber da der TE explizit sein 
Spartan-6 erwähnte scheint ein Lattice Vergleich nicht unbedingt 
angebracht. Für das TE-Board sehe ich keine reele Chance auf den Quartz 
zu verzichten. Und der beschriebenen Regelung würd ich die selbe 
Obergrenze bei der Taktrate zugestehen wie der AVR-µC-internen 
RC-Taktung -> ca. 8 MHz bei +/- 10% -> nicht wirklich eine Anwendung in 
der man "teure" 100 MHz-fähige FPGA's einsetzt. Aber vielleicht hat ja 
der technische Fortschritt inzwischen diese Erfahrungswerte überholt.


> In früheren Fällen hatte ich für solche "taktlosen" Designs auch schon
> Ringoszillatoren eingesetzt:
> http://www.lothar-miller.de/s9y/categories/29-Ringoszillator
> Die sind aber wesentlich kritischer in der Handhabung

Wie kritisch? Also ich seh hier das Problem das man ohne Messung am 
rausgeführten Taktpin nicht sagen kann, auf welcher Frequenz der Oszi 
wirklich schwingt. Auf die Angabe des Speedgrades bei FPGA's kann man 
sich ja auch nicht unbedingt verlassen, da kann einer der als langsam 
verkauft wird, tatsächlich ein schneller sein -> und schon läuft der 
interne Oszillator schneller. Oder beim P&R landet der Oszillator in 
einen "schnellen Bereich" des FPGA, so richtig homogen geht es bei den 
Nanometerstrukturen wohl nicht zu. Deshalb braucht man ja den Mastertakt 
um dann die unterschiedlichen Laufzeiten wieder gleich zu plätten.

C. A. Rotwang schrieb:
> Den
> Lattice RC-Generator muss ich mir aber mal genauer anschauen, ich bin
> gespannt "wie RC der tatsächlich ist" also ob der Vergleich mit einem
> Atmel-RC-interner Takt hier sinnvoll ist.

So hab mal kurz nachgeschlagen:
"The internal oscillator
accuracy is +/- 5% (nominal). This oscillator is intended as a clock 
source for applications that do not require a higher degree of accuracy 
in the clock."
aus TN1199 "MACHXO2 Sysclk .. usage Guide".

Also ähnlich mies wie man es aus Mikrocontrollern kennt, beispielsweise 
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2486-8-bit-AVR-microcontroller-ATmega8_L_datasheet.pdf 
S.270 .

Lothar M. schrieb:
> C. A. Rotwang schrieb:
>>> http://www.lothar-miller.de/s9y/categories/29-Ringoszillator
>>> Die sind aber wesentlich kritischer in der Handhabung
>> Wie kritisch?
> So kritisch, dass ich sie eigentlich nur noch zur Zufallszahlerzeugung
> nehme und ein LFSR damit asynchron zum "Mastertakt" takten.
> Damit habe ich eine Zufallskomponente, die bei jedem FPGA anders
> reagiert.

Also Takt dessen genauigkeit noch dazu taugt um "asynchron" zu takten - 
das ist wohl der schlechtmöglichste aller Takte und nicht das was der TE 
beabsichtigte.
Der könnte jetzt wirklich mal genauer beschreiben was er mit "wie der 
Spartan 6 das Clocksignal erzeugt ganz ohne Quarz" ... " weil der 
Spartan6 eben auf seinem Board genau das nicht tut. Und auf lale anderen 
Boards könnte ich Lothbeschreibung bzgl der Quali eines "ungwquarzten" 
Taktes wie: "Dieser Takt ist also bestenfalls für etwas geeignet, das 
"einfach irgendeinen Takt" braucht". anschliessen. Also etwas mit 
Genauigkeit im einstelligen Prozentbereich und weit weg von 
ppm-Genauigkeiten die der TE vermutlich erwartet.

C. A. Rotwang schrieb:
> Ich denke, es gibt diesen Fall "ohne" Quarz bei FPGA' nicht.
Aber sicher gibt es solche Fälle. Z.B. kann man sich die Frage stellen, 
was passiert, wenn der Takt ausfällt. Antwort: Die PLL läuft weiter. 
Probiere es aus.

Zudem war seine Frage genau so gestellt.

Allerdings kann man vermuten, warum er seine Frage so stellt. Nämlich: 
Weil er gar nicht weiß, was er fragen will.

Zu Lothars Ausführungen noch:

Das sind eigentlich keine Programmiertricks, sondern waren früher der 
Standard. Wer platziert ohne Grund einen Oszillator, wenn er keinen 
braucht? Damals hatten wir ein GAL oder PAL, das sich seinen Takt 
gemacht hat, um externe Signale zu sampeln und zu verarbeiten. War 
völlig normal.

Dass heute jeder Bautstein eine PLL drin hat, ist ja eine Neuerung 
jüngeren Datums.

Weltbester FPGA-Pongo schrieb im Beitrag #5347352:
> C. A. Rotwang schrieb:
>> Ich denke, es gibt diesen Fall "ohne" Quarz bei FPGA' nicht.
> Aber sicher gibt es solche Fälle. Z.B. kann man sich die Frage stellen,
> was passiert, wenn der Takt ausfällt. Antwort: Die PLL läuft weiter.
> Probiere es aus.

Nee, bei meinen designs tut sie das nicht. Schonmal weil meine Spartans 
eine DLL und keine PLL haben und dann haben manche Designs einen 
DLL-Resetgenerator eingebaut, der losschlägt wenn das LOCK-Signal 
entsprechend steht.

> Zudem war seine Frage genau so gestellt.
Ich lese die Frage des TE nicht so, ob er wüsste das in seinem Spartan6 
eine PLL im clock Pfad sein könnte.

> Allerdings kann man vermuten, warum er seine Frage so stellt. Nämlich:
> Weil er gar nicht weiß, was er fragen will.

Ja, schaut nach Lernphase aus, erst mal nach jeder Dummheit fragen die 
einem in den Sinn kommt.

> Das sind eigentlich keine Programmiertricks, sondern waren früher der
> Standard. Wer platziert ohne Grund einen Oszillator, wenn er keinen
> braucht?

Also ich kann mir kaum Fälle vorstellen, wo es keine stabile Frequenz 
braucht, muss also schon sehr lange zurück sein.

Schon der C64 hat einen Oscillator von  17,734475 MHz um die 
Videotimings der Monitore zu treffen. Die Baudratenquarze wurden ja 
schon erwähnt, die Uhrenwecker liefen mit Uhrenquarze, oder waren auf 
netzgeregelte 50Hz von der Primärseite abhängig. Im (digitalen) 
Audiobereich/Kommunicationsbereich gibt es auch einige "Grundfrequenzen 
die es zu treffen gilt, die WP nennt dort einige: 
https://en.wikipedia.org/wiki/Crystal_oscillator_frequencies Einzig 
Taschenrechner brauchten auf keine Standards Rücksichtnehmen und takten 
irgendwie. Oder Kaffeekocher, Waschmaschinen und der ganze 
Hausfrauenkram den man auch mit mechanischen Uhrwerk und Codierwalze 
aufbauen kann: https://youtu.be/IvUU8joBb1Q?t=175


Und mit einem RC-Oscillator spart man aus meiner Sicht nicht wirklich, 
sondern handelt sich eher "alte" Probleme wie bspw. Langzeitstabilität 
ein.

Was man an bspw im Job als Tools für die Produktion/Endprüfung gebaut 
hat und in der Betriebnahme wunderbar funktionierte, liegt nach ein paar 
Jahren ein paar Prozent daneben (Kondensatoralterung X7R 1% pro Dekade) 
und Quality läuft Amok warum das hausgebaute Tool in seinen 
Kernparameter "Lichtjahre" daneben liegt.
Also mir ist seit Jahrzehnten kein RC-Design mehr unterkommen, höchstens 
im Bastelbereich oder im Bereich (nicht nachahmenswertes) Retro. So ein 
Oszillator kostet bei reichelt unter einem Euro, ... eingebaut und nie 
den Kopf über Anschwingverhalten bei Kälte/Hitze machen oder 
Flankensteilheit oder oder oder.