Wie hängen Systemtakt und Oszillatorfrequenz zusammen?

Meine Frage ist beispielsweise ein Quarzoszillator auf einer MCU-Platine, wie wird der Systemtakt erzeugt? Ich werde diese Frage im Folgenden in mehrere Teile unterteilen:

  1. Ich habe immer den Eindruck, dass der Oszillator eine Sinuswelle erzeugt. Aber digitale Schaltungen verwenden eine Rechteckwelle als Taktsignal. Gibt es also immer eine Schaltung, die die Sinuswelle in eine Rechteckwelle mit derselben Frequenz umwandelt?

  2. Wenn der Oszillator schließlich für die MCU verwendet wird, um die Systemzeit zu zählen (z. B. ist die MCU in der Lage, einen aktuellen Zeitstempel zu geben oder eine Zeitdauer in Bezug auf ihre "Gerätezeiteinheit" zu messen), ohne eine Frequenzmultiplikation oder -division zu verwenden, tut man " Gerätezeiteinheit" der Dauer einer Periode des Oszillators entsprechen?

  3. Wenn zwischen der tatsächlichen Oszillatorfrequenz und ihrer Nennfrequenz ein konstanter Versatz besteht, wie übersetzt sich dieser Fehler in den Fehler in der Dauer, die durch eine "Gerätezeiteinheit" dargestellt wird?

Danke schön!

Beachten Sie, dass bei Prozessoren und Systemen mit höherer Frequenz ein PLL mit niedriger* Geschwindigkeit (100 MHz) einen Front Side Bus auf dem Motherboard speist, der dann an alle Subsysteme weitergeleitet wird, dh CPU / RAM / PCI-Controller - dies ist der gemeinsame Systemtakt. aus dem dann die einzelnen Subsystemtakte abgeleitet werden, meist über Frequenzvervielfacher. Ein Intel i7 erreicht 3,4 GHz über einen 100-MHz-FSB, der durch einen 34-fachen Multiplikator läuft. So funktioniert auch das CPU-Speed-Stepping auf modernen Systemen – der Multiplikator ändert sich automatisch je nach Systemlast, aber der FSB bleibt konstant.

Antworten (3)

Die PC-Taktung verwendet einen Referenzoszillator von etwa 25 MHz (eine beliebte Wahl für Ethernet und PCIe). Dies beginnt als Kristallsinuswelle, die von einem Puffer "quadratisch" gemacht wird, um ein digitales Signal zu erzeugen. Diese Rechteckwelle wird dann verwendet, um die verschiedenen Frequenzen (CPU, DRAM, PCIe usw.) mit PLL-Multiplikatoren und -Teilern zu erzeugen. Die resultierenden Takte haben normalerweise eine gewisse Verhältnisbeziehung zueinander.

Der Tick der Systemuhr kommt ebenfalls von derselben Referenz und wird verwendet, um Zeitgeber und einen Systemuhrzähler anzusteuern. Es wird auch eine numerische Beziehung zum Referenzoszillator haben, aber nicht unbedingt eine ganzzahlige Beziehung zum CPU-Takt. Dieser Uhrtick wiederum erzeugt eine Schätzung der "Wanduhr"-Zeit. Das Betriebssystem verwendet dies als Referenzzeit. Dies ist die Zeit, die vom Betriebssystem zB über den get_time()Systemaufruf zurückgegeben wird.

Es gibt jedoch ein Problem. Die Differenz zwischen der lokal geschätzten „Wanduhr“-Zeit und der tatsächlichen, auf Standards rückführbaren Zeit wird als Uhrendrift ausgedrückt und wird tatsächlich durch die Genauigkeit und Stabilität des Systemoszillators beeinflusst. Es wird nicht erwartet, dass PC-Kristalle genauer als etwa 30 ppm oder so sind, noch sind sie stabilisiert, also muss die Ortszeit von einer nachvollziehbaren Quelle korrigiert werden, wenn dies wichtig ist.

Wo spielt das eine Rolle? Server benötigen beispielsweise genaue Zeitstempel für Transaktionsereignisse.

Diese Systeme, die eine kalibrierte Referenz benötigen, stellen zunächst ihre geschätzte „Wanduhr“ basierend auf einer unabhängigen lokalen, nichtflüchtigen Referenz ein. Dies kann (und ist es oft) in Form einer lokalen batteriegestützten Echtzeituhr (manchmal auch als CMOS-Uhr bezeichnet) sein, die beim Start eine Schätzung der Wanduhrzeit erstellt.

Sobald das System läuft, kann die Maschine über ein Netzwerk mit einem Protokoll wie NTP auf eine auf Standards rückführbare Zeitreferenz zugreifen. Drahtlose Systeme können ein Mobilfunkgerät oder sogar einen GPS-Empfänger verwenden, der eine auf Standards rückführbare Zeit hat (dies gilt heutzutage für alle Mobiltelefone).

Unabhängig von der Methode - CMOS-Uhr, NTP, GPS oder Mobilfunk - diese Kalibrierung gewährleistet eine genaue Wanduhrzeit.

Ein Fall, in dem der Systemquarz selbst in Echtzeit eingestellt wird, sind digitale Fernsehempfänger. Diese verwenden eingebettete Timing-Referenzen im MPEG-2-Transport, um einen VCO oder einen „ziehbaren“ Kristall anzupassen, um die Taktdrift zu kompensieren. Dadurch wird sichergestellt, dass bei der Videowiedergabe keine langfristigen Über- oder Unterlaufprobleme auftreten. (Heutzutage verwenden sie einen Fractional-n-Clock-Synthesizer, um diese Anpassung vorzunehmen.) Dieser Standard generiert dann die Video- und Audio-Wiedergabetakte. Systeme, die diese Korrektur nicht verwenden, überspringen/wiederholen stattdessen Frames und/oder stören das Audio. (Erfahrung: IC-Design für Medienprozessoren.)

Was eine Low-End-MCU betrifft, gibt es nicht unbedingt einen Systemzeit-Tick, es sei denn, er wird von einem Timer generiert. Dies hat eine gewisse Teilerbeziehung zum Systemquarz, dessen Genauigkeit die Taktdrift bestimmt. Ein anständiger, richtig geladener Quarz sollte immer noch etwa +/-50 ppm liefern; RC-Oszillatoren, nicht so sehr. Auch hier ist es am besten, wenn die Genauigkeit kritisch ist, mit einer bekannten Referenz neu zu synchronisieren, um eine bekannte Wanduhrzeit zu ermitteln.

  1. Ja. Eine Rechteck-/Rechteckwelle ist erforderlich.

  2. nicht unbedingt. Zum Beispiel teilt ein Mikrocontroller des Basismodells 8051 die Oszillatorfrequenz durch 12. Somit ist der Zähler/Timer-Takt Oszillator/12. Vergleichen Sie dies mit einem AVR mega328 - Der standardmäßige interne Oszillator ist 8 MHz und vorausgesetzt, die div8-Sicherung ist nicht aktiviert, können die Timer bei 8 MHz zählen.

  3. Es gibt immer ein gewisses Maß an Fehler - der Oszillator könnte mit 8 MHz +/- 10 % spezifiziert sein oder etwas genauer könnte 8 MHz +/- 10 ppm (Teile pro Million) sein. Der Fehler würde sich auf Ihre Timing-Messungen auswirken, daher muss dies berücksichtigt werden.

Ein Beispiel wäre für Uart-Kommunikationen, die Sie im Allgemeinen besser als 2% Timing-Fehler wünschen. Bei Verwendung des AVR Mega328 wäre der interne Oszillator bei +/-10% nicht akzeptabel. Während Sie diesen Wert trimmen können, basiert er auch auf Temperatur und Spannung, sodass er driftet. Ein externer Quarz könnte mit mehr als 100 ppm spezifiziert sein, was eine viel bessere Wahl wäre, ohne dass ein Trimmen erforderlich wäre - er würde "out of the box" funktionieren.

  1. Wie der Oszillator schwingt, ist eine Sache, und welche Art von Ausgang der Oszillator erzeugt, ist eine andere Sache. In einer MCU würde die Oszillatorschaltung höchstwahrscheinlich nur die Sinuswellenform zur weiteren Verwendung in eine Rechteckwelle verstärken.

  2. Es hängt wirklich von der MCU ab. Es gibt MCUs, die die Quarzuhr direkt als Systemuhr verwenden können. Es gibt auch Prozessoren, die zwei, vier oder 12 Quarzuhren als Systemuhr verwenden. In einigen Fällen könnte die MCU sogar beide Flanken der Kristalluhr verwenden, um zu laufen, sodass sie variiert.

  3. Nein, definitiv kein Offset, sondern ein Verhältnis. Wenn die Uhr von einer Zielfrequenz aus 1 % zu langsam läuft, würde die gesamte MCU und alles darin 1 % zu langsam laufen, unabhängig davon, wie stark die Quarzfrequenz geteilt oder multipliziert wird, um die MCU-Systemuhr zu erhalten.