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.
Detlef schrieb: > 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. Meinst du den internen RC-Oszillator, der zum Landen des Bitstroms verwendet wird und über undokumentierte Tricks auch in "eignen" Designs als Taktquelle verwendet werden kann? Dann etwa plusminus 500000PPM (also ca. +-50%): http://forum.gadgetfactory.net/topic/2034-hidden-clock-in-the-spartan-6/ Dieser Takt ist also bestenfalls für etwas geeignet, das "einfach irgendeinen Takt" braucht... Oder meinst du sowas: https://www.xilinx.com/support/documentation/application_notes/xapp872.pdf Aber ich denke, du solltest da eher mal den Xilinx FAE fragen...
:
Bearbeitet durch Moderator
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.
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.
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. 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 und idR. finden sich die 3x5mm für den Oszillator immer. Detlef schrieb: >>> Bzw. wo kann ich das nachlesen? >> Schaltplan, Datenblatt Oszillator > Ok vielen Dank! Warst mir eine riesen Hilfe :) Das war jetzt hoffentlich nicht ernst gemeint? Natürlich ist bei der Frage nach Komponenten bzw. Funktion eines Board immer der Schaltplan die allererste Anlaufstelle, die dann zur BOM (Stückliste) und von dort zum Datenblatt der Bauteile führt. Da kann man aber leicht selber drauf kommen...
:
Bearbeitet durch Moderator
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 .
C. A. Rotwang schrieb: > Also ähnlich mies wie man es aus Mikrocontrollern kennt Klar, ist ja auch die selbe Technik. C. A. Rotwang schrieb: > nicht wirklich eine Anwendung in der man "teure" 100 MHz-fähige FPGA's > einsetzt. Teuer ist relativ, wenn ich so einen MachXO2 in Kleinststückzahlen für 4€ kaufen kann und so parallele Hardware ohne jegliche Interrupt- und Ausführungslatenzen bekomme, dann löse ich damit schon mal Aufgaben, die mit etwas Hirnschmalz und durchdachter Programmierung sicher auch mit einem uC lösbar wären. >> 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.
:
Bearbeitet durch Moderator
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.
Wie irgendwo ganz oben schon mal geschrieben kann der Spartan 6 auch seinen Config Clock (der ja für alle Master config modes da sein muss) verwenden, das geht mit der STARTUP Primitive. Aber der ist eben mit +-50% spezifiziert. Das kann man für einfaches Blinken schon nehmen aber für Baudrate schon nicht mehr.
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.
C. A. Rotwang schrieb: > 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" Na er hatte offenbar ein Bild von einem Quarz im bekannten HC Gehäuse im Kopf, den er natürlich deshalb nicht gefunden hat, weil ja ein Quarzoszillator die Takterzeugung erledigt. Und dass diese Information im Schaltplan am offensichtlichsten dargestellt ist, diese Idee ist ihm nicht gekommen.
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.