Oszilloskope
8b/10b-Code mit dem Scope analysieren
Fortsetzung des Artikels von Teil 1
Erfassung bestimmter Datenwerte
Um Protokollfehler im Datenstrom zu finden, wird häufig nach einem bestimmten Zeichen in der Protokolltabelle gesucht. Allerdings handelt es sich dabei um ein Verfahren, das im Anschluss an die Erfassung erfolgt und somit auf einen Zeitrahmen beschränkt ist, der durch die Größe des Erfassungsspeichers bestimmt ist. Die Totzeit zwischen den Erfassungsvorgängen ist verhältnismäßig lang und ergibt sich einerseits durch das Oszilloskop und andererseits aus der Zeit, die die Software zum Verarbeiten des Signals in das Binärformat und anschließend zum Suchen nach dem jeweiligen Zeichen benötigt. Dieser Zusammenhang ist in Bild 6 dargestellt.
Jobangebote+ passend zum Thema
Demnach ist die Wahrscheinlichkeit, unregelmäßige und selten auftretende Fehler zu erfassen, sehr gering. So wird die Echtzeiterfassung beispielsweise bei einer Abtastung von 10 Millionen Punkten und 50 GS/s nach 200 μs gestoppt. Bevor das System den nächsten Block mit 10 Millionen Punkten erfassen kann, vergehen zunächst einige hundert Millisekunden. Mit einem größeren Speicher wird dieses Problem sogar noch verstärkt. Um seltene Ereignisse zu finden, muss das Triggern auf solche Fehler erfolgen.
Die meisten digitalen Oszilloskope verfügen über eine große Auswahl an Triggerfunktionen. Üblicherweise ist dabei die Fehlerdiagnose mit dem zeit- und pegelqualifizierten Triggern verknüpft. Angesichts der modernen Triggermöglichkeiten gestaltet sich das Triggern auf Glitches, Transitions, Runts usw. viel einfacher als in der Vergangenheit. So kann es sich bei Protokollfehlern als hilfreich erweisen, auf Befehle, Zeichen oder Bitsequenzen zu triggern. Leider können mit einer seriellen Triggerschaltung, die für NRZ-Muster entwickelt wurde, derartige Fehler nicht gefunden werden, da der Großteil der seriellen Hochgeschwindigkeitsdatensignale 8b/10b-codiert sind und eine dedizierte Hardware-Lösung erfordern.
Ein standardmäßiger NRZ-Trigger kann aus zwei Gründen nicht auf Wörter von 8b/10b-codierten Datenströmen triggern: Erstens ändert sich die Codierung des 8-bit-Wortes in ein 10-bit-Symbol mit der Geschwindigkeit der Datenrate und würde eine Anpassung der Symbolrate im Triggerspeicher an die gleiche Geschwindigkeit erfordern.
Zweitens setzt die Triggerung auf das richtige 8b/10b-Symbol eine Synchronisierung oder Ausrichtung der 8b/10b-Codes mit dem Datenstrom voraus. Für die Echtzeit-Triggerung muss die Hardware in der Lage sein, eines der „Kommasymbole“ (K.28.1, K.28.5 und K.28.7) zu synchronisieren. Diese Symbole sind eindeutig und können an keiner Bitposition im codierten Datenstrom gefunden werden. Das Synchronisierungszeichen kann sich irgendwo im Datenstrom befinden und tritt möglicherweise sehr selten oder nur ein einziges Mal auf. Ein Beispiel für ein Synchronisierungszeichen ist das Kommasymbol K.28.5 (011110101). Nachdem das Ausrichtungssymbol gefunden wurde, kann die Decodierung der nachfolgenden Symbolwerte fortgesetzt werden.
Software-Lösungen für die Triggerung durchsuchen die erfassten Daten und haben deshalb lange Totzeiten. Diese verursachen sehr große Lücken zwischen den Erfassungsvorgängen und verringern die Wahrscheinlichkeit, dass das gesuchte Zeichen gefunden wird.
Viele höherwertige Oszilloskope sind mit einem speziellen Trigger-Chip ausgestattet, mit dem auf 8b/10b-Datenmuster in seriellen Hochgeschwindigkeitssignalen von bis zu 6,25 Gbit/s getriggert werden kann. Dadurch kann das Gerät auch seltene Ereignisse finden, da so das Triggern auf 8b/10b-Zeichen ermöglicht wird. Zeichen sind Akronyme für ein 10-bit-Muster des 8b/10b-Codes, z.B. D.31.6 oder K.28.5. Eine zweite Option in Bezug auf das Protokoll eines seriellen Hochgeschwindigkeitsstandards ist die Triggerung auf 8b/10b-Wörter (Befehle), bei denen die Wörter aus mehreren Zeichen (im allgemeinen 4 Wörter oder 40 Bits) bestehen. Beachtet werden sollte, dass jeder Standard über seine eigenen Wort-Definitionen verfügt.
Ein Tool zur Fehlerbehebung ist dann wirklich leistungsstark, wenn es auf 8b/10b-Codefehler triggern kann. Zwar wäre kein serieller Trigger jemals in der Lage, auf alle möglichen speziellen Zeichenfehler, Disparitätsfehler oder Verluste der Bytesynchronisierung zu triggern; das Triggern auf allgemeine Fehler wie Disparitäts- oder Zeichenfehler ist in der Regel aber schon möglich.
Verzögerungsmessung bei Netzwerkelementen
Ein Anwendungsbeispiel für das Triggern auf serielle 8b/10b-Muster ist das Messen der zeitlichen Verzögerung eines aktiven Netzwerkelements. Es wäre anzunehmen, dies sei auch ohne das spezielle Triggern auf 8b/10b-Codes eine leichte Aufgabe. Doch kann es auch zu einer Herausforderung werden, wenn nämlich die zeitliche Verzögerung unter realen Bedingungen gemessen werden soll.
Der zugehörige Messaufbau ist in Bild 7 zu sehen. Das Eingangssignal des Netzwerkelements ist an Kanal 1 angeschlossen, während der Ausgangsdatenstrom mit Kanal 2 des Oszilloskops verbunden ist. Ein Datengenerator liefert dem Eingang des Netzwerkelements (Prüfling) den erforderlichen Datenstrom, innerhalb dessen ein eindeutiges Muster als Zeitreferenz dient. Diese Referenz muss ein sehr seltenes Muster sein, damit keine Verwechslungsmöglichkeit mit anderen zeitlichen Bezugspunkten besteht. Nachdem das Muster festgelegt wurde, kann im erfassten Signal von Kanal 1 und Kanal 2 nach ihm gesucht und anschließend die Zeit zwischen den beiden Punkten gemessen werden.
Für die Suche nach der Sequenz im Datenstrom könnte eine in die Software integrierte Decodierfunktion hilfreich sein, da sich die Suche nach dem Muster aufgrund seiner Seltenheit als recht schwierig erweisen kann. Angesichts des begrenzten Erfassungsspeichers von Oszilloskopen ist die Wahrscheinlichkeit, das Muster für die Zeitreferenz zu finden, recht gering. Anders als bei der Suche ist das 8b/10b-Triggern zum Auffinden der Sequenz viel erfolgversprechender. Das liegt daran, dass beim Triggern sichergestellt ist, dass sich das Muster auf jeden Fall im Erfassungsfenster befindet.
Ohne die Möglichkeit des 8b/10b-Triggerns würde für die Verzögerungsmessung ein Triggersignal vom Datengenerator zum Oszilloskop erforderlich sein. Nur so könnte dann der Ausgangspunkt der 8b/10b-Zeitreferenz am Ausgang des Datengenerators mit dem Erfassungsfenster des Oszilloskops synchronisiert werden. Ein solcher Aufbau entspricht jedoch in keiner Weise realen Bedingungen.
In dem in Bild 7 gezeigten Aufbau sind die beiden Netzwerkelemente über eine bidirektionale Verbindung miteinander verbunden. Netzwerkelement A fungiert dabei als Datenquelle und sorgt dafür, dass Netzwerkelement B (der Prüfling) im gewünschten Betriebsmodus läuft. Die Kommunikationsverbindung muss nun durch proprietäre Befehle hergestellt werden. Der dadurch ausgelöste Datenstrom muss während der Messung aufrechterhalten werden, damit der Prüfling weiterhin im gewünschten Betriebsmodus läuft. Ein von einem Datengenerator erzeugtes statisches Datenmuster ist demnach für diese Aufgabe ungeeignet.
Ähnlich wie bei dem vorigen Beispiel ist auch hier ein eindeutiges Muster als Zeitreferenz (Markierung) im Datenstrom erforderlich. Da das Muster nur sehr selten auftritt und kein Triggersignal von dem als Quelle fungierenden Netzwerkelement A zur Verfügung steht, ist ein 8b/10b-Trigger erforderlich, um das Muster im Eingangs- und Ausgangssignal des Prüflings zu ermitteln.
Die beste Möglichkeit, die Verzögerung zwischen dem Eingang und dem Ausgang des Netzwerk-elements zu erkennen und zu messen, ist die Verwendung zweier Zoom-Fenster. Das erste der beiden Fenster wird an den Anfang der Mustersequenz an Kanal 1 platziert, das zweite analog dazu an den Anfang der Mustersequenz an Kanal 2. Für die Verzögerungsmessung sollte das Erfassungszeitfenster des Oszilloskops mindestens so groß wie die Verzögerungszeit sein.
Letztlich können Messgeräte (Oszilloskope) mit Funktionen, die speziell für das Prüfen serieller Busse konzipiert wurden - wie etwa das Triggern auf oder das Decodieren serieller Daten - maßgeblich die Produktivität von Ingenieuren erhöhen, wie hier gezeigt wurde, und die Entwicklung zuverlässigerer und höherwertiger Designs vorantreiben.
Der Autor
| Dean Miles |
|---|
| ist als Senior Technical Marketing Manager bei Tektronix für das High Performance Product Portfolio zuständig. In seinen über 20 Jahren Unternehmenszugehörigkeit hat Miles verschiedene Positionen bei Tektronix durchlaufen, so z. B. als Global Business Development Manager für Tektronix RF Technologies oder als Business Development Manager für den Tektronix-Geschäftsbereich Optische Systeme. Miles hat in weltweit über 80 Ländern die Technologien von Tektronix bekannt gemacht und sich dabei mit mehr als 10.000 Ingenieuren ausgetauscht. |
- 8b/10b-Code mit dem Scope analysieren
- Erfassung bestimmter Datenwerte
Lesen Sie mehr zum Thema
