Statische und dynamische Hazards in kombinatorischer Logik

Kurz gesagt: Ein statischer Hazard ist ein möglicher Impuls an einem Ausgang, der während eines Eingangssignalwechsels konstant bleiben sollte; ein dynamischer Hazard erzeugt mehrere Ausgangswechsel, obwohl nur einer beabsichtigt war. Decken Sie für ein zweistufiges SOP-Netzwerk unter der Annahme einer einzelnen Eingangsänderung jedes benachbarte Paar von 1-Zellen mit einem gemeinsamen Implikanten ab; der hinzugefügte Konsensterm erhält die Boolesche Funktion und schließt zugleich die gefährliche Übergabestelle. Dieser Beweis deckt nicht automatisch mehrere sich ändernde Eingänge, mehrstufiges Mapping, asynchrone Rückkopplung oder Synthese ab, die die redundante Logik entfernt.

Eine Wahrheitstabelle legt stabile Ein- und Ausgangswerte fest. Sie legt nicht fest, was passiert, während Signale durch Gatter mit unterschiedlichen Verzögerungen laufen. Zwei Implementierungen derselben Booleschen Funktion können daher in jeder stabilen Zeile übereinstimmen und sich nach einer Eingangsänderung für einige Nanosekunden unterschiedlich verhalten.

Dieses Übergangsverhalten ist wichtig, wenn es eine asynchrone Steuerung, einen Takt- oder Reset-Eingang, einen externen Pin, ein pegelsensitives Speicherelement oder eine Abtastflanke erreicht.

Hazard, Glitch und Race

Ein Race liegt vor, wenn zwei oder mehr relevante Signalpfade zeitlich miteinander konkurrieren. Ein Hazard ist eine Schaltungsstruktur mit einem Übergang, bei der eine zulässige Reihenfolge der Pfadverzögerungen einen unerwünschten Ausgangswechsel erzeugen kann. Ein Glitch ist der Impuls, der in einem konkreten Timing-Fall beobachtet wird.

Die Unterscheidung ist nützlich:

• Eine Simulation ohne Verzögerungen kann einen Hazard verbergen.
• Ein Verzögerungssatz kann den Hazard enthalten, aber keinen Impuls zeigen.
• Prozess, Spannung, Temperatur, Platzierung oder Verdrahtung können verändern, welcher Pfad gewinnt; und
• „Ich habe keinen Glitch gesehen“ ist kein Beweis für Hazardfreiheit.

Statische Hazards

Ein statischer 1-Hazard ist möglich, wenn der Ausgang 1 bleiben sollte, aber kurz auf 0 fallen kann. Er wird üblicherweise in einem zweistufigen Sum-of-Products-(SOP)-Netzwerk analysiert.

Ein statischer 0-Hazard ist das Dual dazu: Der Ausgang sollte 0 bleiben, kann aber kurz auf 1 steigen. Er wird üblicherweise in einem zweistufigen Product-of-Sums-(POS)-Netzwerk analysiert.

Das Lehrbuchverfahren mit Karnaugh-Maps setzt voraus:

1. Das Netzwerk ist in der angegebenen zweistufigen Form implementiert.
2. Es ändert sich jeweils nur eine Eingangsvariable.
3. Gatter und Verbindungen können beliebige positive Verzögerungen haben; und
4. Stabile Eingangswerte erfüllen die vorgesehene Boolesche Funktion.

Ändern sich diese Annahmen, muss sich auch der Beweis ändern.

Durchgerechnetes Beispiel für einen statischen 1-Hazard

Betrachten Sie:

Wenn $B=C=1$ gilt, ist der stabile Ausgang für jeden Wert von $A$ gleich 1:

• bei $A=1$ hält der Term $AB$ den ODER-Ausgang hoch;
• bei $A=0$ hält der Term $\overline{A}C$ ihn hoch.

Während eines Übergangs von 1 nach 0 bei $A$ kann der direkte Pfad $AB$ deaktivieren, bevor der Inverterpfad $\overline{A}C$ aktiviert:

Die mittlere Zeile ist keine weitere Wahrheitstabelleneingabe. Sie steht für ungleiche Ankunftszeiten innerhalb der Implementierung.

Finden Sie die Naht auf einer Karnaugh-Map

Für die Variablen $A$, $B$ und $C$:

              BC
        00   01   11   10
      +----+----+----+----+
 A=0  |  0 |  1 |  1 |  0 |
      +----+----+----+----+
 A=1  |  0 |  0 |  1 |  1 |
      +----+----+----+----+

Das ursprüngliche SOP verwendet:

• $\overline{A}C$ für die Zellen der oberen Zeile, in denen $C=1$ gilt; und
• $AB$ für die Zellen der unteren Zeile, in denen $B=1$ gilt.

Die Zellen A=0, B=1, C=1 und A=1, B=1, C=1 sind benachbart, weil sich nur A unterscheidet. Dennoch deckt kein ausgewählter Implikant beide ab. Beim Wechsel von A muss die Zuständigkeit für den Ausgang von einem Produktausdruck auf einen anderen übergehen. Diese nicht abgedeckte Nachbarschaft ist die Naht des statischen 1-Hazards.

Den Konsensterm hinzufügen

Der Konsens von $AB$ und $\overline{A}C$ ist $BC$:

Der Konsenssatz lautet:

Der hinzugefügte Term ändert daher kein stabiles Ergebnis der Wahrheitstabelle. Während des gefährlichen Übergangs bei $B=C=1$ bleibt $BC$ jedoch 1 und hält den ODER-Ausgang hoch.

Auf der Karnaugh-Map ist $BC$ die vertikale Gruppe über die beiden benachbarten Zellen. Das allgemeine zweistufige SOP-Verfahren lautet:

1. Identifizieren Sie jeden zulässigen Übergang einer einzelnen Variablen zwischen benachbarten 1-Zellen.
2. Prüfen Sie, ob die implementierte Überdeckung einen Implikanten enthält, der jedes Paar überspannt.
3. Fügen Sie für jedes nicht abgedeckte Paar einen geeigneten Konsens- oder Überdeckungsterm hinzu; und
4. Verifizieren Sie, dass Synthese und physische Implementierung die vorgesehene Struktur erhalten.

Das duale Verfahren deckt benachbarte 0-Zellen in einer POS-Implementierung ab, um statische 0-Hazards zu verhindern.

Minimale Logik und hazardfreie Logik optimieren unterschiedliche Ziele

Das minimale SOP hat weniger Terme, weil $BC$ Boolesch redundant ist. Das hazardfreie SOP behält die physische Redundanz absichtlich bei.

Das schafft ein Implementierungsproblem: Ein Logiksynthesizer darf normalerweise Terme entfernen, die die Boolesche Funktion nicht ändern. Er kann den Ausdruck auch in ein mehrstufiges Netzwerk faktorisieren oder ihn in Look-up-Tabellen und Zellen mit unterschiedlichem internem Verhalten abbilden.

Wenn Hazardfreiheit eine Anforderung ist:

• Formulieren Sie sie als Implementierungsconstraint, nicht als Kommentar.
• Verwenden Sie die dokumentierte Methode des Anbieters zur Erhaltung oder zur hazardfreien Implementierung.
• Prüfen Sie die synthetisierte Netzliste.
• Führen Sie eine timingbewusste Verifikation des gemappten Designs durch; und
• Validieren Sie die endgültig geroutete Implementierung, sofern der Zielablauf dies unterstützt.

Eine RTL-Gleichung allein garantiert nicht, dass der physische Konsenspfad die Optimierung übersteht.

Dynamische Hazards

Ein dynamischer Hazard tritt auf, wenn sich der korrekte Ausgang einmal ändern sollte, die Implementierung ihn aber vor dem Einschwingen mehrmals ändern kann – beispielsweise 0 → 1 → 0 → 1.

Dynamische Hazards benötigen mehrere zusammenwirkende Verzögerungen und stehen mit mehrstufiger, rekonvergenter Logik in Verbindung. Ein zweistufiges Netzwerk, das unter dem Modell einer einzelnen Eingangsänderung nachweislich frei von den relevanten statischen Hazards ist, lässt sich leichter analysieren; eine faktorisierte oder technologieabgebildete Realisierung kann diese Struktur nicht mehr haben.

Es gibt keine universelle Korrektur nach dem Muster „einen Term hinzufügen“ für einen beliebigen dynamischen Hazard. Praktische Antworten sind:

• Umgestaltung oder erneute Synthese zu einer Form mit einem Beweis für Hazardfreiheit;
• Registrierung des Ergebnisses, bevor es einen empfindlichen Verbraucher erreicht;
• Verwendung eines Handshakes oder eines Zustandsmaschinenstils, der für asynchronen Betrieb entworfen wurde;
• Einsatz zielspezifischer glitchfreier MUX-/Taktsteuerungszellen; und
• Verifikation des implementierten Verzögerungsverhaltens.

Beliebige Verzögerungspuffer hinzuzufügen, um Pfade „auszugleichen“, ist über Prozess, Spannung, Temperatur und Verdrahtung hinweg fragil, sofern die Entwurfsmethodik nicht ausdrücklich auf begrenzten Verzögerungen beruht und sie einschränkt.

Mehrere Eingangsänderungen und funktionale Hazards

Die Nachbarschaft in einer Karnaugh-Map steht für die Änderung einer Variablen. Wenn sich zwei unabhängige Eingänge nahe beieinander ändern können, kann die Schaltung eine von mehreren stabilen Zwischenkombinationen durchlaufen. Selbst ein Netzwerk ohne statische Hazards bei Einzel-Eingangsänderungen kann einen funktionalen Hazard erzeugen.

Ein Übergang von 00 zu 11 kann beispielsweise physisch über 01 oder 10 verlaufen. Wenn sich die Boolesche Funktion in diesen Zwischenzeilen unterscheidet, kann kein redundantes Gatter beide Wege gleichwertig machen, ohne die Funktion zu verändern.

Optionen auf Systemebene sind:

• ein Protokoll mit nur einer Eingangsänderung erzwingen;
• Übergänge, wo passend, so kodieren, dass sich nur ein Bit ändert;
• zusammengehörige Steuerungen synchronisieren und registrieren;
• Request/Acknowledge-Handshakes verwenden;
• ein kohärentes Datenbündel erst nach einem Valid-Signal erfassen; oder
• die Schnittstelle so umgestalten, dass gleichzeitige Eingangsänderungen nicht kombinatorisch interpretiert werden.

Gray-Code hilft bei einem bestimmten Problem benachbarter Zustände; er ist kein Allheilmittel für beliebige Busse.

Wenn synchrone Logik den Glitch eindämmt

Wenn ein kombinatorisches Ergebnis nur einen D-Eingang eines Flipflops speist und das Netzwerk vor der Abtastflanke mit Setup-Reserve eingeschwungen ist und während der Hold-Zeit stabil bleibt, muss ein interner Glitch nicht zum architektonischen Zustand werden.

Diese Aussage hat Grenzen:

• Der Glitch verbraucht dennoch dynamische Leistung.
• Er kann sich in einen anderen Pfad mit anderem Timing fortpflanzen.
• Er ist an asynchronen Resets, Sets, Takten, Enables und Handshakes gefährlich.
• Er kann erfasst werden, wenn die Timing-Reserve schrumpft; und
• Er kann an Pins oder Chip-Select-Signalen extern sichtbar sein.

Erzeugen Sie keinen Takt, indem Sie Logik durch ein gewöhnliches kombinatorisches Netzwerk führen. Verwenden Sie integrierte Clock-Gating-Zellen, FPGA-Taktsteuerungsressourcen oder ein synchrones Design auf Basis eines Enable-Signals.

Asynchrone und essenzielle Hazards

Asynchrone sequenzielle Schaltungen erlauben absichtlich, dass Übergänge den Zustand ohne globale Abtastflanke beeinflussen. Sie erfordern eine Entwurfsmethodik, deren Verzögerungsannahmen, Zustandskodierung, Handshakes und Bedingungen für Hazardfreiheit explizit sind.

Ein essenzieller Hazard entsteht dadurch, dass sich ein Eingang in einer asynchronen Rückkopplungsimplementierung unterschiedlich schnell ausbreitet, sodass der interne Zustand fortschreiten kann, bevor die Eingangsänderung jeden erforderlichen Punkt erreicht hat. Er ist nicht einfach ein anderer Name für einen kombinatorischen statischen Glitch, und ein Konsensterm beseitigt ihn im Allgemeinen nicht.

Die Behandlung essenzieller Hazards gehört zur Spezifikation und Implementierung der asynchronen Maschine – oft mit Annahmen über Rückkopplungsverzögerungen oder einer anderen Schaltungsstruktur. Der Wechsel zu synchroner Logik ist eine Option, kein Beweis dafür, dass alle Hazards verschwinden.

Das richtige Modell simulieren

Ein digitaler Simulator ohne Verzögerungen ändert abhängige Knoten normalerweise im selben simulierten Zeitpunkt und zeigt möglicherweise keinen Impuls. Um Hazards zu untersuchen, muss das Modell ungleiche Laufzeiten enthalten:

1. Bauen Sie $F=AB+\overline{A}C$ auf.
2. Halten Sie $B=C=1$.
3. Weisen Sie dem direkten und dem invertierten A-Pfad eine dokumentierte Verzögerungsdifferenz zu oder erzeugen Sie sie.
4. Schalten Sie nur A um.
5. Untersuchen Sie F mit einer Zeitauflösung, die kleiner als die modellierte Verzögerung ist; und
6. Fügen Sie $BC$ hinzu und wiederholen Sie den Vorgang.

Wenn die Pufferkomponente des Simulators keine logische Verzögerung hat, beweist das Hintereinanderschalten von Puffern nichts. Verwenden Sie eine verzögerungsbewusste Funktion, eine Gate-Level-Timingsimulation oder eine physische Messung.

Das Ausbleiben eines Impulses bei einer Verzögerungszuweisung ist ein Beleg für diesen Durchlauf, aber kein Beweis für jede zulässige Verzögerung.

Checkliste zur Verifikation

• Welche Eingänge dürfen sich gemeinsam ändern?
• Muss der Ausgang konstant bleiben oder einen Übergang ausführen?
• Ist das implementierte Netzwerk zweistufig, faktorisiert oder als LUT/Zelle abgebildet?
• Teilt jedes relevante benachbarte Paar der Karnaugh-Map einen Überdeckungsterm?
• Kann die Synthese die Redundanz entfernen oder refaktorisieren?
• Steuert der Ausgang nur einen registrierten D-Eingang oder eine empfindliche Steuerung?
• Wurden minimale und maximale Verzögerungen nach Mapping und Routing geprüft?
• Werden asynchrone Rückkopplung und essenzielle Hazards mit einer anerkannten Methodik behandelt?

Nächste Schritte

Der Leitfaden zu Clock Skew erklärt, wie ungleiche Taktankunft Setup- und Hold-Reserven verändert. Don’t-Care-Bedingungen in Karnaugh-Maps erklärt, wann nicht spezifizierte Eingangskombinationen die Minimierung unterstützen können – doch ein Don’t-Care muss durch den Systemvertrag gerechtfertigt sein, bevor es in einer Hazard-Analyse verwendet wird.

Primärquelle

• David A. Huffman, „Entwurf und Einsatz hazardfreier Schaltnetzwerke“, Journal of the ACM, 1957