Die Stromversorgung im Blick

Bei der Analyse der Leistungsaufnahme eines SoC-Designs ist es notwendig, das komplette System – auf realistische Weise – während der Hardware-/Softwarevalidierung zu betrachten. Mit dem Veloce-Emulator und Codelink liefert Mentor hierfür die notwendigen Tools.

Die zeitliche Abfolge der Schaltaktivitäten des Designs ermöglicht die Erkennung und weitere Untersuchung von Stromspitzen. (Bild: Mentor Graphics (Deutschland) GmbH)

Die Beurteilung der Leistungsaufnahme ist ein wichtiger Bestandteil der Systemvalidierung. Es reicht nicht mehr aus, durch Verifikation zu klären, ob ein SoC funktioniert. Designer müssen auch die Frage beantworten, ob das System das Leistungsbudget einhält. Eine korrekte Bewertung der Leistungsaufnahme erfordert jedoch eine Analyse der realen Anwendungsstimuli und die Verwendung von ausgereifter Software. Normalerweise beginnen die Softwareentwicklung und Verifikation erst, wenn das Design und die Implementierung der Hardware abgeschlossen sind. Oft arbeiten Hardwareteams zu diesem Zeitpunkt bereits am nächsten Projekt. Um die Leistungsaufnahme zu verifizieren und zu validieren, müssen Entwickler zumindest Teile der Software früher im Designzyklus entwerfen. Zudem muss die Software in einem Kontext laufen, in dem Leistungsdaten erfasst werden können.

Beim Versuch Probleme bei der Leistungsaufnahme herauszufinden, ist es entscheidend, dass das System auf realistische Weise betrieben wird. Nur wenn die komplette Software läuft und die Caches in einem typischen Zustand sind, erhält man ein realitätsnahes Leistungsprofil. Systementwickler können nicht benötige Teile eines Systems abschalten und somit große Energieeinsparungen ohne Kompromisse an der Funktionalität erzielen. Bei einem Kundenprojekt wurde ein derartiger Ansatz verwendet, wobei jedoch ein Problem festgestellt wurde. Die meiste Zeit funktionierte das System innerhalb der Akkulaufzeit sehr gut, gelegentlich (ca. zehn Prozent der Zeit) verabschiedete sich der Akku lange bevor er sollte. Die Entwickler waren verblüfft. Nach ausführlichem Debuggen entdeckten sie, dass eine der energiehungrigen Peripheriekomponenten dauerhaft eingeschaltet war, obwohl diese von keinem Prozess verwendet wurde. Um das Problem zu debuggen, stoppten sie die Arbeiten am Prototypen und kehrten zur Emulation zurück. Mit dem Veloce-Emulator von Mentor wollten sie die Ursache herausfinden. Veloce bietet eine Funktion, mit der man ein ‚Activity Plot‘ des Designs erstellen kann, das auf dem Emulator läuft. Der Activity-Plot zeigt einige Sample der Schaltaktivität des Designs. Obwohl die Schaltaktivität kein absolutes und exaktes Maß für die aufgenommene Leistung ist, lassen sich damit die verstecken Stromfresser herausfinden (siehe Bild oben).

Der Activity-Plot zeigt die Schaltaktivitäten im Design. (Bild: Mentor Graphics (Deutschland) GmbH)

Der Codelink-Korrelationscursor weist auf den Punkt, wo das System Peripherie A herunterfahren haben soll. (Bild: Mentor Graphics (Deutschland) GmbH)

Ein reales Beispiel

In diesem Fall lies der Kunde sein Design auf Veloce ablaufen und erfasste den Activity-Plot. Das Design wurde so konfiguriert, dass es zwei Prozesse ausführt: einen mit Peripherie A, den anderen mit Peripherie A und Peripherie B. Wie aus dem Graphen zu erkennen ist, erfolgt der Zugriff auf eine Peripheriekomponente bei einer bestimmten Frequenz. Dadurch werden während der Schaltaktivität eine Reihe von Spikes erzeugt. Der zweite Prozess greift – weniger häufig – auf beide Peripheriekomponenten zu, produziert aber die höheren Spikes. Wie in Bild 2 zu sehen ist, verschwinden irgendwann die Spikes an Peripherie A – das heißt, Peripherie A läuft weiter, wenn Peripherie B eingeschaltet wird. Die Überprüfung des Systems zeigte, dass die Stromversorgung für Peripherie A tatsächlich nicht ausgeschaltet wurde. Mit Codelink, einer Hardware/Software-Debug-Umgebung, die mit Veloce arbeitet, waren die Entwickler in der Lage, die Stelle der Softwareausführung der Kerne durch die Änderungen der Schaltaktivitäten des Activity-Plots zu bestimmen. Codelink verfolgt die Aktivität der Prozessoren bei der Codeausführung. Diese Tracedaten werden zu einem Co-Model-Host weitergleitet, wo sie verarbeitet und in einer Datenbank gespeichert werden. Mit der Datenbank kann man jederzeit den Zustand des Prozessors und der umgebenden Speicher rekonstruieren und dann den Zustand des Codes in einem herkömmlichen Softwaredebugger anzeigen.

Am wichtigsten ist jedoch, dass eine bestimmte Software-Zeile mit einem bestimmten Zeitpunkt in der Hardwareausführung in Bezug gesetzt werden kann. Der Anwender erhält somit einen Überblick über die Aktivitäten des Prozessors während oder unmittelbar von Perioden mit unerwartet hoher Leistungsaufnahme. Da das Problem mit dem Ausschalten der Stromversorgung einer der Power-Domänen zusammenhängt, setzten die Designer den Codelink-Korrelationscursor auf den Punkt, wo das System Peripherie A heruntergefahren haben soll (Bild 3). An diesem Punkt gab es zwei Prozesse, die auf zwei verschiedenen Kernen aktiv waren und beide Peripherie A gleichzeitig ausgeschaltet hatten (Bild 4). Mit Codelink konnten die Entwickler Schritt für Schritt durch den Bereich des Codes gehen, in dem die Power-Domäne in der eingeschalteten Position stecken geblieben ist. Hier fanden sie zwei Prozesse, jeder auf einem eigenen Kern, die beide dieselbe Power-Domäne ausschalteten. Es stellte sich heraus, dass die AXI-Fabric den Begriff ‚Master‘ für die AXI-Master-ID von der Fabric einführte. Da der ARM-Prozessor vier Kerne hat, stammt der AXI-Bus-Traffic der vier Kerne vom selben Master-Port, was den Anschein erweckte, als ob alle vom selben Master kommen würde. Aus der Fabric- und Slave-Perspektive wurden alle Schreib- und Lesebefehle vom selben Master initiiert. Deshalb wurde der Zugriff erlaubt. Es gab keine Differenzierung zwischen dem Zugriff auf Kern 0 und Kern 1. Einem exklusiven Zugriff von einem Kern, konnte ein exklusiver Zugriff von einem anderen Kern im selben Cluster folgen und der wäre erlaubt. Das war der Knackpunkt dieses Bugs. Die ID des Kerns, der eine AXI-Transaktion erzeugt, wird in einen Teil der Transaktions-ID kodiert. Wird diese dem Master hinzugefügt, der die Exklusivität des Zugriffs auf das Referenz-Count-Register bestimmt, dann erlaubt das Design die korrekte Verarbeitung des exklusiven Zugriffs. Der Veloce-Emulator gab den Entwicklern die notwendige Leistungsfähigkeit, um den Algorithmus bis zu dem Punkt ablaufen zu lassen, an dem das Problem reproduziert werden konnte. Codelink lieferte die erforderliche Transparenz beim Debuggen, so dass sie die Ursache der Probleme aufdecken konnten. Der Activity-Plot ist eine Funktion, mit der Entwickler die relative Leistungsaufnahme ihres Designs verstehen können. Zusammen geben sie den Ingenieuren die Informationen und Mittel zur Entwicklung leistungsfähigerer, effizienterer Designs. Mehr Informationen über die Power-Management-Validierung mit Veloce und Codelink sowie ausführlichere Details zu dieser speziellen Implementierung liefert das Whitepaper System Activity Validation.