Serielle Busse mit niedriger Geschwindigkeit

In den letzten Jahren gab es eine starke Zunahme von seriellen Niedergeschwindigkeitsbussen, die in die Forschung und Entwicklung eintraten und als Endbenutzerprodukte auf den Markt kamen. Einige davon sind anwendungsspezifisch, wie FlexRay in der Automobilindustrie, während andere viele Märkte und Branchen umfassen und schon seit langem existieren, wie RS232 und UARTs. Neue Protokolle kommen ständig auf den Markt und bieten Produktdesignern und Endbenutzern mehr Funktionen, Leistung und Robustheit, aber auch neue Debug-Herausforderungen, um die Leistung und Interoperabilität zu validieren. Abbildung 1 ist ein Menü eines LeCroy-Oszilloskops, das einige Arten von seriellen Datensignalen mit niedrigerer Geschwindigkeit zeigt, die mit modernen digitalen Oszilloskopen erfasst, dekodiert und debuggt werden können.

Abbildung 1:

LeCroy-Oszilloskope können eine Vielzahl von seriellen Datenprotokollen mit niedriger Geschwindigkeit erfassen und decodieren

Einige serielle Niedergeschwindigkeitsbusse verwenden eine differenzielle Architektur, um die Immunität gegenüber Gleichtaktrauschen und Interferenzen zu erhöhen. Dies ist eine typische Praxis bei seriellen Hochgeschwindigkeitsbussen wie USB oder PCI Express, die geringere Spannungsschwankungen aufweisen und daher leichter durch Rauschen beeinträchtigt werden können. CAN ist ein Beispiel für einen differentiellen Bus mit niedriger Geschwindigkeit. Es verwendet differentielle Datenleitungen, wobei Sender und Empfänger mit der gleichen Bitrate arbeiten – siehe Abbildung 2.

Abbildung 2:

Ein Beispiel für ein serielles Datensignal, das differentiell gesendet wird

Ein differentiell kodiertes Signal kann extrahiert werden, indem entweder die internen mathematischen Fähigkeiten des Oszilloskops verwendet werden (Erfassen der beiden Seiten des differentiellen Signals in zwei Kanälen des Oszilloskops – dann Subtrahieren davon) oder indem eine differentielle Sonde verwendet wird, was die bevorzugte Methode ist.

Differenztastköpfe sind für die Erfassung von Differenzsignalen optimiert, indem sie zwei möglichst identische Signalpfade bereitstellen, die in Gesamtdämpfung, Frequenzgang und Zeitverzögerung aufeinander abgestimmt sind. Die beiden Pfade werden einem Differenzverstärker innerhalb der Sonde zugeführt, wodurch das Gleichtaktunterdrückungsverhältnis (CMRR) maximiert und das resultierende unsymmetrische Signal zur Analyse durch das Oszilloskop extrahiert wird.

Im Gegensatz dazu wäre ein Beispiel für einen seriellen Bus mit niedriger Geschwindigkeit, der keine differenzielle Signalisierung verwendet, I2C, das eine Zweidrahttopologie verwendet, die aus einer Datenleitung, SDA, und einer Taktleitung, SCL, besteht.

Zunächst würde die Erfassung und Fehlerbeseitigung eines seriellen Busses mit der Validierung der Signalintegrität oder Qualität der physikalischen Wellenformen vor der Protokollbeseitigung beginnen, da eine stabile und gültige physikalische Schicht für die Stabilität des Gesamtsystems von größter Bedeutung ist.

Nützliche Methoden zum Triggern und Erfassen von Fehlern im Takt- oder seriellen Datensignal sind die Glitch-, Runt-, Dropout- und Intervall-Triggerfunktionen des modernen Oszilloskops. Man kann auch Funktionen wie WaveScan verwenden, um auf nicht-monotone Flanken, Flanken mit Anstiegs-/Abfallzeiten, die außerhalb der Spezifikation des Protokolls liegen, und/oder andere Signalmerkmale, die gegen die Spezifikation verstoßen, zu triggern (oder in einer zuvor erfassten Wellenform zu lokalisieren). dem seriellen Datenstandard.

Die meisten Oszilloskopmarken bieten eine schnelle Triggermethode und die Verwendung einer Nachleuchtanzeige, um zu versuchen, Signalunregelmäßigkeiten zu erkennen. Aber Smart Triggering, wie in Abbildung 3, ist weitaus besser als die Verwendung des Persistenz- oder Schnellaktualisierungsmodus. Dies liegt daran, dass diese sogenannten Hochgeschwindigkeitserfassungsmodi immer noch eine beträchtliche Totzeit haben, die das Auftreten eines Fehlerzustands verpassen kann, insbesondere wenn dieser Zustand nur selten auftritt. Smart Trigger hält das Oszilloskop 100 % der Zeit aktiv (keine Totzeit), bis die nützlichen Daten auftreten und das Oszilloskop sie erfasst.

Außerdem erlauben viele der Schnellaktualisierungsmodi keine Kombination mit einem ausgeklügelten Triggermodus, wodurch der Benutzer mit einem einfachen Flankentrigger zurückbleibt, der beim Debuggen von Burst-gesteuerten seriellen Bussen praktisch nutzlos ist.

Andererseits überprüft ein Smart-Trigger jeden Zustand, der in das Oszilloskop gelangt, und hat keine Totzeit, da das Oszilloskop nicht triggert, bis die Fehlerbedingung erfüllt ist. Häufig bietet der Erfassungsmodus „Normal“ mit einem Smart-Trigger größere Triggermöglichkeiten, eine größere Erfassungsspeichertiefe und eine bessere Analysefähigkeit nach der Erfassung. Viele moderne Oszilloskope ermöglichen es auch, die erfasste Wellenformspur lokal im Oszilloskop zu speichern und den Trigger dann schnell neu zu aktivieren, um die Überwachung des Busses fortzusetzen. Diese Wellenformaufzeichnung kann bei Bedarf praktisch unbegrenzt fortgesetzt werden.

Einige Oszilloskope verfügen auch über intelligente Erfassungsmodi, die auch dann verwendet werden können, wenn die genaue Triggerbedingung unbekannt ist. In Abbildung 4 sehen wir, wie auf einem langen CAN-Bus-Trace nach einer Runt-Bedingung gesucht wird. Jedes Auftreten einer Runt-Bedingung stoppt das Oszilloskop und ermöglicht eine weitere Analyse. Die Tabelle links in Abbildung 4 zeigt 9 Runt-Vorkommen, die 4th Auftreten wird in der Tabelle hervorgehoben und im Zoomfenster (untere Kurve) detailliert dargestellt.

Abbildung 4:

Ein Runt-Trigger wird verwendet, um ein Signalintegritätsproblem in einem CAN-Signal zu finden. In der obersten Spur wird ein langer Datensatz erfasst. Es werden neun Fehler gefunden. Der vierte ist für eine detaillierte Betrachtung in der unteren Spur gezoomt

Die Möglichkeit, einen Smart-Trigger einzurichten, ist besonders nützlich, wenn man bedenkt, dass nicht nur Runt- und Non-Monoton-Bedingungen getestet werden können, sondern auch Arbeitszyklusvariationen, übermäßig schnelle oder langsame Anstiegs- und Abfallzeiten, Frequenz- und Periodenabweichung, positive und negative Breite Abweichungen und Zeitverschiebungsvariationen. Das Oszilloskop kann sogar nach übermäßigem Über- oder Unterschwingen suchen. Jeder dieser Triggertypen kann mit Suchfilteroptionen gekoppelt werden, siehe Abbildung 5, um umfassende Debug-Analysefähigkeiten zu bieten.

Abbildung 5:

Das Triggern auf Signalbedingungen wie z. B. Runts, Impulsbreiten, Frequenz, Anstiegs-/Abfallzeit, Signalausfall usw. kann durch eine Vielzahl von Benutzeroptionen numerisch gefiltert werden

Jedes serielle Datenprotokoll hat seine eigene Spezifikation, die Informationen über die physikalische Schicht und das Protokoll enthält. Die physikalische Schicht wird typischerweise durch die zulässige Toleranz von einem Ideal spezifiziert. Solche „Ideale“ und Toleranzen können für Bitratenvariationen, Daten-/Takt-Timing-Besonderheiten, erwartete Spannungspegel und für die Form des Signals eingestellt werden.

Die Oszilloskop-Maskenfunktion ist ein weiteres Werkzeug, das für die Validierung der physikalischen Schicht verwendet werden kann. In Abbildung 6 zeigt ein FlexRay-Beispiel ein Augendiagramm mit Maskenverletzungen, die durch rote Kreise markiert sind. Die Implikation ist, dass diese Signale nicht der FlexRay-Spezifikation entsprechen und daher nicht konform sind. Diese Probleme erfordern offensichtlich weitere Untersuchungen.

Abbildung 6:

Ein Augendiagrammtest der Form eines seriellen Datensignals – in diesem Fall Flexray

Jede Schaltung sollte von der Hardware-Phase an debuggt/validiert werden, bevor sie zur Protokoll-Debugging-/Validierungsphase übergeht, d. h. stellen Sie sicher, dass Ihr Design die physikalischen Spezifikationen wie Spannungspegel, Impulsdauer/Bitraten, Takt-/Datentiming usw. erfüllt. bevor Sie zum Debuggen der Protokollschicht übergehen.

Die Dekodierung des Spannungs-Zeit-Signals zur Durchführung einer Protokoll-Fehlerbeseitigung wird manchmal für unnötig gehalten. Ein Techniker könnte die (riskante) Annahme treffen, dass der Bus und die Komponenten, die von Siliziumanbietern bereitgestellt werden, alle ordnungsgemäß sind, da der Anbieter die Spezifikation versteht und eindeutig befolgt. Leider ist dies nicht immer der Fall.

Protokoll-Trigger- und -Decodierungsfunktionen sind normalerweise optionale Erweiterungen eines Oszilloskops. Auf einem einzelnen Oszilloskop können mehrere verschiedene Protokolldecodierungsoptionen installiert sein (wie in Abbildung 1 gezeigt), die es ermöglichen, es für die Busvalidierung in vielen verschiedenen Teilen des Designs zu verwenden oder mehrere Busse gleichzeitig zu decodieren (z. B. bei Verkehrslatenzmessungen zwischen Bussen). .

Das Triggern und Decodieren des Oszilloskopprotokolls kann mehrere Formen annehmen. Einige verwenden lediglich einen einfachen Flankentrigger und decodieren dann das Spannungs-Zeit-Signal, um dem Benutzer die decodierten Informationen anzuzeigen. Dies hat einen deutlichen Nachteil im Vergleich zum protokollbewussten Triggern, bei dem der Benutzer auf bestimmte Adress- oder Dateninformationen oder auf Fehlerbedingungen triggern kann. Das Auslösen einer Fehlerbedingung verbessert den gesamten Busvalidierungsprozess erheblich, da er einen Bus über lange Zeiträume oder unter unterschiedlichen Bedingungen auf der Suche nach einem auftretenden Fehler überwachen kann.

Die Protokolldecodierung durch verschiedene Oszilloskophersteller variiert ebenfalls erheblich. In Abbildung 7 sehen wir die protokollbewusste Triggerung, eine Dekodierungstabelle und die Wellenform selbst mit aktivierter farbkodierter Dekodierungsüberlagerung. Dies vereinfacht den gesamten Prozess des Verstehens der Ereignisse, die im Bus stattfinden.

Abbildung 7:

Ein Beispiel, das die Einrichtung der Triggerung auf einen bestimmten Bereich von Adresswerten zeigt. Das Oszilloskop löst das Signal aus und entschlüsselt es, wenn eine interessante Adresse auftritt.

Abbildung 8 zeigt ein Beispiel für die MIL-STD-1553-Fehlerauslöseoptionen und den daraus resultierenden erfassten Fehler. Diese Fehlerbedingung ist nun bereit für weitere Untersuchungen, um zu sehen, welche Ereignisse dazu geführt haben.

Abbildung 8:

Protokollbewusste Triggerung und Busdecodierung. In diesem Fall löst der Bereich bei Fehlerbedingungen aus

Zusammenfassung

Das Debuggen und Validieren von seriellen Bussen erfordert ein Verständnis des Busses selbst und seines Protokolls. Es gibt viele Tools, die helfen können. Die Qualität des Bussignals oder die Signalintegrität sollte immer der Ausgangspunkt sein, indem Tools wie ein Oszilloskop mit Smart Trigger und WaveScan verwendet werden, bevor zur Phase der Protokollvalidierung übergegangen wird. Weitere technische Hinweise und LAB-Briefings sind verfügbar, die weitere Einzelheiten zur Verwendung dieser Funktionen enthalten.

Viele Oszilloskope verfügen über Bus-Trigger- und Dekodierungsoptionen. Diese Debug-Tools haben den Vorteil, dass sie als Teil des Oszilloskops in Echtzeit ausgeführt werden, was zu einer höheren Effizienz bei der Fehlersuche und -validierung des seriellen Busses führt.