Mikrocontroller Cortex-A32: ultimativer Energiesparfuchs

Erst im Oktober 2015 hatte ARM auf seiner Entwicklerkonferenz TechCon mit dem Cortex-A35 den kleinsten und energieeffizientesten ARMv8-A-Prozessor vorgestellt. Wenige Monate später folgte nun zur Embedded World der Cortex-A32, ein weiter abgespeckter A35, gut geeignet für Embedded-Anwendungen.

Als ARM den Cortex-A35 vorstellte, einen vollwertigen 64-bit-Prozessor basierend auf dem ARMv8-A-Befehlssatz, fiel es unabhängigen Beobachtern – darunter auch ich – schwer, aus dem Staunen herauszukommen: Die Minimalkonfiguration mit jeweils 8 KB Cache für Befehle und Daten belegt lediglich 0,4 mm2 Siliziumfläche bei 28-nm-HPM-Fertigung. Im Vollausbau mit jeweils 32 KB Cache, Neon, Verschlüsselung, ACP (Accelerator Coherency Port, ein 64-bit-AXI-Slave-Port für eine DMA-Engine oder einen Nicht-Cache-Kohärenz-Master) und 1 MB L2-Cache werden nur 0,75 mm2 Chipfläche belegt, d. h. mit identischer Konfiguration ist der Core nur 25 % größer als ein 32-bit-ARMv7-Cortex-A5 und 35 % größer als ein A7.

Dazu ist der Cortex-A35 mit 90 mW Leistungsaufnahme bei 1 GHz Taktfrequenz und 6 mW in seiner Minimalkonfiguration bei 100 MHz im Schnitt rund 32 % energiesparender als ein ARMv8-A-Cortex-A53 und 10 % weniger leistungshungrig als ein Cortex-A7. Kein Wunder, dass große Smartphone-Hersteller wie MediaTek sofort auf den Cortex-A35-Zug aufsprangen und bereits im 2. Halbjahr 2016 erste Geräte auf den Markt kommen werden.

ARM jedoch musste feststellen, dass der minimalistische Cortex-A35 für den Embedded-Markt noch immer zu groß ist. Insbesondere 64-bit-Instruktionen sind in dieser konservativen Welt noch längst nicht angekommen. Daher wurde der Cortex-A35 in der einen und anderen Weise kastriert und fertig war der Cortex-A32, der zur diesjährigen Embedded World vorgestellt wurde und dem A35 nach nur sechs Monaten den Rang als energieeffizientesten ARMv8-A-Core abgelaufen hat.

Konkret kappte ARM das Design des A35 um den 64-bit-Betriebszustand AArch64, also um die 32 64-bit-Register X0 bis X31 und das AArch64-Exception- und Privileg-Modell mit seinen vier Exception-Ebenen (0–3), welche die acht verschiedenen Prozessor-Modi in ARMv7 ersetzen – es handelt sich somit um einen reinen 32-bit-Prozessor. Dazu gibt es für Vektor-Befehle nur 16 statt 32 128-bit-Register (Bild 1). Eine der häufigsten Fragen lautet daher, was an dem 32-bit-Betriebszustand AArch32, den der Cortex-A32 ausschließlich unterstützt, besser sein soll als an der im A5, A7 u. a. implementierten 32-bit-Architektur ARMv7.

Zunächst einmal ist ARMv7 zweifellos ein brauchbarer RISC-Befehlssatz, der aber einige eher unattraktive Eigenschaften hat, die mit den Idealen einer RISC-Architektur kollidieren und reale Implementierungen erschweren. Dies ist kaum verwunderlich:Die meisten RISC-Architekturen zeigten Macken, die insbesondere aus der Historie stammten.Und bei ARM ist das nicht anders. Viele der Merkwürdigkeiten bei ARM sind das Ergebnis der Fokussierung auf Embedded-Computing wie Registerbänke für die schnelle Interrupt-Verarbeitung.

Das zu ARMv7 kompatible AArch32 enthält ebenfalls 13 Allzweck-Register (R0–12), den Programmzähler (R15) und zwei Registerbänke, welche Stapelzeiger (R13) und Link-Register (R14) enthalten. Die Benutzer- und System-Modi teilen sich diese 16 Register und ein Programm-Status-Register (PSR). Der schnelle Interrupt-Modus (FIQ) teilt die Register R0 bis R7 und den PC mit seinen eigenen privaten R8 bis R14 und dem gesicherten PSR. Alle anderen Exception-Modi haben private Registerbänke und gesicherte PSRs. Dieses komplizierte Register-Banking war eine der Techniken, die ursprünglich verwendet wurden, um die Latenzzeiten bei Exceptions zu reduzieren, was ARM besonders für Embedded-Controller geeignet machte. Dies hat jedoch den Nachteil, dass mehr als 40 Register benötigt werden, von denen weniger als die Hälfte gleichzeitig verwendbar sind – ein klares Problem hinsichtlich der Energie- und Flächeneffizienz. Unterstützt werden die beiden Befehlssätze A32 und Thumb32, deutliche Verbesserungen gibt es gegenüber ARMv7 jedoch in den Bereichen Gleitkomma- und Vektorverarbeitung sowie Verschlüsselung.

Die Gleitkomma-Architektur (VFP) ist für skalare Berechnungen mit einfacher und doppelter Genauigkeit bestimmt. Es gibt neue Anweisungen, um den Standard IEEE754-2008 zu erfüllen, insbesondere die Berechnung von Minimum und Maximum zweier Zahlen. Vergleiche von Gleitkommazahlen setzen nun Integer-Zustand-Flags anstatt Flags im Gleitkomma-Status-Register. Es gibt auch neue Konvertierungsanweisungen zwischen verschiedenen Gleitkomma-Formaten. ARMv8 umfasst dazu Verschlüsselungsanweisungen, die dazu bestimmt sind, bestehende Hardwarebeschleuniger zu ergänzen. ARM hat entschieden, sich mit 16 neuen Anweisungen auf AES-Verschlüsselung, die SHA1- und SHA256-Hash-Algorithmen und Galois-Felder zu konzentrieren.

Dazu gibt es noch zwei neue Anweisung Load Acquire (LD) und Store Release (ST). LD garantiert, dass jeder spätere Speicherzugriff (in der Reihenfolge des Programms) erst nach Abarbeitung von LD sichtbar wird. ST garantiert, dass alle früheren Speicherzugriffe sichtbar werden, bevor ST sichtbar wird. Darüber hinaus wird die Speicherfreigabe für alle Caching-Agenten im System gleichzeitig sichtbar.

Skalare Mikroarchitektur

Um das Design so einfach wie möglich zu gestalten, griff ARM wie schon beim A35 auf eine skalare Mikroarchitektur ähnlich der des Cortex-A5 zurück. Neben der AArch32-ARMv8-Kompatibilität gibt es allerdings diverse Verbesserungen, die man erstmals beim A53 sah, wie den optimierten Daten-Prefetch und eine leistungsfähigere Stromversorgung, dazu später mehr.

Um die Energieeffizienz im Vergleich zum Dual-Issue-A53 zu erhöhen, kann der A32 in den meisten Fällen nur eine Instruktion pro Taktzyklus ausführen, dies betrifft u. a. ALU- und Lade/Speichern-Befehle. Eine Verzweigung kann hingegen parallel zu einer anderen Instruktion ausgeführt werden. Für diese Fälle hat die CPU zwei Befehlsdecoder, aber nur eine Haupt-Execution-Engine, die eben nur einen Befehl pro Taktzyklus ausführen kann. Wie Bild 2 zeigt, nutzt der A32 dieselbe In-Order-8-stufige Pipeline wie der A53 und A35, was bedeutet, dass er in einem 28-nm-HPM-Prozess rund 2 GHz erreichen sollte. Die Instruktionen werden aus dem L1-Cache geladen und in eine Warteschlange für die spätere Decodierung eingestellt. Um Energie und Siliziumfläche einzusparen, ist die Warteschlange wie auch beim A35 kleiner gegenüber dem A53. Die Fetch-Einheit ist für eine – laut ARM wie auch immer verbesserte – Sprungvorhersage verantwortlich und lenkt die zu ladenden Befehle entsprechend um. Die Decoder verarbeiten ARMv7-A-, ARMv8-A-AArch32- und Thumb-32-Befehle und wandeln diese in Micro-Ops um, damit die Ausführungseinheit nur einen einzigen Instruktionssatz abarbeiten muss statt zwischen drei ISAs wechseln zu müssen. Direkte Verzweigungen werden erst gar nicht in die Exekutionspipeline weitergeleitet und bedingte Verzweigungen werden so schnell wie möglich verarbeitet, sobald die Bedingung erzeugt wurde.

Integer-Instruktionen benötigen bis zu zwei Pipeline-Stufen, was den Shift- und Operate-Befehle von ARMv7 geschuldet ist. Eine große Verbesserung gegenüber dem A7 ist auch die gemeinsame Pipeline für Gleitkomma- und »Neon«-Befehle: Während letzterer bei doppelter Genauigkeit fünf Taktzyklen benötigte und bei einfacher Genauigkeit zwei, werden diese Befehle beim A32 in einem Taktzyklus verarbeitet.

Ein weiterer Fortschritt gegenüber dem A7 ist das Speicher-Subsystem. Werden mehrere aufeinanderfolgende Lade-Befehle erkannt, werden die Daten vom Speicher in den L1-Datencache geladen, um die Anzahl der Cache-Misses zu reduzieren. Es können gleichzeitig vier unterschiedliche Datenströme verwaltet werden. Für den Fall eines Cache-Misses wurde der L2-Lese-Schreibpuffer auf 32 oder 16 Einträge (Lesen/Schreiben) erweitert. Dazu wurde der TLB auf 512 Einträge erweitert. In Summe konnte gegenüber dem A7 eine bis zu 3,75-mal höhere Bandbreite ermittelt werden, was angesichts des eher am A53 angelehnten Speichersubsystems zu erwarten war.

Vom A53 stammt auch die integrierte Stromversorgungs-Einheit (PMU). Diese implementiert für unterschiedliche Power-Domänen wie jeden einzelnen Core verschiedene Power-Stati (Bild 3), um die Leistungsaufnahme in Abhängigkeit des Workloads zu minimieren. Über einen »Governor«-Block wird hardwareseitig der Eintritt/Austritt aus einem Retention-Status gesteuert (Bild 4), in welchem im Gegensatz zum vollständigen Abschalten der jeweiligen Domäne die Registerinhalte erhalten bleiben.

Als Schnittstelle für den Cortex-A32 stehen der 128-bit-AXI4 und optional ein 128-bit-ACP für I/O-Kohärenz zur Verfügung. Der A32 kann in Clustern bis zu vier Cores implementiert werden, durch mehrere Cluster kann ein Prozessor aber theoretisch auch mehr CPUs aufweisen. Um den Betrieb von mehreren Clustern zu ermöglichen, wird Kohärenz über replizierte Cache-Tags unterstützt, so dass sich Kohärenz-bezogene-Transaktionen nicht mit internen Speicheroperationen in die Quere kommen.

Klein, energieeffizient und schnell

In seiner kleinsten Konfiguration mit einer CPU, jeweils 8 KB L1-Cache für Daten und Befehle und einer 128-bit-AMBA-AXI-4-Schaltmatrix kommt der A32 bei Fertigung in einem 28-nm-HPC-Prozess mit weniger als 0,25 mm2 Siliziumfläche aus und nimmt bei 100 MHz Takt weniger als 4 mW auf. Das sind gegenüber dem A35 nochmal weniger Fläche (0,4 mm2) und Leistungsaufnahme (6 mW), was an den entfallenden Gattern für den 64-bit-Modus AArch64 liegt.

Für den Vollausbau mit 32 KB L1-Cache für Daten und Befehle, Neon, Gleitkomma-Einheit, ACP, SCU, 1 MB L2-Cache mit Fehlererkennung/Korrektur und 128-bit-AMBA-AXI-Schaltmatrix hat ARM keinen offiziellen Wert bezüglich der Die-Fläche publiziert. Wir schätzen sie auf rund 0,5 mm2, rund ein Drittel weniger als beim A35. Die Leistungsaufnahme gibt ARM bei 1 GHz mit 75 mW an, nochmal 15 mW weniger als beim A35. Bei 2 GHz schätzen wir durch die notwendige höhere Versorgungsspannung eine Leistungsaufnahme von 250mW.

Im Vergleich zu dem im Embedded-Umfeld hinreichend bekannten Cortex-A7 ist der A32 vor allen Dingen wegen seiner Gleitkomma- und Verschlüsselungsinstruktionen überlegen: 30 % schneller bei Gleitkommaverarbeitung und eine um Faktor 3,5/11 (SHA-1/AES) schnellere Verschlüsselung sind erreichbar. Bei der Integer-Verarbeitung halten sich die Fortschritte mit rund 6 % Zuwachs in engen Grenzen. Am Ende ist der A32 in Bezug auf die Energieeffizienz (Rechenleistung/W) bei 32-bit-Workloads rund 10 % besser als der Cortex-A35 und 25 % besser als der Cortex-A7.

Infolge der von den Cortex-A-CPUs bekannten TrustZone-Sicherheitstechnik ist der A32 für unterschiedliche Betriebssysteme geeignet: Er kann entweder ein Echtzeitbetriebssystem (RTOS) verarbeiten oder ein vollständiges OS wie Linux, Googles Android-basiertes Brillo für IoT, Android selbst (im 32-bit-Modus), Windows 10 IoT, Linaro oder Ubuntu Snappy OS.

Killerargument IoT?

Wie man weiß, ist die Embedded-Welt sehr preissensitiv. Die Lizenzgebühren für den A32 sind höher als beim A7, dafür ist er durch sein ARMv8-AArch32-ISA für sicherheitssensitive IoT-Anwendungen viel besser geeignet. Dazu kommt seine extreme Energieeffizienz, die ihn für batteriebetriebene Anwendungen besser geeignet macht als jede andere ARM-Cortex-A-CPU. Es würde mich daher sehr wundern, wenn nicht auch der Cortex-A32 seinen Teil zu ARMs Lizenz zum Gelddrucken beitragen würde.