Powermanagement optimieren MCU-Energieaufnahme ohne Software regeln

Bei Auswahl, Etablierung und Markterfolg eines Systems ist der Energiebedarf ein bedeutender Faktor. Doch der traditionelle Ansatz, die Energieeffizienz in Mikroampere oder µW/MHz anzugeben, greift heute nicht mehr. Das Powermanagement moderner Ultra-Low-Power-MCUs benötigt einen neuen Ansatz.

Die jüngste Generation der ultra-energieeffizienten MCUs folgt der Powermanagementarchitektur von Hochleistungsprozessoren; es sind leistungseffiziente DC/DC-Wandler zusammen mit analogen Spannungsreglern verbaut. Die spannende Frage ist, ob Anwender diese Architektur jederzeit ohne zusätzliche »energiefressende« Software nutzen können. Kann ein Anwender seine Anwendung optimal an den Energie- und System-Leistungsbedarf anpassen? Ist eine energieprofiloptimierte Anwendung möglich und kann diese verlässlich gewartet, erweitert und angepasst werden, und zwar nicht nur in der Entwicklung, sondern auch im Feld?

Der Energiebedarf kann während der Entwicklung eines Systems gut kontrolliert und den Zielen angepasst werden, wenn die Anwendung mit allen Parametern klar definiert ist. Dies ist bei statischen Verhältnissen und Raumtemperatur einfach machbar; die Datenblattparameter einzelner Mikrocontroller halten hier umfangreiche Situationen vor. Mehr als 150 Stromparameter sind dabei keine Seltenheit, sondern eher die Regel. Der rasant wachsende Bedarf an Speicher aufgrund komplexerer Code- und Datenmengen bedingt die Transformation zu kleineren Prozessgeometrien. Damit erreicht man weniger Energieaufnahme im aktiven Betrieb (Codeausführung, Run-Modus). Der Energieanteil des Ruhezustands (Leckstrom) steigt jedoch rasant – insbesondere bei höheren Temperaturen – für die Betriebsmodi, bei denen wenige oder keine Teile des Systems noch in Betrieb sind.

Wie stark Spannung und Temperatur den Energiehaushalt beeinflussen, zeigten frühzeitig die Entwicklungen für Computer- und Kommunikationselektronik infolge zunehmend kleinerer Prozessgeometrien. Power-Gating, Spannungs- und Frequenzskalierung sind in diesem Umfeld entwickelt worden. Diese Techniken sind nun auch Standard in MCUs/SoCs und geeignet für niedrigsten Energiebedarf. Doch welche Maßstäbe zum Beurteilen der Energieeffizienz wurden von den Herstellern angelegt und welche sind konkret für eine Anwendung und für ein Portfolio wichtig?

Betriebsmodi vs. Energiebedarf

    Der erste Faktor betrifft die Verweilzeit in einem Energiemodus, und deren Verhältnis zur gesamten aufgenommenen Energie sowie die dynamischen Umschaltkonditionen:

    • Betriebsmodus bestimmt Energiebedarf. Funktionen/Code werden ausgeführt.
    • Ruhemodus bestimmt Energiebedarf. Funktionen/Codeausführung ist angehalten und benötigt externe oder interne Ereignisse zur Rückkehr in den Betriebsmodus.
    • Beide Modi bestimmen den Energiebedarf. Der Betriebs- und der Ruhemodus bestimmen zusammen den Energiebedarf.
    • Die Umschaltbedingungen und die nicht zu-/abschaltbaren Funktionen.

    Bild 1 zeigt das Profil des EEMBC-Energie-Benchmarks ULPBench und seine zwei Phasen. Der Betriebsmodus (1) führt einfache Code-Beispiele aus. Die Wahl des Betriebsmodus bleibt dem Anwender überlassen; er kann den Modus des geringsten Energiebedarfs bei bestimmungsgemäßer Ausführung wählen. Die Echtzeituhr (RTC/RTCC) mit einem 32-kHz Quarzoszillator ist während der gesamten Zeit aktiv und Teil (2) der Energieaufnahme. Die Periodendauer beträgt 1 Sekunde. Es wird die Energieaufnahme anstelle der Stromaufnahme gemessen. Geplante zukünftige Generationen des Benchmarks sind damit vorbereitet auf die Erfassung von Umschaltverlusten.

    Bei aktuellen Low-Power-MCU/SoCs dominiert die Betriebsmodusenergie die Energieaufnahme; meistens wird ein höherer Betriebsstrom durch die kürzere Ausführungszeit mehr als kompensiert. Bei einer Periode von 1 Sekunde spielen die Einschaltverluste keine Rolle.

    Bild 2 zeigt das Prinzip des Power-Gatings. Das Abschalten der Versorgung von Teilen der Schaltung soll Energieverluste durch Leckströme reduzieren. Die Leckströme entladen intern vorhandene Kapazitäten umso schneller, je höher die Temperatur ist. Die Kapazitäten sind sowohl parasitärer als auch integrierter Natur und halten Spannungseinbrüche durch Spitzenstöme der Funktionen auf einem vertretbaren Niveau. Durch Power-Gating wird aber auch die dynamische Energieaufnahme verschlechtert und die Transferbedingungen addieren einen unproduktiven Energiebedarf. Da parallel zum Power-Gating in vielen Betriebssituationen die Funktionen der Leistungsversorgung ab- und zugeschaltet werden, wird der dynamische transferbedingte unproduktive Energiebedarf weiter erhöht.

    Der zweite Faktor betrifft die Systemumgebung wie Energiequelle und Temperatur oder Temperaturprofil:

    • Die Energiequelle muss auf die Systemspannung angepasst werden z. B. mit Längsregler oder DC/DC-Wandler – es ist bei MCUs meist nur einer zu einem Zeitpunkt aktiv, bei Hochleistungssystemen (z. B. Multi-Core-SoCs) sind oft mehrere Spannungssysteme gleichzeitig aktiv.
    • Das Temperaturprofil ist zu betrachten, wenn die Energieverluste, zum Beispiel durch Leckströme, einen wesentlichen Anteil an der Energieaufnahme ausmachen; dies kann bei allen drei Modi zutreffen.

    Welche Optionen kann man bei MCUs/SoCs nutzen?

    Die verschiedenen Funktionen der Betriebsmodi werden in der Regel durch einen Powermanagementblock verwaltet. Dies gilt für Grundeinstellungen und Übergänge zwischen verschiedenen Energiemodi. Die möglichen Betriebsmodi sind im wesentlichem bestimmt durch die interne Aufteilung, ihrer Ausbildung, und dem daraus resultierenden Verhalten der Hardware in MCU/SoCs.

    Die zur Verfügung stehenden Betriebsmodi – in bis dato verfügbaren Generationen von Low-Power-Bausteinen – stellen dem Anwender im Wesentlichen Instruktionen, Energiemodusbits und -daten sowie Kontrollbits und -daten zur Verfügung. Zusätzlich werden Softwarelibraryelemente (z. B. APIs) angeboten. In der Anwendung wird damit nur bedingt anwendungsgerechte Energieeffizienz erzielt.

    Wunsch und Wirklichkeit

    In vielen Anwendungen sind MCUs/SoCs von unterschiedlichen Herstellern nötig, die zusammen mit einer Energiequelle Mindestanforderungen an Leistungsfähigkeit und Laufzeit erfüllen. Die Energiemodi und Funktionalitäten werden direkt mittels Instruktionen und Kontrollbits/-daten aktiviert. Ist ein direkter Zugriff möglich, können die Funktionalität und Energiemodi über den gesamten Programmcode verteilt sein. Der Zugriff könnte allerdings auch abgesichert sein und zum Beispiel im Supervisormodus die Umschaltungen durch ein zentrales Softwareprogramm wie das Betriebssystem oder eine Powermanagementsoftware vorgenommen werden. Dies bietet einen Schutz vor kritischen Betriebszuständen durch fehlerhafte Modusumschaltung. Vom energetischen Standpunkt gesehen ist die Softwarelösung indes meist ungeeignet, um häufig in der Situation angepasste optimale Betriebsmodi zu wechseln; jede Ausführung von Code braucht wesentliche Hardwareteile mit entsprechend hohem Energiebedarf.

    Der Schutz vor unerlaubten Zugriffen ist in MCUs/SoCs noch weitgehend ein Wunschszenario. Ferner benötigt es noch Software. Damit ist eine Anwendung in Interrupt- oder ereignisgetriebenen Situationen ohne Softwareausführung nicht abgedeckt. Und jede Softwareausführung benötigt Energie auch beim Aktivieren wesentlicher Hardwareteile wie Hauptspeicher, Bussystem, Codeausführung in einem Kern.