Ultra-Low-Power Mikrocontroller ULPMark jetzt mit Peripheriefunktionen

Die Energieffizienz einer MCU ohne Peripheriefunktionen zu messen, ist nur bedingt sinnvoll. Trotzdem ist der von EEMBC entwickelte ULPBench nicht sinnlos, da man das Speichersubsysteme und CPU-Architekturen vergleichen kann. Der ULPMark, berücksichtigt von nun an auch Pheripherieblöcke.

Unter dem Begriff »Peripheral Profile« hat EEMBC eine neue Version des Ultra-Low-Power-Benchmarks ULPBench für embedded Mikrocontroller vorgestellt. Der Benchmark wurde angesichts neuer Messhardware in ULPMark umbenannt, es gibt jetzt den ULPMark-CP (Core-Profile, entspricht dem ehemaligen ULPBench) und den ULPMark-PP (Peripheral-Profile). Hier werden nicht nur A/D-Wandler, Timer, SPI und Echtzeituhr berücksichtigt, sondern die Hersteller haben auch die Möglichkeit, Werte für Versorgungsspannungen unterhalb von 3,3 V zu publizieren. Initialzündung hierfür war unser Exklusivbericht [1], in dem wir eigene Messungen bis hinunter zu 1,8 V vorgestellt hatten. 

Die DESIGN&ELEKTRONIK hatte bereits im Juli exklusiv die Möglichkeit, selbst Messungen mit neuer Hard- und Software vorzunehmen. Klar ist, die seinerzeit von Texas Instruments für den ULPBench entwickelte Hardware mit der Bezeichnung »EnergyMonitor« ist für diese Messungen nicht geeignet. Daher gab EEBMC bei ST  Microelectronics die Entwicklung neuer Messhardware und zugehöriger Software in Auftrag.

Das sogenannte »Power Shield« (im Bild 1, rechts, links daneben befindet sich der alte »EnergyMonitor« von TI) basiert auf einem mit 80 MHz getakteten Mikrocontroller STM32L496VGT6 und kann theoretisch dank LC-Display und entsprechenden Konfigurations-Buttons im Gegensatz zum Energy-Monitor ohne PC betrieben werden. Die Einstellungen und Ergebnisse werden in diesem Fall auf dem Display dargestellt (Bild 2). Komfortabler ist freilich die Anbindung an einen Windows-PC mittels USB und die Installation der neuen EEMBC-Software »Cube Monitor«, die nicht nur die Benchmark-Ergebnisse als Zahl auswirft, sondern auch einen Verlauf der Stromaufnahme über die Zeit grafisch darstellt (Bild 3).

Der Messbereich im aktiven Modus der MCU liegt zwischen 100 nA und 50 mA, im Energiesparmodus zwischen 1 nA und 200 mA. Die maximale Abweichung der Messergebnisse soll 2 % betragen, was zumindest durch eigene Vergleichsmessungen mit dem Energy-Monitor bestätigt wurde.

Mit den drei 12-bit-A/D-Wandlern und einer maximalen Abtastrate von 5 MS/s wird eine dynamische Erfassungsrate von 761 kS/s erreicht.

In der GUI kann man sehr einfach den Energieverbrauch für selektierte Zeiträume auswerten, wie etwa für TIs MSP430FR5969 bei einer Gesamtlaufzeit des ULPBench von 10 s einen Verbrauch von 80,317 μJ oder 8,0317 μJ/s, was einem ULPMark-Score von 124,5 entspricht. Wie Bild 4 zeigt, kann man jedoch weiterhin feststellen, dass pro ULPBench-Zyklus die MCU im aktiven Modus bei 8 MHz Taktfrequenz rund 2 ms benötigt, um den Workload abzuarbeiten und dabei im Schnitt 895 µA aufnimmt, sodass in Summe 6,475 µJ verbraucht werden. Im Energiesparmodus, der rund 998 ms belegt, werden im Schnitt 526 nA aufgenommen und so 1,575 µJ verbraucht. Damit werden 80,5 % der Energie im aktiven Modus benötigt und 19,5 % im Energiesparmodus, was insofern interessant ist, als dieses Verhältnis bei 32-bit-ARM-CPUs beim Cortex-M0 etwa bei 60/40 % liegt und beim Cortex-M4 sogar bei etwa 40/60 %. Die IPC der MSP430-16-bit-CPU ist eben vergleichsweise gering. implementiert wurden. In

Das Peripheral-Profile des ULPBench 

Die Problematik beim Vergleich des Energieverbrauchs von Pheripherieblöcken ist erstens, dass unterschiedliche MCUs unterschiedliche Peripherien beinhalten und zweitens selbst bei prinzipiell vergleichbaren Funktionen diese unterschiedlich

der ULP-Arbeitsgruppe der EEMBC hat man sich daher im ersten Schritt auf einen Minimalkompromiss geeinigt, der Blöcke betrachtet, die so gut wie auf jeder MCU gefunden werden: Ein A/D-Wandler, ein Timer zur Erzeugung einer Puls-Weiten-Modulation (PWM), eine SPI-Schnittstelle und eine Echtzeituhr (RTC). Der Benchmark selbst besteht aus 10 Schritten in jeweils 1 s Abstand: 

Schritt 1: x64 Byte Datenerfassung über einen A/D-Wandler mit einer Abtastrate von 1 kHz + 20 PWM-Pulse mit 32 kHz und festem Tastverhältnis + RTC aktiv,

Schritt 2: x64 Byte Datenerfassung über einen A/D-Wandler mit einer Abtastrate von 1 kHz + 40 PWM-Pulse mit 32 kHz und ansteigendem Tastverhältnis + RTC aktiv,

Schritt 3: 1 Byte Datenerfassung über einen A/D-Wandler + 40 PWM-Pulse mit 32 kHz und festem Tastverhältnis + RTC aktiv,

Schritt 4: 1 Byte Datenerfassung über einen A/D-Wandler + x64 Byte senden/empfangen über SPI-Schnittstelle + 100 PWM-Pulse mit 32 kHz und festem Tastverhältnis + RTC aktiv,

Schritt 5: 1 Byte Datenerfassung über einen A/D-Wandler + x64 Byte senden/ empfangen über SPI-Schnittstelle sowie Überprüfung der Daten aus Schritt 4 + 100 PWM-Pulse mit 32 kHz und festem Tastverhältnis + RTC aktiv,

Schritte 6-8: wie Schritt 5,

Schritt 9: 1 Byte Datenerfassung über einen A/D-Wandler + x64 Byte senden/empfangen über SPI-Schnittstelle sowie Überprüfung der Daten aus Schritt 8 + 30 PWM-Pulse mit 1 MHz und ansteigendem Tastverhältnis + RTC aktiv und

Schritt 10: Überprüfung der A/D-Wandlerdaten aus Schritt 3 bis 9 + überprüfen der SPI-Daten aus Schritt 9 + RTC (überprüfen und anhalten).

Die DESIGN&ELEKTRONIK konnte exklusiv schon vor Publizierung dieses neuen Benchmarks Messungen durchführen, konkret mit diversen STM32-Derivaten, einem MSP430FR und der »Subthreshold-MCU« Apollo von AmbiqMicro zum Vergleich. Der Verlauf des Energieverbrauchs des STM32L4 über die Zeit ist in Bild 5 dargestellt. Der MSP430FR konnte beim Core-Profile, bei dem die CPU und das Speichersystem getestet werden, gegen den STM32 kein Land gewinnen [1]. Das Peripheral-Profile ist jedoch, das war schon vor den Messungen klar, dem MSP430 wie auf den Leib geschnitten. Warum? Es handelt sich um die einzige Ultra-Low-Power-MCU, deren A/D-Wandler bei der definierten Abtastrate von 32 kHz im Stop-Modus, bei TI LPM3 genannt, ohne jede Involvierung der CPU, betrieben werden kann.


Die Folge ist, dass in den Schritten 1-8 und 10 der Energieverbrauch deutlich hinter dem einer Cortex-M4-CPU wie dem STM32L4 zurückbleibt (Bild 6), während in Schritt 9, in dem die Abtastrate auf 1 MHz erhöht wurde, dieser Vorteil nicht mehr zum Tragen kommt.

Im Gesamtergebnis - gemessen bei 3,0 V Versorgungsspannung - kann der STM32L433 (256 KB Flash-Speicher) mit einem Score von 65 den MSP430FR mit 63,7 gerade noch überholen, während der STM32L0 mit Cortex-M0-CPU und seinem energiehungrigeren A/D-Wandler nur auf 57,5 Punkte kommt. Der STM32L452 mit 512 KB Flash-Speicher erreicht 61,7. Dies sind keine offiziell von den Herstellern angegebenen Scores, möglicherweise können sie durch die eine oder andere Code-Optimierung noch etwas höhere Werte erzielen als wir.

AmbiqMicro scheitert 
 
Gleiches gilt natürlich auch für die Apollo-MCU, die - dies ist kein Schreibfehler - bei 3,0 V Versorgungsspannung auf einen katastrophalen Score von 32 kommt. Die Frage ist natürlich, warum ist dies so, nachdem die Subthreshold-MCU beim Core-Profile so überragend abgeschnitten hat. Es gibt zwei Hauptgründe: Zum einen hat AmbiqMicro keine DMA-Übertragung implementiert, sondern für den A/D-Wandler steht ein lediglich 8 Byte großer FIFO-Puffer zur Verfügung. 

Dies bedeutet, dass nach je 8 Datenerfassungen die CPUs aufgeweckt werden und die Daten ins SRAM transferieren muss. Beim STM32 wird dieser Vorgang in den Betriebsmodi LPSleep (A/D-Wandler-Betrieb) und LPRUN (Daten evaluieren) abgebildet, in Summe werden somit schon in Schritt 1 des Benchmarks 16,9 µJ (STM32L433) jedoch 28,6 µJ (Apollo) verbraucht. In Schritt 9, wo die Erhöhung des PWM-Tastverhältnisses stattfindet, kann der STM32L4 ebenfalls im Modus LPRUN verbleiben, während Apollo erneut jedesmal in den aktiven Modus aufgeweckt werden muss. Im Ergebnis stehen 58,5 µJ (STM32L433) hohe 210 µJ (Apollo) gegenüber. Der zweite Grund ist eine grottenschlechte SPI-IP. Diese verbraucht im Schnitt 2-4x soviel Energie wie der STM32L433, auch die PWM ist energiehungriger als bei ST. Extrem energieeffizient ist dagegen Ambiqs Echtzeituhr, was der MCU beim Core-Profile diesen hohen Score eingebracht hat.

Natürlich muss man sich angesichts der Tatsache, dass das Prüfszenario in der EEMBC-Arbeitsgruppe von deren Leiter, einem TI-Mitarbeiter, vorgeschlagen wurde, fragen, wie realistisch es denn ist und ob die Abtastraten von 32 kHz nicht grundsätzlich zu niedrig angesetzt wurden. Wenn man die typischen Zielapplikationen von Ultra-Low-Power-MCUs ansieht, wo es in der Regel um die Erfassung und Weiterverarbeitung von Sensordaten geht, können wir dies nicht erkennen, sehr viele bewegen sich in Bereichen von 10 Hz bis maximal 4 kHz, wie bei Stromzählern. Zudem hätten die Mitstreiter in der Arbeitsgruppe wie NXP, SiliconLabs, ST Microelectronics, Renesas und ARM die Möglichkeit gehabt, zu protestieren und Gegenvorschläge einzubringen

Interessant fanden wir im Rahmen der Untersuchungen auch die Frage, warum TI in seinem MSP432 nicht den Low-Energy-Accelerator (LEA) aus dem MSP430FR implementiert hat. Auch wenn die Funktionalität von LEA beim MSP432 zum Teil durch die integrierte Cortex-FPU bereitgestellt wird, hat der LEA, der ohne CPU-Involvierung arbeitet und den Abschluss der Berechnungen per Interrupt meldet, bei zahlreichen Funktionen seitens des Energieverbrauchs die Nase vorne. Gegen die Integration sprach aus Sicht von TI daher weniger die Technik als die geringe Akzeptanz einer proprietären Lösung auf einer »Standard-MCU« mit ARM-CPU.

Fazit 

Mit dem Peripheral-Profile ist EEMBC auf dem richtigen Weg, ein realistischeres Messszenario für Ultra-Low-Power-MCUs bereitzustellen. Gleichwohl wäre beispielsweise auch die Integration eines UART interessant gewesen, ebenso die Frage, wie sich MCUs verhalten, wenn im Energiesparmodus mehr als die wenigen Variablen des ULPMark im SRAM gehalten werden müssen. Diesbezügliche Messungen werden wir in einer der nächsten Ausgaben der DESIGN&ELEKTRONIK publizieren. (fr)
 
Referenz 

[1] Riemenschneider, F.: ULPBench entzaubert. DESIGN&ELEKTRONIK 2016, Heft 8, S. 9 ff.