Flip-Flops mit mehreren Uhren

Angenommen, ich habe 2 Flipflops FF1 und FF2, die mit mehreren Takten angesteuert werden. Auf welche möglichen Verstöße könnten wir stoßen? Ich wurde dies in einem Interview gefragt, für das ich antwortete, dass der Unterschied in der Verzerrung oder den Uhren Timing-Verletzungen und Metastabilität verursachen würde, und weiter erklärte, wie Setup-/Holdtime-Verletzungen behoben werden können. Aber am Ende sagte der Interviewer, dass diese Probleme nur dann ins Bild kommen, wenn wir eine einzelne Uhr mit Versatz/Verzögerung zwischen den Takteingängen der 2 Flipflops verwenden. Also habe ich mich gefragt, ob mir jemand sagen kann, was passiert, wenn ich mehrere Uhren verwende

schematisch

Simulieren Sie diese Schaltung – Mit CircuitLab erstellter Schaltplan

Wow, ich weiß nichts über den Schaltplaneditor! Interessant!
Wenn die Takte erheblich unterschiedlich sind, kann eine Art Aliasing auftreten - dies gilt, wenn clk2 niedriger als clk1 ist
Hat der Interviewer sie als Edge- oder Level-Triggered FFs gezeichnet? Er wollte Sie dazu bringen, darüber zu diskutieren, wie Mehrphasen-Taktschemata das Skew-Problem reduzieren/eliminieren und eine robustere Lösung im Vergleich zu einem einphasigen flankengetriggerten Schema ermöglichen.
Nein, dies war ein Telefoninterview und seine FFs wurden flankengesteuert. Kennen Sie einen Link, der die Verwendung mehrerer Takte und ihre Probleme oder Vorteile beschreibt?
@Rancho CLK1 wird Daten in einem angemessen schnellen Tempo durch die Logik takten, und wenn CLK2 langsamer als CLK1 läuft, kann es wichtige Änderungen im Ausgang der Logik "übersehen" - fast so, als würden Sie ein Signal zu langsam abtasten - Sie können bekommen Aliasing-Effekte, die alles durcheinander bringen. Schlagen Sie Aliasing nach
Bedeutet das nicht Metastabilität? Die Ausgabe wäre ein unvorhergesehener Wert, da die Daten von FF1 möglicherweise nicht bei FF2 erfasst werden und möglicherweise einen falschen Wert haben? Ok, ich werde in Aliasing graben

Antworten (2)

Der Interviewer hat sich einfach geirrt. Sie müssen immer an Setup/Hold-Time-Verletzungen und die daraus resultierende Möglichkeit der Metastabilität denken, wenn Sie Signale betrachten, die von einer Clock-„Domäne“ zu einer anderen übertragen werden, unabhängig davon, ob die Clocks „nahezu synchron“ oder vollständig asynchron sind.

Für Signale, die deutlich langsamer als jeder Takt übergehen, können Sie normalerweise Doppel-FF-Synchronisierer verwenden. In anderen Fällen müssen Sie echte asynchrone FIFOs verwenden, möglicherweise mit einer Art Flusssteuerung oder Handshake-Mechanismus.

Man muss vielleicht in gewisser Weise über sie "nachdenken", aber es gibt viele Situationen in der realen Welt, in denen die Art der Quelle mindestens einer Uhr garantiert, dass die beiden Eingänge niemals nahe beieinander getaktet werden, also das "Denken". " muss sich möglicherweise nicht auf etwas über "Diese Eingänge werden immer mindestens 10 us auseinander schalten; die s / h-Zeiten auf dem zweiten Latch sind 2 ns und 5 ns. Da 10 us größer als 5 ns ist, gibt es kein Problem".
@supercat: Wenn Sie das sagen können, dann haben Sie es mit Uhren zu tun, die sich in derselben Domäne befinden, und meine Kommentare gelten nicht.
Vielleicht verstehe ich nicht genau, was mit "Domäne" gemeint ist? Angenommen, zwei unabhängige Takte bei 3,00 MHz und 3,14159 MHz gehen in T-Latches, deren Eingänge doppelt mit "Freigabe"-Signalen synchronisiert sind, und das Gerät, das die Freigabesignale steuert, deaktiviert einen Latch für mindestens 1 us, bevor er den anderen aktiviert. Wenn die Ausgänge dieser T-Latches als Takte verwendet würden, würden sie dann als in derselben Domäne oder in unterschiedlichen Domänen liegend betrachtet?
@supercat: OK, bei intermittierenden Uhren sprechen Sie überhaupt nicht über synchrone Designtechniken, und Sie müssen vollständige asynchrone Designregeln anwenden. Offensichtlich können Sie sich in dieser speziellen Situation einige Grundregeln einfallen lassen, die Metastabilität vermeiden, aber Sie mussten zumindest "darüber nachdenken", um dorthin zu gelangen.
Mit unterschiedlichen CLK-Domänen meinte er nur Uhren, die unabhängig sind. Wir sind daran gewöhnt, dass in unseren Kursen allen FFs (synchrone Designs) derselbe clk zugeführt wird. Nach dem, was ich gelernt habe, konnte ich nur an Metastabilität und Timing-Verletzungen denken. Ich bezweifle, dass er mit mehreren Domänen meinte, dass die Uhren nur ein bisschen auseinander lagen. Ich nehme etwas wie 2 & 4 MHz oder 5 & 10 MHz an (möglicherweise keine Beispiele aus der realen Welt). Ich werde nicht viel hinterfragen, da ich nicht zeigen möchte, dass ich nichts über mehrere Uhren wusste. Also habe ich nur geantwortet, was ich wusste! Danke für die Antworten. Ich werde; recherchieren Sie dazu weiter.
@Rancho: Es ist merkwürdig, dass ein Interviewer vorschlagen würde, dass Metastabilität nur dann ein Problem ist, wenn es eine einzige Taktquelle gibt. Wenn eine Uhr so ​​viel schneller ist als die andere, dass die hohen und niedrigen Zeiten der langsamen Uhr beide mindestens zwei Perioden der schnellen sind, kann man Metastabilität ziemlich einfach vermeiden, indem man die langsame Uhr mit der schnellen synchronisiert. Die Dinge sind viel schwieriger, wenn bekannt ist, dass keine der beiden Uhren viel langsamer ist als die andere.
@DaveTweed: Wie schwierig ist es, synchrone und asynchrone Logik in einem Design zu kombinieren? Mir ist aufgefallen, dass viele ARM-basierte Controller entweder wirklich die Menge an asynchroner Logik minimieren oder lästige Synchronisationslogik zwischen ihr und allem, was mit dem Kern zu tun hat, hinzufügen; Aus praktischer Sicht kann es in der Software einfacher sein, mit der Tatsache umzugehen, dass das Setzen eines „Weck“-Alarms auf einen asynchronen 32.768-Hz-Zähler in dem Moment, in dem er erhöht wird, ein falsches Ereignis erzeugen könnte, als zwei 30 us nach der Anfrage warten zu müssen einen Alarm, bevor er geändert werden kann. Wenn die Software den Interrupt vorher deaktiviert...
... die Alarmzeit schreiben, das Interrupt-Flag löschen und dann prüfen, ob die Uhr nicht vorgerückt ist, bevor sie das Interrupt-Flag aktiviert (wenn ja, wiederholen Sie den gesamten Vorgang), es wäre möglich, dass das Interrupt-Flag gehen würde metastabil, aber Software würde es niemals in Situationen aktivieren, in denen es metastabil sein könnte. Würden die Design-Tools jeden Versuch scheuen, ein solches Design zu erstellen (da die Tools sehen würden, dass die Verriegelung metastabil werden könnte, aber nicht wissen würden, dass die Software einen solchen Zustand vorhersehen und sicherstellen würde, dass es kein Problem verursacht)?
@supercat: Inwiefern ist die Synchronisationslogik "nerviger" als die Implementierung des aufwändigen Softwareprotokolls, das Sie skizziert haben? Im Allgemeinen werden Design-Tools tun, was Sie ihnen sagen; Sie erhalten höchstens Warnungen über mögliche Verstöße gegen die Setup-/Haltezeit. Darüber hinaus verfügen die meisten Tools über Möglichkeiten, diese Warnungen auf bestimmten Pfaden zu unterdrücken, für die Sie andere Vorkehrungen getroffen haben.
@DaveTweed: Jedes Mal, wenn man einen Alarm für eine zukünftige Zeit einstellt, ist es eine gute Idee, nach dem Einstellen des Alarms zu überprüfen, ob es sich immer noch um eine zukünftige Zeit handelt. Wenn der einzige synchronisationsbezogene Latch ein "Übereinstimmungs"-Flag ist, das eine Uhr mit dem Zähler teilt und ein asynchron erzeugtes Vergleichsergebnis erfasst, dann weiß man, dass er gesetzt ist, wenn sich der Zähler nicht bewegt hat, während der Alarm gesetzt wurde richtig. Wenn der programmierte Alarmwert mit dem Zählwert übereinstimmt, erfolgt das Aufwachen beim nächsten Zählzyklus. Wenn das Alarmregister doppelt synchronisiert ist...
...der früheste Alarm, den man einstellen kann, wird zwei 32-kHz-Zyklen in der Zukunft sein. Schlimmer noch, wenn man bei einer Reihe von Prozessoren mit solchen Weckfunktionen einen Wecker für eine ferne Zukunft stellt, zu Bett geht und fast sofort durch einen externen Reiz geweckt wird, kann man nicht damit beginnen, den Wecker für a einzustellen kürzere Zeit, bis die frühere Anforderung vollständig durch den Synchronisierer übertragen wurde. Somit wird es erforderlich, Weckereignisse, die innerhalb der nächsten vier Uhren auftreten sollen, anders zu handhaben als solche für weiter entfernte Zeiten.
@DaveTweed: Eine Sache, die viele Hardware-Leute nicht erkennen, ist, dass es in der Software oft nicht wirklich schwieriger ist, etwas zu tun und es erneut zu versuchen, wenn es fehlschlägt, als zu warten, bis etwas getan werden kann, und es zu tun. Wenn die Operation zB 50 Zyklen dauert und beim zweiten Versuch fast immer erfolgreich wäre, wenn nicht beim ersten, ist es viel besser, bis zu 100 Zyklen aufzuwenden, als bis zu 2.000–3.000 aufzuwenden.
@supercat: Ich stimme zu, es hört sich so an, als hätten die Hardwaredesigner in diesem Fall Probleme auf Systemebene nicht angemessen berücksichtigt. Es besteht wirklich keine Notwendigkeit, das Alarmregister doppelt zu synchronisieren, wenn Sie sich wirklich nur um die Ausgabe des Alarmkomparators kümmern. Eine andere Hardwareimplementierung wäre viel softwarefreundlicher.
@DaveTweed: Ich weiß nicht, warum es da draußen so viele verschiedene Programmierer-feindliche "Echtzeituhr mit Alarm" -Designs gibt. Es scheint, als sollte es einfach sein, einen 47-Bit-Zähler mit einem 32-Bit-Komparator zu entwerfen, der es ermöglichen könnte, einen Alarm für jeden zukünftigen Halbzyklus des 32-kHz-Takts einzustellen und sofort wirksam zu werden; Code, der einen Alarm setzen oder den vollen 48-Bit-Wert lesen möchte, müsste einen Versuch/Test/Neuversuch durchführen, aber eine solche Logik wäre in robusten Systemen auch ohne Metastabilitätsprobleme eine gute Idee. Übrigens hat die RTC eines Prozessors eine merkwürdige Eigenschaft: ...
...ein Register, das den Alarmkomparator anweisen kann, die unteren 0-7 Bits des Zählers zu ignorieren. Angeblich wird dies den Stromverbrauch reduzieren, aber ich bin mir nicht sicher, warum es sollte; Wenn jedes Bit des Zählers, beginnend mit dem MSB, ein "Match = (upper_bits_match & Cnt0 & !Comp0)" oder (upper_bits_match & !Cnt0 & !Comp0)" erzeugt, würden die unteren Bits des Zählers keine Transistoren im Komparator dazu veranlassen schalten, bis die oberen Bits übereinstimmen, sodass die dynamische Stromaufnahme im Grunde Null sein sollte. Man möchte vielleicht nicht verlangen, dass der Vergleich alle 32 Bits durchläuft, aber ...
... das Generieren eines "Übereinstimmungs" -Signals für die oberen 24 Bits und das anschließende Einspeisen in eine Kette für die unteren 8 Bits sollte immer noch funktionieren, um den dynamischen Stromverbrauch zu minimieren.

Die Frage wird verwirrend gestellt, was der springende Punkt gewesen sein könnte, da sie einige Konzepte aus verschiedenen Aspekten dessen, was als "synchrones Timing mit offenem Regelkreis" bekannt ist, durcheinander bringt. Er hat vielleicht nach Ihnen gesucht, um ein paar Schlüsselkonzepte zu klären. Offener Regelkreis bedeutet in diesem Zusammenhang, dass die Verzögerungen/Phasen unkontrolliert sind. Hier ist ein kurzer Überblick, der in Richtung starker Vereinfachung weist.

1) Globaler Takt, flankengetriggert. Woran die meisten Leute in Bezug auf synchrone Logik denken. Am beliebtesten für Low-End-Logikdesign, da das flankengetriggerte FF ein einfaches Modell des sequentiellen Designs bietet, zweitens sind flankengetriggerte FF häufig von TTL, CMOS und in den Standardzellenbibliotheken abgeleitet, die sie ersetzt haben, und drittens decken die meisten Logikdesignkurse nur ab Kantengetriggerte Designs. - Der Nachteil besteht darin, dass es zwei Einschränkungen gibt: Die maximale Verzögerung der Logik muss kleiner als eine Grenze sein, damit die Schaltung mit einer gegebenen Zykluszeit arbeitet. Die minimale Verzögerung muss größer als eine Grenze sein, die sich auf den Taktversatz bezieht, damit die Schaltung bei jeder Taktfrequenz arbeitet.

Die minimale Verzögerung der Logik:

T D , l Ö G ich C T S k e w + T H Ö l D T P R Ö P , C > Q

Die minimale Zyklusbeschränkung ist:

T C j T D , l Ö G ich C + T S k e w + T S e T u P + T P R Ö P , C > Q

2) pegelempfindliche Zweiphasen-Taktung. Ist vielleicht das Designregime mit dem höchsten Volumen. weil dies in Prozessoren und komplexeren Geräten verwendet wird. Natürlich gibt es dazu viele Varianten, hier schauen wir uns nur die Version mit nicht überlappender Uhr an. Die Logik wird durch die Master- und Slave-FFs geteilt und die minimale Zykluszeit wird nur durch die Prop-Zeit jedes Logikblocks und den Takt -> Q der FFs begrenzt. Clock Slew (in Grenzen) spielt bei diesen Designs keine Rolle, und daher sind sie robuster, schneller und kleiner. Es ist mir nicht klar, warum das nicht so oft gelehrt wird.

T C j T D , l Ö G ich C 1 + T D , l Ö G ich C 1 + 2 T P R Ö P , C > Q

Dieser zweite Fall, wenn es keine OL-Takte und keinen zweiten Logikblock gibt, kehrt zum ersten Fall zurück.

3) Pipeline-Timing: das wir hier nicht besprechen werden.