Home
Fehlersuche in Digitalsystemen
Busübergreifende Fehlerdiagnose macht Logikabläufe auf mehreren Bussen gleichzeitig sichtbar
02.04.2008 | Autor: Dave Ireland*
Ein Fehler in einem Bus kann seinen Ursprung - und seine Auswirkungen - in mehreren Bussen im System haben. Integrierte Instrumente sind in der Lage, serielle, parallele und sogar analoge Ereignisse zeitkorreliert auf einen einzigen Logikanalysator auszugeben. Sie erleichtern die Ursachenforschung und decken Wechselwirkungen auf.
 |
Drei Konzepte für das Aufzeigen der Logikabläufe
Diese Entwicklung steigert die Nachfrage nach busübergreifenden Fehlerdiagnoselösungen, die auf einfache, integrierte Weise die Logikabläufe auf mehreren unterschiedlichen Bussen gleichzeitig sichtbar machen. Hierfür gibt es mehrere Konzepte.
Der klassische Ansatz kombiniert einen standardspezifischen Protokollanalysator mit einem Logikanalysator (LA). Ersterer kümmert sich um die serielle Erfassung, während der LA parallele Busdaten aufzeichnet, die für das jeweilige Problem relevant sein können.
Ein alternativer Ansatz besteht darin, einen LA zusammen mit einem Bus-Supportpaket zu verwenden, das eine externe Schnittstelle zur Umwandlung der seriellen Daten in die vom Logikanalysator verwendeten parallelen Daten beinhaltet.
Eine dritte Methode wurde von Tektronix entwickelt: Die Logikanalysatoren der Serie TLA7000 können mit integrierten seriellen PCI-Express-Erfassungsmodulen ausgerüstet werden, die sich genau wie die parallelen Versionen direkt an das LA-Mainframe anschließen lassen. Serielle und parallele Erfassungsmodule können innerhalb eines Systems gemischt werden. Mit dieser seriellen Unterstützung ist die Serie in der Lage, parallele und serielle Daten ebenso wie Analogsignale von einem Oszilloskop zu erfassen und auf dem LA-Bildschirm zeitkorreliert darzustellen. Das vereinfacht die Fehlersuche in digitalen Systemen. Durch den Einsatz serieller und paralleler PCI- Express-Module können mit einem einzigen Logikanalysator busübergreifende Analysen durchgeführt werden.
Digitale Lösungen beginnen mit einer Diagnose der analogen Elemente
Die zugrunde liegende Architektur einer seriellen PCI-Express-Verbindung ist bekannt. Ein PCI-Express-Sender mit einem SerDes (Serializer-Deserializer) als Kernstück - häufig als Element innerhalb eines FPGA eingebettet - sendet 8B10B-kodierte Daten an einen Empfänger, der sich an einem anderen Punkt im System befindet. Die Impedanzen, Bitraten und Takteigenschaften bei der Übertragung sind genau festgelegt und werden kontrolliert, um Kompatibilität zwischen den PCI-Express-Komponenten unterschiedlicher Hersteller zu gewährleisten.
Ergänzendes zum Thema
Bei der Diagnose nicht auf einen Bus beschränken
Obwohl es sich bei dieser Verbindung um ein digitales System handelt, können Fehler darin sowohl digitalen als auch analogen Ursprungs sein. Häufig besteht der erste Schritt in der Fehlerdiagnose darin, eine Momentaufnahme der analogen Signale zum Fehlerzeitpunkt zu machen. Einige Logikanalysatoren verfügen über Funktionen, mit denen sie analog erfasste Daten (Signale) des angeschlossenen Oszilloskops in die digitale LA-Darstellung einbinden können. Die analogen Kurven werden zeitlich in Beziehung zu ihren digitalen Gegenstücken gesetzt. Dadurch lassen sich analoge Ereignisse wie Glitches und Runt-Impulse gleichzeitig mit den digitalen Ereignissen betrachten. Parallele Daten des Debug-Ports ermöglichen eine andere Sicht auf die Aktivität der seriellen Verbindung.
Integrierter Debug-Port liefert gerätespezifische Echtzeitdaten
Die PCI-Express-Sender-/Empfängerpaare, wie sie üblicherweise in der Unterhaltungselektronik, Telekommunikation verwendet werden, haben neben der seriellen Verbindung einen integrierten Debug-Port. Dieser parallele Ausgang liefert Echtzeitdaten, welche die Vorgänge innerhalb des Gerätes zusammenfassen. Wenn sowohl Sender als auch Empfänger über einen Debug-Port verfügen, können Entwickler den Zustand der Verbindungsleitung überwachen.
Bild 2 zeigt eine State Machine, die innerhalb eines seriellen PCI-Express-Empfängers realisiert sein könnte. Die vereinfachten Interaktionen symbolisieren eine normale Verbindungsprozedur und die schwarzen Pfeile markieren die zulässigen Statusübergänge.
Bild 3 zeigt ein Blockdiagramm, das die Prüfanordnung für die serielle PCI-Express-Verbindung und die zugehörigen State Machines auf Sender- und Empfängerseite zeigt. Angenommen, es handelt sich um eine Fehlersuchroutine, die den Ursprung verstümmelter Daten an der seriellen Verbindung ermitteln soll. Die Debug-Ports sind an ein paralleles Erfassungsmodul angeschlossen, die PCI-Express-Verbindung an ein serielles Modul.
Die Bildschirmdarstellung der LA-Erfassung zeigt das Bild 4. Der vom Debug-Port des Empfängers erfasste parallele Datenstrom wurde hinzugefügt. Der neue LA-Kurvenzug für die Busform hat die Hexadezimalwerte aus dem Diagramm der State Machine (unteres Signal) übernommen. Bei beiden Busform-Envelopes soll der Punkt betrachtet werden, an dem sie von der roten Cursorlinie gekreuzt werden. An dieser Stelle geht die Verbindung in den Overflow-Status (001). Hier stimmt etwas nicht: Die Routine ist direkt vom Idle- in den Overflow-Status gesprungen, was unmöglich ist, wenn die State Machine ihre Anweisungen ordnungsgemäß abarbeitet. Der graue Pfeil in Bild 2 weist auf diesen Fehler-Schritt hin.Latenzzeit wird genau widergespiegelt
Alle drei Kurvenzüge in Bild 4 sind durch die eng integrierten seriellen und parallelen Erfassungsmodule, die innerhalb des gleichen Logikanalysator-Mainframes arbeiten, zeitkorreliert dargestellt. Teilweise tritt der Statuswechsel des seriellen Busses hinter den Ausgangsdaten des Debug-Ports auf. Ursache der Verzögerung ist die Latenzzeit, die der serielle Puffer nach der Statusänderung benötigt, um seinen Inhalt zu leeren. In solchen Fällen wird die Latenz als Zeitdifferenz in der busübergreifenden Darstellung genau widergespiegelt.
In Bild 4 ist der Verkehr am seriellen Bus so dicht, dass einzelne Zyklen mit der aktuellen Auflösung nicht dargestellt werden können. Es ist aber klar ersichtlich, dass der gelbe Teil des seriellen Kurvenzugs mit dem 001-Status des Kurvenzugs der State Machine zusammenfällt. Der blaue Teil der Timingwerte der seriellen Kurve entsprechen genau dem E81-Idle-Status am Debug-Port. Die Verbindung ist funktionsfähig und kommuniziert, befolgt aber nicht die vorgesehene Routine.
Da die seriellen Datenfehler mit dem Overflow-Status am Debug-Port zusammenfallen und die seriellen Daten vom SerDes gesteuert werden, ist die Schlussfolgerung zulässig, dass hier ein Timing-Problem vorliegt, dessen Ursprung innerhalb des SerDes zu suchen ist. An dieser Stelle können mehrere Fehlersuchstrategien in Frage kommen, die von architekturspezifischen Überlegungen und anderen Debugging-Ergebnissen beeinflusst werden.
Gewünschte Funktionen werden synthetisiert
Im Regelfall sind die hier beschriebenen seriellen Verbindungselemente in einen FPGA integriert. Diese Bausteine verwandeln sich ausschließlich durch Konfiguration grundlegender logischer Funktionen in die vom Programmierer definierte Schaltung. Dieser Vorgang wird als Synthese bezeichnet, da die gewünschten Funktionen mithilfe interner Schalter synthetisiert werden. Mit diesem Wissen wird ein Entwickler bei der Fehlersuche zuerst die Ergebnisse der FPGA-Synthese überprüfen, um sicherzugehen, dass alle Übergänge der State Machine korrekt implementiert sind.
Falls das nicht die Fehlerursache ist, werden andere Signale an den Debug-Anschluss geleitet, um das Verhalten des Bauelements abzubilden. Nach Auswertung der Current-State-Daten, könnte der FPGA so programmiert werden, dass die Next-State-Daten an den Debug-Port ausgegeben werden. Das könnte Probleme aufzeigen, die im Current State nicht zu sehen sind, und natürlich gibt es noch viele weitere Zustände, die näher untersucht werden könnten.*Dave Ireland ist Marketingleiter Design & Manufacturing für die EMEA-Region bei Tektronix in Beaverton.
Artikel versenden
Druckversion
Artikel als PDF
Meine ELEKTRONIKPRAXIS
zum Login