Optimierung der Systemleistung am Beispiel des MPC5554: Hohe Taktfrequenzen allein reichen nicht aus Robuster Rechenkünstler

In Zukunft werden moderne Hochleistungscontroller wie der MPC5554 mit Taktfrequenzen von weit über 100 MHz in Automotive-Anwendungen eingesetzt, wo bisher Taktfrequenzen von 10 bis 40 MHz vorherrschend waren. Diese Steigerung hat aber keinen linearen Einfluss auf die Leistungsfähigkeit des Gesamtsystems. Oftmals werden die modernen Controller durch externe Programmspeicher ausgebremst, weil deren Zugriffszeiten nicht mit dem Prozessortakt Schritt halten können.

Optimierung der Systemleistung am Beispiel des MPC5554: Hohe Taktfrequenzen allein reichen nicht aus

In Zukunft werden moderne Hochleistungscontroller wie der MPC5554 mit Taktfrequenzen von weit über 100 MHz in Automotive-Anwendungen eingesetzt, wo bisher Taktfrequenzen von 10 bis 40 MHz vorherrschend waren. Diese Steigerung hat aber keinen linearen Einfluss auf die Leistungsfähigkeit des Gesamtsystems. Oftmals werden die modernen Controller durch externe Programmspeicher ausgebremst, weil deren Zugriffszeiten nicht mit dem Prozessortakt Schritt halten können.

Die Taktfrequenz ist ein wichtiger Parameter für die Rechenleistung eines Systems. Allerdings gibt es hier gerade in Controlleranwendungen oftmals andere Grenzen. So will man aus EMV-Gründen nicht mit unnötigerweise hohen Systemtaktfrequenzen arbeiten. Ein anderer wichtiger Grund ist die Verlustleistung eines Rechners. Mit zunehmender Taktfrequenz steigt die Verlustleistung überproportional an. Das aber ist Gift für Steuergeräte, die zum Teil in heißem Öl arbeiten müssen (wie das gerade in Autoanwendungen auftritt). Bei einer Umgebungstemperatur von 125 °C, einer Chiptemperatur von 150 °C und einem thermischen Widerstand von ca. 18 K/Watt ergibt sich als maximale Verlustleistung ein Wert von (150 – 125) / 18 = 1,4 Watt. Die Maximalfrequenz eines Controllers wird dann darauf abgestimmt.

Rechner mit einer Taktfrequenz von mehreren GHz, wie sie in modernen Desktop-PCs verwendet werden, nehmen nicht selten über 100 Watt auf; das sind aber für das Budget eines Steuergerätes annähernd zwei Zehnerpotenzen zu viel.

Rechenleistung braucht Speicherbandbreite

Leider steigt die Rechenleistung nicht linear mit der Systemtaktfrequenz an, wie Bild 1 verdeutlicht. Das liegt vor allem an der Zugriffszeit der (externen) Flash-Speicherbausteine. Ein externes Flash hat heute typischerweise eine Zugriffszeit von ca. 70 ns. Dazu kommen noch die Setup-Zeiten für die Adressen und Daten. Damit ergibt sich eine gesamte Zugriffszeit von ca. 80 ns. Durch einen so genannten Burst können die nächsten sieben Speicherworte in jeweils ca. 15 ns gelesen werden, so dass insgesamt acht Speicherzugriffe in 80 + 7 x 15 = 185 ns gemacht werden können. Bei einer Speicherbreite von 32 bit ergibt sich daraus ein theoretisches Maximum von 43 Megaworten/s = 172 Mbyte/s. In der Praxis werden von diesen möglichen acht Zugriffen innerhalb eines Burst nur etwa fünf wirklich benötigt, danach erfolgt ein Sprung auf eine andere Adresse. Die Zeit für den ersten Zugriff bleibt konstant, deshalb ergibt sich hier ein echter Durchsatz von 80 + 4x 15 = 140 ns für fünf Zugriffe, entsprechend circa 36 Megaworte/s = 144 Mbyte/s.

In der Zwischenzeit wird mit „Double-Data-Rate“-Speichern (DDR) versucht, diesen Flaschenhals zu umgehen. Dabei bleibt die Zeit für den ersten Zugriff konstant, die Folgezugriffe des Burst halbieren sich. So ergibt sich für das theoretische Maximum: 80 + 7 x 7,5 = 132,5 ns entsprechend 60 Megaworten/s = 240 Myte/s. Für den „normalen“ Fall von fünf Befehlen pro Burst ergibt sich ein Durchsatz von 80 + 4x 7,5 = 110 ns, entsprechend 45,5 MWorte/s = 182 Mbyte/s. Für die typischen Anwendungen steigert sich beim Einsatz von DDR-Flash-Bausteinen der Durchsatz also von 36 auf 45,5 MWorte/s, das entspricht also einer Steigerung von 21 %, von „Double“ kann dabei keine Rede sein.

Diese Rechnungen zeigen, dass der Datendurchsatz eines externen Flash-Bausteins im Mittel auf ca. 40 MHz begrenzt ist. Ein moderner RISC-Prozessor kann pro Takt einen Befehl ausführen; muss diesen aber auch vorher lesen. Rechner, die mit über 40 MHz getaktet sind, können deshalb aus dem externen Flash nicht mehr als 40 Millionnen Befehle pro Sekunde lesen und werden auf diese Weise ausgebremst, d.h. auf eine Rechenleistung begrenzt, die einer Taktfrequenz von ca. 40 MHz entspricht. Deshalb kann eine Frequenzsteigerung über ca. 40 MHz hinaus hier keinen Leistungszuwachs bringen (außer durch einen internen Cache in Verbindung mit einer entsprechenden Trefferrate).

Anders sieht die Situation bei internen Flash-Speicher-Modulen aus. Hier sind die Zugriffszeiten wesentlich kürzer, die Busse sind breiter (64 bit), die Taktfrequenzen höher und moderne Flash-Module arbeiten zudem vorausschauend, d.h., während der Übertragung der Daten aus dem Flash-Modul in die CPU adressiert das Flash intern bereits den nächsten Block. Damit liefert ein internes Flash beim MPC5554 einen Datendurchsatz von >1 Gbyte/s. In der Praxis bewegt sich der Durchsatz immer noch bei >900 Mbyte/s und liegt damit über den Anforderungen des Prozessors, die bei cirka 530 Mbyte/s für Codezugriffe liegen (ohne Cache); dazu kommen noch die Anforderungen für Daten.

Allerdings zeigt sich auch beim internen Flash ab etwa 100 MHz ein kleiner Unterschied zwischen der theoretischen Leistung des CPU-Kerns und der tatsächlichen Leistung des Systems. Der Grund dafür liegt unter anderem darin, dass bei typischen Controlleranwendungen nicht nur das Programm, sondern auch größere Datenmengen im Flash liegen (z.B. Kennfelder und applikationsspezifische Konstanten). Auf dieses Flash kann aber nicht gleichzeitig ein Code- und ein Datenzugriff erfolgen. Auch ist die „vorausschauende“ Adressierung ist nicht bei allen Sprüngen möglich.

Das ist der Grund, warum bei Bausteinen ab ca. 100 MHz heute meistens ein Cache implementiert wird. Anwender sorgen sich deshalb oft um die Echtzeit-Fähighkeit ihrer Software, denn es macht für die Laufzeit einen großen Unterschied, ob die Software bereits im Cache gepuffert ist oder (noch) nicht. Allerdings ist dafür nicht nur der Cache ausschlaggebend, auch traditionelle Parameter (wie z.B. die Anzahl und die Art der auftretenden Interrupts) beeinflussen die Laufzeit der Software in hohem Maße.

Einfachste Abhilfe schafft hier eine manuelle Steuerung des Cache; laufzeitkritische Routinen und Daten können dauerhaft im Cache abgelegt werden (Cache locking), so dass diese Werte nicht überschrieben werden und während der gesamten Laufzeit garantiert im Cache vorliegen. Damit gibt es keinen „worst case“ mehr, denn die Laufzeit ergibt sich für diese Routinen immer aus den Cache-Zugriffszeiten.

Genau so ist es für manche Code- bzw. Datenbereiche sinnvoll, diese erst gar nicht in den Cache zu übernehmen; dann haben Zugriffe auf diese Bereiche keine Änderung im Cache-Inhalt zur Folge. Derartige Bereiche werden durch die integrierte MMU (Memory Management Unit) definiert und verwaltet.