PHY-Layer-Tests in der Praxis „Ein bestandener Compliance-Test ersetzt keine Systemvalidierung“

Wann lohnt sich ein PHY-Layer-Test wirklich und wo hört Compliance auf? Jan Claes, Director Testing & Certification bei Bitifeye, erklärt im Gespräch, warum ein bestandener Standardtest allein keine Aussage über die Robustheit im Feld ermöglicht. Ein anonymisiertes Beispiel aus der Praxis verdeutlicht die Tücken der PHY-Abstimmung.

Mit steigenden Datenraten wachsen auch die Anforderungen an Leiterplatten, Steckverbinder und Transceiver. Das war der Ausgangspunkt eines Beitrags der ELEKTRONIKPRAXIS zu elektrischen Tests bei Schnittstellen wie PCIe und MIPI A-PHY. Bereits kleine Abweichungen der Impedanz, zusätzliche Dämpfung oder Jitter können die Übertragung beeinträchtigen, und die Ursachen liegen nicht nur im Transceiver selbst, sondern ebenso in Gehäuse, BGA-Übergängen, Vias, Leiterbahnen, Steckverbindern und der Gegenstelle.

BitifEye Digital Test Solutions aus Böblingen bietet PHY-Layer- und Compliance-Tests für PCIe und MIPI A-PHY an und ist nach eigenen Angaben das erste von der MIPI Alliance autorisierte Testlabor („Authorized Test Lab", ATL) für das A-PHY-Compliance-Programm. Dazu habe ich mit Jan Claes, Director Testing & Certification bei Bitifeye, vertiefend über die Praxis solcher Tests gesprochen.

Von der Simulation zum seriennahen Design

Nach Einschätzung von Claes sollte mit dem Testen so früh wie möglich begonnen werden. Bereits Kanal- und Signalintegritätssimulationen liefern wertvolle Informationen, noch bevor die erste Hardware verfügbar ist. Sie helfen dabei, potenzielle Probleme frühzeitig zu erkennen. Bei komplexeren Designs empfiehlt BitifEye, bereits mit den ersten Prototypen elektrische Messungen an Sender und Empfänger durchzuführen. Solche frühen Messungen sagen bereits viel über das grundlegende Design und dessen Machbarkeit aus. Bietet der Prototyp ausreichende Testmöglichkeiten, lassen sich anschließend Margen untersuchen oder elektrische Probleme gezielt eingrenzen.

Mit wachsendem Reifegrad des Designs werden eine umfassendere elektrische Validierung und Pre-Compliance-Tests wichtiger. Dann geht es nicht mehr nur um die Frage, ob die Datenverbindung grundsätzlich funktioniert, sondern darum, ob die Implementierung voraussichtlich die Anforderungen des jeweiligen Standards erfüllt. „Einen Fehler früh zu finden, ist fast immer einfacher und kostengünstiger, als ihn zu beheben, wenn das Produkt bereits im Feld ist“, sagt Claes.

Für die Reihenfolge empfiehlt er, sich in der frühen Entwicklungs- und Prototypenphase auf elektrische Tests beziehungsweise Tests auf PHY-Ebene zu konzentrieren. Sobald das elektrische Design stabiler ist, folgen Link-Layer- und Protokolltests. Interoperabilität wird relevant, sobald die komplette Hard- und Software vorliegt – gefolgt von formalen Compliance-Tests, sofern diese für das jeweilige Produkt vorgesehen sind.

Wenn nicht eine einzelne Komponente die Ursache ist

Für Probleme bei schnellen Datenschnittstellen gibt es laut Claes eine ganze Reihe möglicher Ursachen, und selten lässt sich die Schuld an einer einzelnen schlechten Komponente festmachen. Leiterplattenlayout, Steckverbinder, Terminierung, Spannungsversorgung oder Komponenten im Signalpfad können jeweils beitragen. Als Beispiel nennt er EMI-Komponenten, die für langsame Signale ausgelegt, aber den hohen Datenraten der tatsächlichen Anwendung nicht gewachsen sind. Ein weiteres häufiges Problem ist die Abstimmung des PHY-Frontends: Entwickler übernehmen mitunter Standardparameter oder Einstellungen aus einem Referenzdesign. Das kann funktionieren, aber je nach Kundenspezifikation sind abweichende Einstellungen für die Leiterplatte, die Komponenten oder den Kanal möglich.

Claes beschreibt dazu ein anonymisiertes Beispiel aus der Praxis: Ein Hersteller hatte ein Inspektionssystem für lange unterirdische Rohrleitungen entwickelt, das zunächst korrekt zu funktionieren schien. Nach einer bestimmten Betriebszeit oder Streckenlänge gingen jedoch Daten der Inspektion verloren, weil die Übertragung von der Kamera zum Speichersystem nicht mehr zuverlässig lief. Die Ursache ließ sich auf ein nicht korrekt abgestimmtes Controller-Board zurückführen, das die Funktion des Speichermediums beeinträchtigte.

Zu diesem Zeitpunkt war der Fehler bereits in mehreren Projekten aufgetreten, Geräte mussten zurückgerufen werden. „Das ist ein gutes Beispiel dafür, warum die Frage ‚Funktioniert der Link?' allein nicht ausreicht“, sagt Claes. „Man muss auch wissen, wie robust er unter den Bedingungen funktioniert, denen er später tatsächlich im Feld ausgesetzt ist.“

Kein einzelner Parameter entscheidet

Auf die Frage nach den kritischsten elektrischen Parametern bei PCIe oder MIPI A-PHY hält sich Claes bewusst zurück: Es lasse sich kein einzelner Parameter benennen, der immer am wichtigsten sei. Die Compliance-Programme definieren eine Reihe von Messungen, weil jede eine andere potenzielle Schwachstelle des Links adressiert. Wird allerdings eine davon ausgelassen, übersieht man womöglich genau die Bedingung, die später zu einem Problem führt.

In der Praxis kommt es deshalb darauf an, die Messungen im Zusammenspiel zu betrachten. Zufälliger und deterministischer Jitter, Kanalverluste und Reflexionen beeinflussen das Signal auf unterschiedliche Weise und lassen sich mit den entsprechenden elektrischen Messungen einzeln untersuchen. Sieht der Kanal selbst so aus wie erwartet, hat der Link aber trotzdem zu wenig Marge oder verhält sich anders als im Referenzdesign, rät Claes, die Einstellungen von Sender oder Empfänger genauer zu prüfen. Systematisches Testen hilft dabei, diese Ursachen voneinander zu unterscheiden: Statt mehrere Parameter so lange zu verändern, bis der Link funktioniert, werden die Bedingungen kontrolliert variiert und die Reaktion des Prüflings beobachtet. So lässt sich leichter erkennen, an welcher Stelle die verfügbare Marge verloren geht.

Compliance ist keine Systemvalidierung

Claes unterscheidet deutlich zwischen Compliance-Tests und einer Validierung auf Systemebene. Ein Compliance-Test prüft unter definierten, bewusst begrenzten Testbedingungen, ob eine Implementierung die Anforderungen eines Standards erfüllt. Andernfalls würden solche Tests schnell zu komplex, zeitaufwendig und teuer werden. Das bedeutet zugleich, dass ein Compliance-Test nicht zwangsläufig jede Bedingung abdeckt, der ein Produkt in der realen Anwendung ausgesetzt ist. Sämtliche Temperaturgrenzbereiche, Schwankungen der Versorgungsspannung oder unterschiedliche reale Lastbedingungen zu testen, sei zudem nicht für jedes Produkt gleichermaßen relevant.

Bei BitifEye versteht man Compliance deshalb als wichtige Basis, nicht als Ersatz für die Systemvalidierung. Der zusätzliche Testumfang sollte sich am tatsächlichen Anwendungsfall und dem damit verbundenen Risiko orientieren: Muss ein Produkt über einen großen Temperaturbereich, bei schwankender Versorgungsspannung oder in einer besonders anspruchsvollen Umgebung arbeiten, sollten diese Bedingungen fester Bestandteil der Validierungsstrategie sein. Als weitere Ebene kommt die Interoperabilität hinzu: Auch wenn zwei Geräte einzeln denselben Standard erfüllen, lässt sich daraus nicht automatisch ableiten, wie sich das Gesamtsystem verhält, wenn reale Geräte unterschiedlicher Hersteller zusammenarbeiten.

Wann ein externes Labor sinnvoll ist

Für eine frühe Validierung sind die Anforderungen nach Einschätzung von Claes überschaubar: Bei einem frühen Prototyp braucht es vor allem die für Board-Bring-up und Tests erforderliche Ausrüstung sowie grundlegende Informationen zum Design. Ein Entwickler, der das Design gut kennt und bei Bedarf unterstützen kann, macht das Debugging deutlich effizienter.

Interne Pre-Compliance-Tests seien sehr wertvoll, hätten in der Praxis aber zwei Grenzen. Die erste betrifft die Ressourcen: Fachwissen, Testequipment, Zubehör und ausreichend Entwicklungszeit müssen vorhanden sein. Die zweite ist eine gewisse Voreingenommenheit. Denn wer ein selbst entwickeltes Produkt testet, hat im Hinterkopf oft den Gedanken „Es sollte funktionieren, schließlich habe ich es entwickelt“.

Ein externes Testlabor bringe hingegen einen unabhängigen Blick mit. Frühes Debugging und Pre-Compliance ließen sich häufig intern durchführen, wenn Know-how und Equipment vorhanden sind; für formale Compliance-Tests kann je nach Standard und Compliance-Programm dagegen ein autorisiertes oder zertifiziertes Testlabor erforderlich sein.

Claes rät bei der Auswahl eines Testpartners, über die reine Equipment-Liste hinauszublicken. Erfahrung mit dem jeweiligen Standard, die Einbindung in das entsprechende Compliance-Umfeld und die Fähigkeit, beim Debugging zu unterstützen, wenn ein Test fehlschlägt, seien mindestens ebenso wichtig. „Ein guter Testpartner sollte nicht nur mitteilen, dass etwas nicht funktioniert, sondern auch dabei helfen, die Gründe dafür zu verstehen.“ (heh)

Fehler im Physical Layer

Einen PHY-Layer-Test frühzeitig bei der Entwicklung einplanen

(ID:50967368)