Debugging heute
Die Krux mit den Käfern
Fortsetzung des Artikels von Teil 3
Fehler erst nach vielen Zyklen
Heterogene Multicore-SoCs bringen eine Vielzahl von häufig subtilen aber zerstörerischen Fehlern mit sich. Unerwartete Interaktionen zwischen mehreren Ausführungseinheiten resultieren in Buskonflikten und Bandbreitenproblemen. Für den Anwender macht sich dies bemerkbar, indem zum Beispiel Video-Frames verloren gehen oder ein Telefonanruf nicht angenommen wird. Im schlimmsten Fall wird ein kompletter Neustart des Systems erforderlich.
Viele dieser Probleme treten erst unter hoher Auslastung auf, also im Einsatz beim Endkunden. Zu diesem Zeitpunkt haben die SoCs bereits so viele Zyklen durchlaufen, dass diese Fehler selbst mit einer umfassenden Simulation nicht vorher aufgefunden werden können. Die eng getaktete Entwicklungsphase zwischen dem ersten Prototypen und der Produktserienauslieferung verschärft dieses Problem noch.
Zusätzlich erschweren Zugriffsprobleme die Arbeit des Debuggers.
Gerade wenn es essenziell ist, dass die Geschehnisse in einem SoC transparent dargestellt werden, ist die Sichtbarkeit von Ereignissen innerhalb des Chips stark reduziert. Für diesen Fall wäre es eine Option, die Bedingungen zu replizieren, die zum Absturz oder zum Fehler führten. Aber dabei mag es nicht ganz klar werden, welche Kombination von Ereignissen für die Entstehung des Fehlers verantwortlich war. Das System in einer Simulation oder Emulation einfach zum selben Punkt laufen zu lassen, ist wegen der schieren Anzahl von Zyklen, die ausgeführt werden müssen bevor der Fehler erneut auftritt, häufig nicht praktikabel.
Jobangebote+ passend zum Thema
Testen von Anfang an
Einige Entwickler-Teams haben sich für ein frühes Tapeout entschieden und sparen sich damit zumindest einen Respin vor der kommerziellen Auslieferung der Produkte. Dieser frühe Prototyp kann, solange er den größten Teil des Codes ausführt, die Software-Entwickler mit dem nötigen Spielraum versorgen, um die Zielhardware vor dem endgültigen Auslieferdatum zu untersuchen. Das ist jedoch eine hoch riskante Angelegenheit, da es keine Garantie gibt, dass der Prototyp die Software-Last handhaben kann oder ein ernsthafter Fehler den Betrieb des SoCs nicht schwerwiegend beeinträchtigt.
Selbst bei Verfügbarkeit eines frühen Prototyps, bleibt die Transparenz des SoCs-Betriebs entscheidend. So können Entwickler schnell und effizient mit den subtilen Multicore-Fehlern umgehen, die auftreten, sobald der Chip mehr kann als nur das Betriebssystem zu booten. Alles in allem brauchen wir eine umfassende und universelle Debugging-Umgebung, die von jedem genutzt werden kann.
Universelle Debugging-Lösung
Die Schlüsselanforderung an eine universelle Debugging-Lösung ist eine herstellerneutrale Infrastruktur. Diese erlaubt den Zugriff auf die unterschiedlichen proprietären Debugging-Systeme und ermöglicht eine einfache Erweiterbarkeit für kundenspezifische Rechenkerne sowie die Integration weiterer Logik im System. Der Einsatz einer derartigen Debugging-Infrastruktur ermöglicht Ingenieuren, die Multiprozessorsysteme aus mehreren Baugruppen aufgebaut haben, Logikanalysator-ähnliche Tastspitzen einzusetzen, um Busaktivitäten zu erfassen.
Eine Debugging-Infrastruktur, die sich einfach kundenspezifisch anpassen lässt, ermöglicht es auch, Debugging-Monitore in Bus-Controller und Schnittstellen zu integrieren. Nach dem Auftreten eines Fehlers, können diese Monitore nach dem aktuellen Zustand befragt werden. Dadurch wird es einfacher, sich dem Grund für einen Fehler zu nähern.
Mit einer allgemeinen, kundenspezifisch anpassbaren Debugging-Infrastruktur ist es möglich, einen flexibleren Zugriff auf das Zielsystem zu erhalten. Trace- und Aktivitätsdaten können herausgelesen werden, entweder unter Einsatz von Kommunikationsschnittstellen auf dem Chip, wie USB und Ethernet, oder mit Hilfe von JTAG und dedizierten Trace-Ports.
Dies verbessert nicht nur die Geschwindigkeit und Effizienz der ursprünglichen Debugging-Anstrengungen, sondern liefert auch später im Lebenslauf des Produkts die Fähigkeit, eine transparente Debugging-Unterstützung zu realisieren – selbst wenn das Gerät bereits in Feld eingesetzt wird. Wenn Verschlüsselungstechniken verwendet werden, ist es möglich, Debugging-Funktionen selektiv zu entsperren, um eine Echtzeitdiagnose über Standard-Kommunikationsschnittstellen zu ermöglichen. Dieser hohe Grad an Transparenz vereinfacht die Entwicklung von Reparaturprogrammen für Fehler, die erst nach der Auslieferung entdeckt werden.
Außerdem erhalten Entwickler Einblick in das Systemverhalten und können die Fähigkeit des Systems verbessern. Als positiver Nebeneffekt werden Vereinbarungen auf Service-Ebene erfüllt und künftige Erweiterungen können einfacher entwickelt werden.
Durch den Einsatz einer flexiblen, sicheren, herstellerneutralen Debugging-Lösung können SoC-Anbieter nicht nur sicherstellen, dass sie die engen Fristen für die Auslieferung der Produkte einhalten. Sie können auch damit beginnen, neue Geschäftsmodelle zu entwickeln, die die Vorteile der erhöhten Transparenz der Systeme im Feldeinsatz nutzen. Für diese beiden Ziele ist ein effektives Debugging der SoCs der Schlüssel.
Die Krux mit den Käfern
- Die Krux mit den Käfern
- Simulationen mit FPGA
- Echtzeit-Trace-Bus
- Fehler erst nach vielen Zyklen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
pls
Synchrones Debuggen von Aurix-Multi-Chip-Systemen
Code-Analyse, Scheduling, Security
Werkzeuge für smarte IoT-Entwickler
MEMS, Sensoren und Bildverarbeitung
Zwei Summits für eine intelligente, vernetzte Welt
Ist ein Benchmark genug?
Energieverbrauch moderner Mikrocontroller-Systeme
