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.
Gegenüberstellung von zwei Kernen (Bild: Mentor Graphics (Deutschland) GmbH)
Autor: Russel Klein,
Technischer Direktor,
Mentor Graphics,
www.mentor.com
