Die Betriebsreserve des Kanals ist gar nicht so schlecht

Jason J. Ellison
|  Erstellt: Februar 21, 2019  |  Aktualisiert am: November 9, 2020
Die Betriebsreserve des Kanals ist gar nicht so schlecht

Was ist COM überhaupt?

Channel Operating Margin, kurz COM, ist nicht besonders gut verstanden. Und weil es nicht gut verstanden wird, zweifeln viele daran, dass es überhaupt etwas aussagt. Schließlich: Wie kann die Qualität eines Kanals durch nur eine einzige Zahl in Dezibel dargestellt werden? Tatsächlich ist COM der jüngste Entwicklungsschritt in einer langen Reihe von Kanalvalidierungstechniken auf Basis von Augendiagrammen. Dieser Blog verfolgt die Entwicklung von COM bis zu ihren Ursprüngen zurück und gibt der berüchtigten COM-Kennzahl eine greifbare Bedeutung.

Die erste Channel Operating Margin: Augendiagramme

Beginnen wir mit Augendiagrammen. Augendiagramme sind eine Möglichkeit, einen langen seriellen Datenstrom zu betrachten. Lange vor Keysight ADS und PyBERT wurde ein Augendiagramm mit einem digitalen Abtastoszilloskop oder einem Echtzeit-Oszilloskop gemessen. Im Fenster des Augendiagramms ist die y-Achse in Spannung und die x-Achse in Zeit über zwei Unit Intervals dargestellt. Ein Unit Interval, kurz UI, ist die Zeit, die ein Bit zum Durchlaufen benötigt. Innerhalb von zwei UI kann man also ein Datenbit mittig auf dem Bildschirm platzieren, mit einer halben Bitbreite Reserve auf jeder Seite. Statt jedoch nur ein einzelnes Bit zu betrachten, werden alle Bits nacheinander übereinandergelegt, bis der gesamte serielle Datenstrom auf dem Bildschirm sichtbar ist. Die Signalqualität wird durch die Größe der Öffnung in der Mitte quantifiziert. Wenn das Augendiagramm besonders gut aussieht, hört man Ingenieure manchmal sagen: „Da kann man einen Lkw durch dieses Auge fahren!“ Die gebräuchlichsten Größen zur Quantifizierung der Öffnung sind Breite, Höhe oder Fläche. Der Kreuzungspunkt des Auges am DC-Punkt entspricht dem Jitter, und dieser wird typischerweise statistisch mit einem Histogramm gemessen.

Abbildung 1. Beispiel eines seriellen Bitstroms.

Frühe Kanalspezifikationen und in manchen Fällen auch Spezifikationen für passive Komponenten verwendeten für die Pass/Fail-Bewertung eine sogenannte Eye Mask. Eine Eye Mask ist in der Regel ein rautenförmiger Bereich, der durch Augenbreite und Augenhöhe definiert ist. Ein Augendiagramm besteht die Prüfung, wenn sich nur eine begrenzte Anzahl erkannter Samples oder Treffer innerhalb der Eye Mask befindet. Die Muster aus Einsen und Nullen werden durch den Standard vorgegeben und sind üblicherweise Pseudo-Random-Bit-Sequence- oder PRBS-Muster. Im Wesentlichen lassen sich diese Muster in zwei Kategorien einteilen: vor 10 Gb/s und nach 10 Gb/s. Vor 10 Gb/s wurde in den meisten Systemen eine 8b10b-Codierung verwendet, und PRBS 7 war das passende Muster. Als 10 Gb/s durch die IEEE in 802.3ba eingeführt wurde, wechselte die Codierung zu einem 64b66b-Scrambler, und PRBS 31 setzte sich durch. Selbst heute bei 112 Gb/s ist PRBS 31 oder QPRBS 31 noch immer das Standardmuster, das die meisten verwenden.  

Statistisch betrachtet

Chronologisch gesehen ist StatEye nach den gemessenen Augendiagrammen die nächste Methode zur Qualifizierung passiver Kanäle, und sie wurde stark vom OIF genutzt. Die Idee hinter StatEye wird hier ausführlich erklärt. Kurz gesagt sagt StatEye Augendiagramme anhand der Pulsantwort eines Systems voraus. Eine Pulsantwort ist die Zeitbereichsantwort eines Systems, das mit einem rechteckigen Puls von einer UI angeregt wird; das System ist dabei ein passiver Kanal einschließlich Entzerrung. Die in StatEye verfügbaren Entzerrungstechnologien sind FFE, CTLA und DFE. Die Übertragungsfunktion eines Systems wird aus S-Parametern gewonnen. Da sich Kanal-S-Parameter simulieren lassen, ist StatEye eine effiziente Methode, viele Kanäle und Entzerrungseinstellungen auszuprobieren, um zu sehen, was funktioniert. Dabei bleibt die Eye Mask das Pass/Fail-Kriterium, basierend auf der statistisch vorhergesagten Augenöffnung.

Irgendwo zwischen StatEye und COM wurde die Peak Distortion Analysis (PDA) einigermaßen verbreitet. Die Methode ist von Heck und Hall in Advanced Signal Integrity for High Speed Digital Designs gut dokumentiert. Zusammengefasst verwendet sie dieselbe Pulsantwort wie StatEye, aber ihr Ergebnis ist einfach die sogenannte Worst-Case-Augenöffnung. PDA erfindet keine Daten, und genau deshalb gefällt sie mir persönlich. Ich habe sie selbst implementiert und festgestellt, dass PDA Worst-Case-Augendiagramme mit hoher Zuverlässigkeit vorhersagt. Allerdings berücksichtigen PDA und StatEye nicht den Einfluss von Sender und Empfänger im Kanal, und die beste Entzerrungseinstellung muss man manuell finden.

Abbildung 2: Beispiel eines Augendiagramms in Blau und PDA als schwarze gestrichelte Linie.

COM betritt die Bühne

COM wurde im Rahmen von IEEE 802.3bj, 100GBASE Ethernet, entwickelt und ergänzte den simulierten Kanal um die Unvollkommenheiten der ICs. Es ist einfacher zu verwenden und weiter verbreitet als StatEye und heute de facto das Werkzeug zur Vorhersage der Kanalqualität. Wie bereits erwähnt, baut COM auf StatEye auf und fügt mehrere neue Rauschquellen hinzu. Konkret sind dies Verluste aus dem IC, Reflexionen im IC-Gehäuse, IC-bezogener Jitter sowie eine zusammengefasste gaußsche Rauschquelle für alles andere, was im IC passiert, etwa Übersprechen. Die Implementierung von COM findet sich in IEEE 802.3 Annex 93A.

Der Großteil der Mathematik hinter COM wurde vom Standardisierungsgremium so weit wie möglich vereinfacht. So wird beispielsweise die Verkettung von S-Parametern auf Algebra reduziert, statt Umwandlungen von S-Parametern in ABCD-Parameter oder T-Parameter und anschließender Matrixmultiplikation zu verwenden. Die schwierigste Gleichung ist die Berechnung der Wahrscheinlichkeitsdichtefunktion (PDF) des ISI-bedingten Rauschens, aber nach ein paar Versuchen ist sie eigentlich gar nicht so schlimm. Einige Auslassungen gelten als implementierungsspezifisch, etwa wie sichergestellt wird, dass innerhalb jeder UI von Daten 32 Abtastpunkte vorhanden sind; diese Details finden sich jedoch im frei verfügbaren Open-Source-Code der IEEE.

COM ermittelt für einen gegebenen Kanal das Best-Case-Szenario anhand eines Satzes möglicher Entzerrungseinstellungen. Dazu werden alle Entzerrungseinstellungen durchlaufen und eine sogenannte Figure of Merit (FOM) berechnet. Die Entzerrungseinstellung, die die beste FOM liefert, wird für den Rest der Berechnungen verwendet. Sobald die PDFs aller Rauschquellen berechnet sind, wird das Rauschen bei einer erkannten Fehlerrate (DER) bestimmt. Die DER ist die gewünschte Bitfehlerrate (BER) für das System und wird dadurch festgelegt, welche Forward Error Correction (FEC)-Technik gegebenenfalls betrachtet wird. Das verfügbare Signal wird durch die Spannung der Pulsantwort an einem bestimmten Abtastpunkt bestimmt. Das verfügbare Signal wird durch das Rauschen bei der erkannten Fehlerrate geteilt (Signal-Rausch-Verhältnis), und diese Zahl wird in Dezibel umgerechnet. Voilà! COM! Siehst du, es hat tatsächlich eine Bedeutung. 

Die für COM verwendeten Einstellungen werden durch die verfügbare IC-Technologie bestimmt. Auf das Niveau der IC-Technologie einigen sich Branchenführer wie Intel, Broadcom, Mellanox, Fujitsu und viele andere. Mit anderen Worten: Ein IC, das die in COM abgebildete Technologie verwendet, sollte in funktionierenden Kanälen so arbeiten können, wie COM es vorhersagt. Das ist natürlich sehr leistungsfähig, denn der Standard hat nun (endlich) einen Teil der Verantwortung für den Kanal auf die IC-Anbieter verlagert.

Auch wenn COM wie eine Art Utopie der Kanalvorhersage klingt, hat es doch Einschränkungen. Da es sich um einen einzigen Satz von Einstellungen für alle vom Standard betrachteten Systeme handelt, sagt es die Leistung eines einzelnen ICs nicht für sich allein voraus. Um eine Korrelation mit Messungen zu erhalten, müssen die COM-Einstellungen für jedes einzelne IC angepasst werden. Außerdem vernachlässigt COM jeden Rauschbeitrag durch Skew. Glücklicherweise behandelt ein DesignCon-Paper von Jason Chan genau dieses Defizit, und ich hoffe, künftig aktualisierte COM-Skripte zu sehen, die seine Ideen nutzen.

Fazit

Kurz gesagt: COM ist gar nicht so schlecht. Es ist ein sehr logischer nächster Schritt in der Entwicklung der Kanalanalyse und macht die Bewertung von Kanälen vergleichsweise einfach. Ich bin sehr dankbar, dass die Autoren von COM so freundlich waren, den MATLAB-Code frei zu veröffentlichen und zu unterstützen. Ich hoffe, dass COM künftig von weiteren Signal-Integrity-Ingenieuren implementiert und verbessert wird. Wer weiß, vielleicht sehen wir eines Tages sogar eine Python- oder Octave-Implementierung.

Übersetzen Sie Kanalanalysen wie COM in klarere Designentscheidungen, auf die Sie sich verlassen können. Altium Develop hilft Ingenieuren dabei, Signal-Integrity-Absichten, Designänderungen und Reviews mit dem aktiven Design zu verknüpfen, sodass Analyseergebnisse ohne zusätzliche Reibung im Workflow in Layout und Freigabe einfließen. Starten Sie noch heute mit Altium Develop → 

Alle Abbildungen wurden mit GNU Octave erstellt.

Über den Autor / über die Autorin

Über den Autor / über die Autorin

Jason J. Ellison hat im Dezember 2017 seinen Master of Science in Elektrotechnik an der Penn State University absolviert.Er ist als Ingenieur für Signalintegrität tätig und entwickelt High-Speed-Verbindungen, Laborautomatisierungs- und Kalibriertechnik. Er ist besonders an Themen wie der Signalintegrität, Power-Integrität und dem Design von eingebetteten Systemen interessiert. Außerdem schreibt er Fachpublikationen für Zeitschriften wie „The Signal Integrity Journal”.
Mr. Ellison ist aktives IEEE-Mitglied und Mitglied des DesignCon Programmkomitees.

Ähnliche Resourcen

Verwandte technische Dokumentation

Zur Startseite
Thank you, you are now subscribed to updates.