Weniger als Ultra-Low-Power Perpetuum-Mobile-MCU für Energy-Harvesting

Das »Perpetuum-Mobile-Computing« soll das Billionen-Sensor-Universum zu ermöglichen, in dem Sensoren zusammen mit extrem energiesparenden MCUs mittels Energy-Harvesting oder Knopfbatterien betrieben werden können. Renesas hat mit dem RF70E den ersten Controller für solche Anwendungen vorgestellt.

Wenn es um Ideen geht, wie man das Internet of Things mit seinen prognostizierten Milliarden vernetzten Sen-sorknoten nutzen kann, gibt es sicherlich keinen Mangel. Bei vielen dieser Szenarien wie zum Beispiel die Überwachung von Brückeninfrastrukturen, smarter Landwirtschaft oder Medizin 4.0, bei der intelligente Tabletten in unserem Körper Diagnose betreiben, stellt sich die Frage, wo die Mikroelektronik ihre Energie herbekommt. Ich selbst habe gerade in meinem Haus 27 Feuermelder ersetzen dürfen, deren Batterien am Ende waren.

Will man regelmäßige Batteriewechsel vermeiden, stellt das Ernten von Energie aus der natürlichen Umgebung, das sogenannte Energy-Harvesting, die einzige sinnvolle Alternative dar. Mögliche Energiequellen können zum Beispiel Variationen in der Umgebungstemperatur, Vibrationen oder Luftströmungen sein, wobei man Energieumwandlung durch den piezoelektrischen Effekt, den thermoelektrischen Effekt oder auch den photoelektrischen Effekt ausnutzen kann. Sogar biologische Effekte durch Bakterien können ausgenutzt werden.

Das Problem selbst bei heutigen sogenannten Ultra-Low-Power-Mikrocontrollern (ULP) besteht darin, dass die Leistungsaufnahme für viele Energy-Harvesting-Szenarien immer noch zu hoch ist. Durch Fortschritte in der Chip-Fertigung konnte zwar die Stromaufnahme im aktiven Modus dramatisch gesenkt werden (Bild 1), dies gilt parallel aber nicht für den Sleep-Mode. Das Gegenteil ist der Fall: Kleinere Fertigungsgeometrien führen zu höheren Leckströmen, auch wenn Techniken wie der Einsatz von FinFETs (für Sensor-Nodes zu teuer) oder FD-SOI-Substraten (eingesetzt zum Beispiel von NXP auf Basis eines von Samsung entwickelten Prozesses) die Leckstrom-Explosion in Grenzen halten.

Chiphersteller Renesas hat als Lösung dieses Problems eine SOTB (Silicon on Buried Oxide) genannte Technologie entwickelt, die sowohl die Stromaufnahme im aktiven Modus als auch im Sleep-Mode in Bereiche bringt, welche die entsprechenden Produkte energy-harvesting-fähig macht. Das erste Produkt nennt sich R7F0E, es handelt sich um einen Controller mit arm-Cortex-M0+-CPU, die mit 32 MHz getaktet ist und einem Boost-Modus über eine erhöhte Versorgungsspannung auch mit 64 MHz laufen kann. Als Speicher werden entweder 1,5 MB Flash und 256 KB SRAM oder 256 KB Flash und 64 KB SRAM angeboten. Im aktiven Modus sollen in der kleineren Variante lediglich 10 µA/MHz und im tiefsten Schlafmodus, bei dem nur noch die Echtzeituhr und der Reset-Manager aktiv sind, 150 nA aufgenommen werden. Ein weiterer Energiesparmodus, Software-Standby genannt, führt zu 200 bis 400 nA Stromaufnahme, wobei die Inhalte der Core-Logik (Register- und Statusinhalte) und von 32 KB SRAM-Daten erhalten bleiben. Dazu Echtzeituhr und Reset-Manager aktiv bleiben. Dieser Wert ist extrem gering, da beim SRAM nur 1nA/KB Daten aufgenommen werden, warum dies so ist, wird später erläutert.

In der größeren Variante erhöht sich die Stromaufnahme im aktiven Modus auf 25 µA/MHz (Grund ist der Flash), während der Software-Standby-Modus mit 400-500nA in einem vergleichbaren Bereich bleibt. Die Aufwachzeit vom Sleep-Mode in den aktiven Modus beträgt in der ersten Produktgeneration 1 ms, in zukünftigen Generationen sollen 50 µs erreicht werden.

Last but not least nützt es nichts, wenn CPU und Speicher-Subsystem extrem energiesparend arbeiten, die Peripherie jedoch umso mehr Energie verbrennt – ein Negativbeispiel in dieser Hinsicht ist bekanntlich die Apollo-MCU des Startups AmbiqMicro. Renesas hat daher den für Sensor-Anwendungen essentiellen A-D-Wandler neu entwickelt, die Daten lauten 14-bit-Auflösung, 1,6K Abtastungen/s und nur 3 µA Stromaufnahme, was innerhalb des durchschnittlichen Strombudgets einer Energy-Harvesting-Quelle von ungefähr 5 µA liegt. Damit ist es möglich, Abtastungen nicht nur in Intervallen vorzunehmen, was mit dem Risiko verbunden ist Sensor-Signale zu verpassen, sondern durchgängig zu operieren.

Aufbau der SOTB-MCU 
 
Bild 2 zeigt den Aufbau der in 65-nm-CMOS gefertigten MCU, die aus zwei unterschiedlichen Transistor-Arten besteht. Der SOTB-Teil (links im Bild) bildet die arm-Cortex-M0+-CPU mitsamt der sie umgebenden Logik sowie das SRAM ab. Die Gate-Länge bträgt 60 nm, unterhalb der Gate-Elektrode befindet sich eine 12 nm dicke SOI-Schicht, die einen Ladungsträgerkanal ohne Dotierung darstellt. Dieser Trick ist wichtig, da man damit die Variationen der Schwellenspannungen über eine große Anzahl von Chips gering halten kann, was wiederum dazu führt, dass man mit geringeren Versorgungsspannungen arbeiten kann, um auch den Worst-Case abbilden zu können. Unterhalb von Source, Drain und der SOI-Schicht unterhalb des Gates befindet sich die vergrabene Oxid-Schicht, welche 10 nm dick ist, das Gate-Oxid selbst ist 2 nm dick. In Summe werden in dem Chip 7 Metallschichten verbaut.

Unterhalb der Oxid-Schicht findet sich das sogenannte Back-Side-Gate, über das dank der dielektrischen Isolation der Regionen Pwell und Nwell von Source und Drain eine Vorspannung von -2 V angelegt werden kann. Dank der Oxid-Schicht erzielen die Transistoren mit bis zu 150 mV/V einen fast dreimal so hohen Body-Bias-Koeffizienten Gamma wie Transistoren, die in 65-nm-Bulk-CMOS gefertigt werden.

Die Auswirkungen zeigt Bild 3. Schon mit einer Body-Bias-Spannung von 0 V reduziert sich die Variation der Schwellenspannungen, allerdings befinden sie sich jetzt absolut gesehen in einem Bereich, wo vergleichsweise hohe Leckströme auftreten. Legt man dann eine Body-Bias-Spannung von -2 V an, erhöhen sich die Schwellenspannungen vom Absolutbetrag um rund 0,2 V, was zu reduzierten Leckströmen auf der einen Seite (linker Bereich in Bild 3) führt, und auf der anderen Seite aber im rechten Bereich unterhalb der Schwellenspannungen bei Bulk-Silizium bleiben, so dass eine geringere Versorgungsspannung und damit eine geringere Leistungsaufnahme im aktiven Modus möglich wird. Laut Renesas werden CPU und SRAM bei der Nenn-Taktfrequenz mit nur 0,75 V versorgt. Bei geringeren Taktfrequenzen sind natürlich noch geringere Spannungen möglich, so hat Renesas auf einer wissenschaftlichen Konferenz im Juli 2015 davon gesprochen, dass bei 1 MHz nur 0,22 V nötig wären, der niedrigste jemals publizierte Wert für eine Versorgungsspannung eines arm-Cortex-M0+.

Um die negative Vorspannung anlegen zu können, muss diese natürlich erstmal erzeugt werden, was seinerseits Energie verbraucht. Bild 4 zeigt den entsprechenden Generator mit zwei Ladungspumpen (DSCCP), deren Ausgänge zu den entsprechend voreingestellten Vorspannungen korrespondieren. Getrieben wird die Ladungspumpe über zwei Ringoszillatoren. Der ganze Block soll weniger als 100 nA aufnehmen.

Wie in Bild 2 ersichtlich ist, werden Analog-Teile der MCU, Flash-Speicher und I/Os aus herkömmlichen Bulk-Transistoren aufgebaut. Diese werden wie gewohnt mit 3,3 V versorgt, die Gate-Länge beträgt 400 nm und die Dicke des Gate-Oxids 7,5 nm.

Energy-Harvesting- Controller und Startup

Im Gegensatz zur Batterie, die, solange sie noch Energie gespeichert hat, 24 Stunden an 7 Tagen liefert, ist dies bei geernteter Energie nicht der Fall. Es kommt vor, dass temporär gar keine Energie zur Verfügung steht und dann wieder ein Energieüberschuss. Um aufwendige externe Schaltungen zum Energiemanagement zu vermeiden, hat Renesas in die MCU einen SOTB-Embedded-Controller implementiert, der diverse Energieproduzenten flexibel managt und mit nur wenigen externen Komponenten, unter anderem einem Kondensator, in dem überschüssige Energie gespeichert werden kann, auskommt. Die MCU wird dann je nach Ladezustand und gerade verfügbarer geernteter Energie aus einer oder mehreren Quellen versorgt, wobei die ersten Derivate nur aus einer Quelle gespeist werden können (mehr dazu später im Abschnitt Roadmap).

Eine weitere Herausforderung bei Energy-Harvesting-Lösungen besteht im Hochfahren der MCU. Beim Hochfahren der Versorgungspannung geht sie vom inaktiven Zustand in den Reset-Bereich und dann in den normalen Betriebszustand über. Katastrophal wirkt sich bei einer Energy-Harvesting-Versorgung ein Einschaltstromstoß aus, da die Versorgungsspannung auf ein Niveau zusammenbrechen kann, das die MCU in den Reset-Zustand zurückführt mit der Folge, dass der reguläre Betriebszustand erst gar nicht erreicht wird.

Der Energy-Harvester-Controller hat daher einen Schaltkreis, der die einzelnen MCU-Teile wie Oszillator, Speicher und I/Os zeitlich sequentiell mit Spannung versorgt um einen Einschaltstromstoß zu vermeiden.

Die Roadmap 

Bild 5 zeigt die Roadmap der SOTB-Controller. Die ersten Derivate sind diejenigen, die wir in diesem Artikel beschrieben haben. Sie zielen auf batterie- und wartungsfreie Systeme, die aus einer Energy-Harvesting-Quelle gespeist werden und haben, soweit man das so nennen möchte, zwei Nachteile: Zum einen ist arms-Cortex-M0+, was das Thema Security angeht, anders als die neuen Cores Cortex-M23 und –M33 nicht mit arms-TrustZone-Technologie, die eine weitgehende Isolierung von kritischen Codeteilen ermöglicht, ausgestattet. Zum anderen fehlt die Möglichkeit, von Sensoren gewonnene und wie auch immer aufbereitete Daten zum Beispiel mittels BLE auf Drittgeräte zu übertragen. Die generelle Bemusterung dieser Chips wird Mitte 2019 beginnen, aktuell verschickt Renesas Muster an einige wenige ausgewählte Kunden. Dies wird sich mit der 2. Generation der MCUs ändern: Dank weiterer Entwicklungsfortschritte im Design und schrumpfender Prozessgeometrien (ich tippe auf 40 nm) werden diese Derivate nicht nur mit Cortex-M33 ausgestattet, sondern auch mit einem HF-Funkmodul und BLE. Der Energieverbrauch wird dabei – eine andere Alternative gibt es ja auch nicht, da die geerntete Energie nicht steigt – ähnlich zu dem der 1. Generation bleiben. Der EH-Controller wird erweitert, sodass auch mehrere Energie-Quellen genutzt werden können. Neben Solar, Wasser und Druck aus der 1. Generation kann hier dann auch Energie aus Vibrationen geerntet werden. Der Cortex-M33 [1] hat zumal deutlich mehr Möglichkeiten als der Cortex-M0+ auf Grund seiner um Faktor 1,6-mal höheren Rechenleistung pro MHz (3,96 CoreMark/MHz gegenüber 2,46 CoreMark/MHz), zudem ist er dank der Implementierung von TrustZone bestens auch für sehr sicherheitssensitive Anwendungen geeignet.

Die 2. Generation adressiert natürlich auch dank der deutlich höheren Security-Eigenschaften der CPU neue Märkte wie Smart Home, Smart Building oder Healthcare, wo einerseits Daten gefunkt werden müssen und/oder andererseits extrem hohe Sicherheitsanforderungen an die Datensicherheit und gegen Hacker bestehen.

Die 3. Generation, die ab 2022 am Markt sein soll und nach unserer Einschätzung in 28 nm gefertigt werden wird, setzt dann noch einmal einen drauf: arms Cortex-M7 bietet eine Rechenleistung von 5 CoreMark/MHz, zudem wird auf der HF-Seite auch LPWAN integriert. Auf der Energieernte-Seite wird man dann auch Temperaturunterschiede bzw. durch Bakterien erzeugte Energie nutzen können.

Highlight dieser 3. Generation wird jedoch Renesas‘ Dynamically-Reconfigurable-Processor (DRP) genannte KI-Engine, ein in Hardware gegossener Block, der bis 2022 stetig weiterentwickelt wird (Bild 6) und mit Erscheinen der 3. MCU-Generation sogar inkrementelles Lernen am Endpunkt, also außerhalb der Cloud, ermöglichen soll.

Renesas hat mittlerweile die dritte Generation des DRP entwickelt, einen dynamisch rekonfigurierbaren Prozessor, um tiefe neuronale Netze (DNNs) in eingebetteten Mikroprozessorsystemen zu beschleunigen. Eine DRP-Einheit (unterstützt 16b Gleitkomma-Daten) und eine neu entwickelte Multiply-and-Accumulate (MAC)-Einheit sind eng integriert, um eine hohe Vielseitigkeit, hohe Leistung und DNN-Verarbeitung mit niedriger Latenz zu erreichen. Der Kern zeichnet sich auch durch einen schmalen, bitbreiten Streaming-Datenaustauschmechanismus zwischen den beiden Einheiten aus. Es werden nicht nur grundlegende 16b Gleitkomma-Berechnungen, sondern auch binärisierte DNN-Inferenzberechnungen unterstützt.

Der DRP ist ein programmierbarer HW-Kern mit einer Reihe von Prozessor-Elementen (PEs), Multi-Kontext-Datenpfaden und einer Zustandsmaschine, die eine dynamische 0-Zyklus-HW-Rekonfiguration ermöglicht (Bild 7). Dazu gibt es einen hochautomatisierten Compiler, der HW-Design in C-Sprache ermöglicht. DRP wurde bereits erfolgreich als rekonfigurierbarer Beschleuniger für zum Beispiel die Bildverarbeitung in Digitalkameras oder Handys in Kombination mit einer DMA-Engine zum Streaming von Ein-/Ausgabedaten eingesetzt. Die Zustandsmaschine wird STC (State Transition Controller) genannt und steuert die Reihenfolge der Verarbeitung. Außerdem zeigt der STC Verarbeitungsinhalte an, indem er bei jedem Zyklus einen Zustand an den Datenpfad sendet. Der Datenpfad besteht aus Arrays von PEs und Speichern, dazu gibt es noch zwei 32-bit-Dividierer und 32-bit-ALUs.

Das Grundelement PE ist grobkörniger, ein LUT eines FPGAs und aus einer Kombination von Registern, Multiplexern und Shiftern. Dies führt zu einer hohen Leistung für komplexe Berechnungen. Ein PE besteht aus einer Arithmetik- und Logikeinheit (ALU), einer Datenmanipulationseinheit (DMU) und zwei Register-File-Einheiten (RFUs), die 16 Bit Daten speichern. Die ALUs und DMUs innerhalb der PEs arbeiten mit 16-bit-Werten. Darüber hinaus gibt es eine Reihe von programmierbaren Verbindungen zwischen PEs und Speichern. Durch die flexible Verbindung von PEs und Speichern realisiert der Datenpfad verschiedene Verarbeitungen und kann mehrere Berechnungen parallel durchführen. Auf diese Weise variiert der Verarbeitungsinhalt, indem er den Zustand des Datenpfades bei jedem Zyklus ändert.

Bild 8 zeigt den prinzipellen Aufbau seiner dynamischen Rekonfigurierbarkeit. Die so genannte dynamische Rekonfiguration wird ja auch bei FPGAs verwendet, wobei ein FPGA nur einmal vor seiner Ausführung konfiguriert wird. Hier können bis zu 64 Konfigurationen, das heißt, Hardware-Informationen, in dem DRP-Speicher gespeichert werden. Die State-Machine kann ihren Status innerhalb eines Taktzyklus wechseln (gelber Pfeil in Bild 8). Dazu kann auch noch dynamisch während der Ausführung eine weitere Konfiguration aus externem Speicher geladen werden (lila Pfeil in Bild 8). Das Laden und Ersetzen von einzelnen Konfigurationen wird von der CPU gesteuert.

Fazit 

Renesas nennt seine neue MCU-Familie nicht Ultra-Low-Power (ULP), sondern Extrem-Low-Power, da der Energieverbrauch nicht mit den ULP-Controllern der Konkurrenz zu vergleichen sei. Ein Vergleich ist seriös nicht möglich, da es keinen Benchmark gibt, dessen Workload die mit diesen MCUs adressierten Anwendungen abbildet. Der ULPMark von EEMBC ist nach unserer Einschätzung nicht für Vergleiche mit ULP-MCUs von ST Microelectronics, Microchip unter anderem geeignet, auch wenn sich der RF70E der ersten Generation nach unseren Kalkulationen mit einem Score von mindestens 400 im ULPMark-Core-Profile in der Spitzengruppe platzieren würde und die 2. Generation mit der um Faktor 20 verkürzten Aufwachzeit vermutlich sogar einen Score von 1000 erreichen könnte.

Die SOTB-MCUs sind auf jeden Fall ein sehr interessanter Ansatz, um Energy-Harvesting nutzen zu können, lassen wir uns überraschen, welche Anwendungen sich Embedded-System-Hersteller einfallen lassen, um ihre inneren Werte auszureizen. (fr)

Referenzen 
[1] Arms Cortex-M33: https://www.elektroniknet.de/design-elektronik/halbleiter/cortex-m23-und-m33-sind-erste-armv8-m-cpus-135091.html