Was ist eine Ripple-Clock?

Ich lese gerade Kapitel 12. Empfohlene Designpraktiken aus dem Quartus II Handbuch Version 13.1 Band 1: Design und Synthese , in dem es heißt (S. 8):

Ripple-Zähler verwenden kaskadierte Register, bei denen der Ausgangspin eines Registers den Taktpin des Registers in der nächsten Stufe speist. Diese Kaskadierung kann Probleme verursachen, da der Zähler in jeder Stufe eine Ripple-Clock erzeugt. Diese Ripple-Clocks müssen während der Timing-Analyse richtig gehandhabt werden, was schwierig sein kann und erfordert, dass Sie komplizierte Timing-Zuweisungen in Ihren Synthese-, Platzierungs- und Routing-Tools vornehmen.

Was ist eine Ripple-Clock? Warum ist die Timing-Analyse auf einer Ripple-Clock schwierig?

Antworten (4)

In Quartus II ist Ripple Clock jede Uhr, die von der Ausgabe eines anderen Registers angetrieben wird. Einige Probleme mit Ripple Clocks:

  1. Der letzte Takt hat eine Verzögerung gegenüber dem Eingangstakt, da er mehrere Flops durchläuft. Was ist also das Problem mit dieser Verzögerung? Sie werden Probleme haben, wenn Ihr Design domänenübergreifende Pfade zwischen diesen beiden Uhren hat. Wenn ein Pfad einen Starttakt von der Eingangstaktdomäne und einen Erfassungstakt von dieser abgeleiteten Taktdomäne hat, wird dieser Pfad einen großen Versatz haben. Sie werden es also schwer haben, das Timing einzuhalten.

  2. Ein weiteres Problem besteht beim Schreiben von SDC-Einschränkungen. Sie müssen die Taktdefinitionen auf jeder Stufe schreiben, auch wenn sie nicht verwendet werden. Ein Beispiel sehen Sie hier auf Seite 18.

Dies ist ein Wellenzähler:

schematisch

Simulieren Sie diese Schaltung – Mit CircuitLab erstellter Schaltplan

Es ist ein asynchroner Zähler, der den Eingangstakt in jeder Stufe durch 2 teilt. Es ist ein asynchroner Zähler, da sich jede Stufe zu unterschiedlichen Zeiten ändert und jedes Flip-Flop einen anderen Takteingang hat. Die Zeitdifferenz zwischen jeder Stufe wird durch die CLOCK->Q-Verzögerung des verwendeten Flip-Flops bestimmt. Das simulierte Ergebnis ist unten dargestellt und zeigt, dass jede Stufe den Ausgangsübergang um die Verzögerung von Takt zu Ausgang verzögert.

Geben Sie hier die Bildbeschreibung ein

Nun, um die Bedeutung davon im Zusammenhang mit einem FPGA zu sehen: Das Timing-Analysetool möchte sicherstellen, dass alles zum richtigen Zeitpunkt getaktet wird. Ein Teil davon besteht darin, jedes Signal, das in den CLK-Pin eines Flip-Flops eintritt, zu einer Systemuhr zu machen, die mit allen anderen Uhren synchronisiert werden sollte. Wenn ich also das obige Schema in ein FPGA-Synthesetool eingeben würde, würde es die Netze CLK_IN, DIV_2, DIV_4und DIV_8als "Uhr"-Netze betrachten, unabhängig davon, ob sie zum Ansteuern anderer Uhren verwendet werden. Dies wird wahrscheinlich als Zähler gut funktionieren (es besteht die Möglichkeit einer Haltezeitverletzung bei jedem Flipflop), wird jedoch nicht in der synchronen Logikmethode ausgeführt.

Wenn Sie dies verwenden, um einen schnellen Eingangstakt zu nehmen und einen einzelnen, langsameren Takt abzuleiten (z. B. DIV_8einen Haupttakt für das System zu erstellen), ist dies wahrscheinlich in Ordnung.

Das Problem tritt auf, wenn Sie schnelle Schaltungen haben möchten, die mit getaktet sind , und CLK_INmit langsamen Schaltungen interagieren, die mit getaktet sind DIV_8. In diesem Fall möchten Sie, dass die ansteigenden Flanken des Takts synchronisiert werden, aber Sie werden einen großen Taktversatz zwischen diesen Taktnetzen haben. Der von einer Stufe erzeugte Taktversatz könnte ausreichen, um Synchronisationsfehler zu verursachen, und mehr Stufen werden dies fast garantieren.

Wenn Sie zwei synchronisierte Takte in einem FPGA erstellen möchten, verwenden Sie am besten einen synchronen Taktgenerator oder ein FPGA-internes Taktmodul, z. B. einen PLL/DCM-Block.

Wenn die Zählrate eines Welligkeitszählers langsamer als die Haupttaktrate ist, würde ich erwarten, dass man den Wert zuverlässig erhalten kann, indem man mehrere aufeinanderfolgende Messwerte nimmt (drei, es sei denn, die Welligkeitsausbreitung ist sehr langsam). Ich habe nicht viele Chips gesehen, die einen Ripple-Zähler direkt der Software aussetzen, aber wenn Sie z. B. einen schnellen CPU-Takt verwenden, um einen Zähler zu lesen, der mit 32.768 Hz läuft, sollte der Code Lesungen vornehmen, bis zwei aufeinanderfolgende übereinstimmen, die nicht weniger zuverlässig sind als eine mehrstufige Sequenz verwenden zu müssen, um den Wert in einem synchronisierten Register zu erfassen und zu lesen.
@supercat Das Problem ist nicht, dass es unmöglich ist, sondern nur, dass es eine Gefahr gibt. Sie haben gültige Minderungsstrategien beschrieben, aber das statische Timing-Analysetool wird keine Annahmen über Ihre Signalbehandlung treffen. Sie können dieses Verhalten überschreiben, indem Sie das Design konfigurieren, aber die Absicht ist, dass die Software "sicher" fehlschlägt.
Fair genug. Beim Betrachten der verschiedenen Anforderungen, die Chips beim Zählen asynchroner Signale stellen, frage ich mich oft, inwieweit Design-Tools Diener der Chip-Designer sind und inwieweit die Designer und ihre Designs Sklaven der Tools sind. Ich würde zum Beispiel denken, dass es üblich wäre, dass ein Chip die CPU-Geschwindigkeit drosseln möchte, wenn er nicht viel tut, aber in der Lage wäre, sie hochzufahren, wenn serielle Daten ankommen, die verarbeitet werden müssen, aber relativ wenige Mikrocontroller erlauben dies die CPU-Geschwindigkeit geändert werden, ohne den UART-Betrieb zu unterbrechen.
Ich erkenne an, dass zur Vermeidung von Metastabilität Zero-Wait-State-E / A nur zulässig sein kann, wenn die CPU auf Dinge zugreift, die mit der CPU-Uhr synchron sind. Wenn man jedoch Wartezustände akzeptieren kann, sollte es dann Probleme geben, ein E/A-Subsystem zu haben, als wäre es über einen asynchronen Speicherbus alten Stils mit der CPU verbunden? Oder liegt das Problem hauptsächlich darin, dass Design- und Simulationswerkzeuge mit solchen Dingen nicht sehr gut umgehen können?
Eine gute Alternative, die all diese Probleme vermeidet, besteht darin, eine langsame Logik basierend auf den schnellen Takt- plus Taktfreigabesignalen zu implementieren, die für einen Taktzyklus pro langsamem Intervall pulsieren.
@BenVoigt: Das ist gut, wenn die schnelle Uhr immer existiert und "schnell" ist. Was ich gerne sehen würde, wäre ein peripheres Subsystem, das das Timing von einer von der Systemuhr getrennten Uhr ableitet und von der Systemuhr getaktet werden könnte, wenn sie angemessen schnell lief (durch ein einmaliges Taktsignal pro Peripherie gesteuert). ). Keine Ahnung, wie praktikabel so etwas wäre.
@supercat: Ich glaube nicht, dass es machbar ist. Sie können jedes Mal, wenn die Taktquelle wechselt, einen Taktzyklus verlieren (da Sie die Mindestzykluszeit nicht verletzen können, müssen Sie auf die folgende Flanke warten), daher denke ich nicht, dass "innerhalb von zwei Takten" erreichbar ist langfristig. Einige FPGA-Taktverteilungsblöcke verfügen über Fallback-Clock-Fähigkeiten, jedoch ohne die „innerhalb von zwei Zyklen“-Garantie.
@BenVoigt: Angenommen, man hat einen 3-Bit-Graycode-Zähler, der die Anzahl der Impulse des 1-MHz-Takts zählt, die seit dem Einschalten aufgetreten sind, und einen 3-Bit-Graycode-Zähler, der die Anzahl der "aktiven" Takte zählt, die seitdem von der Logik verarbeitet wurden Start-up. Wenn vom 1-MHz-Takt zum 4-MHz-CPU-Takt kommt, ist es möglich, dass zwei 1-MHz-Takte auftreten, ohne dass die Peripherielogik getaktet wird, aber bei den ersten beiden 4-MHz-Takten, die sie empfängt, sollte sie bemerken, dass die Zähler nicht übereinstimmen, und somit die Peripherie aktivieren Logik auf beiden. Der Effekt wäre, dass die erste Uhr nach dem Wechsel...
... würde "spät" passieren, aber man könnte die Taktquellen beliebig oft wechseln, ohne einen Nettogewinn oder -verlust von Taktereignissen. Einige Anwendungen würden erfordern, dass peripher erzeugte Flanken auf 1 us genau sind, aber in vielen Anwendungen würde 1 us Jitter kein Problem darstellen, wenn Jitter die einzige Unsicherheit beim Zählen darstellen würde.
Leute ... dies ist nicht der Ort, um über Uhrsynchronisationstechniken zu diskutieren. Mein Punkt (in der Antwort) ist, dass dies eine Warnung ist und potenzielle Gefahren bestehen, wenn es Wechselwirkungen zwischen mehreren Taktdomänen gibt. Wenn Sie eine dieser Techniken implementiert haben, dann haben Sie die „Ripple Clock“-Warnung beachtet.
@supercat: Denken Sie darüber nach, jedes Mal, wenn Sie die Uhr zwischen zwei nicht ausgerichteten Quellen umschalten, kann das Intervall zwischen den Kanten nicht genau sein (die Uhren sind nicht ausgerichtet), also muss es zu lang oder zu kurz sein. Zu kurz verstößt gegen Timing-Einschränkungen, sodass Sie bei jedem Schalter Zeit verlieren müssen.

Dieses Problem betrifft nicht nur einfache Binärzähler, sondern auch kompliziertere wie Dekadenzähler (wie den 74HCT4017 ), bei denen jeder Zähler intern von 0-9 zählt und so verdrahtet ist, dass er beim zehnten Impuls auf 0 zurückgesetzt wird.

Angenommen, Sie haben mehrere Dekadenzähler, einen für die Einerstelle, die Zehnerstelle, die Hunderterstelle usw.

Jeder der Dekadenzähler hat einen Takteingang. Der Takt des Einheitenzählers wird von der Haupttaktquelle gespeist, die vermutlich ein- und ausgeschaltet werden kann. Der Takt des Zehnerzählers ist mit dem Übertragsausgang des Einerzählers verbunden. Wenn der Einheitenzähler von 9 bis 10 zählt, passieren zwei Dinge: Der Zähler wird auf 0 zurückgesetzt (es gibt also wirklich nie eine gültige 10-Ausgabe) und ein Taktimpuls wird an den Takteingang des nächsten Zählers weitergeleitet Fall die Zehnerstelle.

Der Grund, warum es Ripple Clock genannt wird, ist, dass die Uhr, die in den Zehnerzähler geht, um mindestens eine Ausbreitungsverzögerung gegenüber der ursprünglichen Uhr verzögert wird, die in die Einerstelle geht. Dies hat dann einen sogenannten "Ripple-Effekt", zB wenn Sie einen 6-stelligen Zähler haben, wird die Uhr, die bei einem Übergang von 099999 auf 100000 auf die sechste Stelle geht, fünfmal verzögert.

Dies kann zu Timing-Problemen führen, wenn beispielsweise versucht wird, die Ausgabe der Zähler mit einem bestimmten Wert zu vergleichen, ändern sich die Zähler nicht alle auf einmal, sodass die Vergleichsschaltung möglicherweise zur falschen Zeit ausgelöst wird – dafür gibt es kein Signal sagt: alle Ausgänge sind stabil.

Soweit ich gesehen habe, sind Ripple Conters, wie sie manchmal genannt werden, digitale Timer (Zähler), die verwendet werden, wenn keine Präzision erforderlich ist und Einfachheit das Ziel ist. Sie können zusätzlich als Taktteiler verwendet werden, um ein Eingangstaktsignal um eine Größenordnung von 2 pro Stufe vorzuskalieren.

Grundsätzlich haben Sie eine Reihe verbundener FlipFlops, bei denen der Ausgang der vorherigen Stufe zum Taktgeber der nächsten Stufe wird.

Abbildung 1

Siehe: Ripple-Zähler

Was ist eine Ripple-Clock?
AntwortenHierDatenschutz-Bestimmungen1y, 0v