Am oberen Ende der Rechenleistung
40-nm-STM32H7 bringt ARMs Cortex-M7 auf 400 MHz
Fortsetzung des Artikels von Teil 2
ARMs Cortex-M7 im Detail
Wie auch der Cortex-M4 basiert der M7 auf ARMs v7E-M-Architektur, was eine hundertprozentige Code-Aufwärtskompatibilität vom M4 bedeutet (anders herum gilt das dank einiger M7-spezifischer Erweiterungen nicht). Die mit 12 Taktzyklen geringe Interrupt-Latenz des M4 konnte beim M7 sogar in manchen Fällen noch um einen Zyklus auf 11 Taktzyklen verringert werden, die Regel sind auch hier 12 Taktzyklen (gemessen von Auftreten des Interrupts bis zur Ausführung der ersten Instruktion in der Interrupt-Service-Routine). Wichtig: Diese Angaben gelten natürlich nur bei einem Null-Wait-State-Betrieb bezüglich des Speicherzugriffs.
Diese funktionalen Erweiterungen gehen – da auch ARM die Physik nicht ausschalten kann – natürlich auf Kosten der Leistungsaufnahme. Um diese trotz allem möglichst niedrig zu halten, hat ARM das M7-Design auch in diese Richtung verbessert: Drei separate Power-Domänen (Interrupts, Prozessor, Cache) und gegenüber dem M4 deutlich erweitertes Clock- und Power-Gating ermöglichen ARMs Lizenznehmern deutlich mehr Optionen in Richtung „Energiesparen“. Dazu kommen vier Energiesparmodi (Power Off, Deep-Sleep (WIC), Deep-Sleep und Sleep). Im Deep-Sleep-Modus wird der Core komplett abgeschaltet und von einem optional zu implementierenden Wake-Up-Interrupt-Controller (WIC) wieder aktiviert, was noch energiesparender ist, als wenn der interne Interrupt-Controller NVIC aktiv bleiben würde.
Neue Mikroarchitektur treibt Rechenleistung hoch
Die vom Cortex-M3 und –M4 bekannte dreistufige doch sehr einfach gehaltene Pipeline wurde beim M7 vollständige durch eine 6-stufige Dual-Issue-Pipeline ersetzt (Bild), wobei die parallele Ausführung von 2 Befehlen nicht bei allen Sequenzen möglich ist – hier ist der Compiler dafür verantwortlich, einen möglichst optimalen Code zu generieren. Allerdings sind die meisten Befehle parallelisierbar, anders als bei anderen Architekturen, wo der Compiler einige wenige quasi „magische Befehlspaare“ erzeugen muss. In jedem Fall ist auch die parallele Ausführung zweier Befehle in der Kombination Laden/Laden und Laden/Speichern möglich. Die fünf Ausführungseinheiten teilen sich in eine Einheit für Laden/Speichern, zwei ALUs, eine Einheit für MAC-Instruktionen und eine Gleitkomma-Einheit auf.
Die beiden ALUs der Integer-Pipeline unterscheiden sich dahingehend, dass eine ausschließlich für einfache Operationen vorgesehen ist und eine auch SIMD-fähig ist. Die MAC-Pipeline kann Berechnungen der Art 32 x 32 + 64 bit = 64 bit ausführen.
In der Gleitkomma-Pipeline kann parallel zur Integer-Pipeline eine MAC-Operation mit einfacher Genauigkeit pro Taktzyklus ausgeführt werden. Die Lade-/Speicher-Pipeline unterstützt die Dual-Issue-Ausführung von 32-bit-Ladeoperationen in den TCM und Datencache. Während der Cortex-M4 noch auf eine Gleitkommaeinheit des Typs FPv4 zurückgriff, die zwar Lade- und Speicheroperationen in doppelter Genauigkeit (64 bit) ermöglichte, Berechnungen aber nur in einfacher Genauigkeit (32 bit), musste die ARMv7-M-Architektur zwangsläufig in diese Richtung erweitert werden. Das Ergebnis ist eine FPU des Typs FPv5. Bei dieser bleibt der Registersatz (schon FPv4 enthielt 16 Register für Gleitkommawerte doppelter Genauigkeit) und die Lade-/Speicheroperationen unverändert. Die existierenden 18 Rechen-Instruktionen wurden für das Rechnen mit doppelter Genauigkeit erweitert, dazu gibt es auch noch 14 neue Gleitkomma-Instruktionen (Tabelle 2).
Auf Grund der Anforderung an deterministisches Verhalten handelt es sich zwangsläufig um ein In-Order-Design, bei welchem im Gegensatz zu den „großen“ Out-of-Order-CPUs der Cortex-A-Familie alle Instruktionen in der tatsächlichen Reihenfolge abgearbeitet werden. Verbessert wurde auch das sogenannte „Load-Use-Penalty“ für DSP-Code. Bislang sollte man zwischen Lade-Instruktionen und Befehlen, welche diese Daten weiterverarbeiten, möglichst andere Befehle setzen, damit der Prozessor nicht Wartezyklen einfügen muss, weil er auf die Verfügbarkeit der weiterzuverarbeitenden Daten warten muss. Beim M7 können jetzt geladene Daten unmittelbar mit ADD und MUL/MAC ohne Wartezyklen weiterverarbeitet werden, bei Laden gefolgt von Laden einer Basisadresse (Zeigeroperation) wurde die Wartezeit auf einen Taktzyklus verkürzt.
Auf Grund der verlängerten Pipeline ergab sich die Notwendigkeit einer erweiterten Sprungvorhersage, die man so bei ARMs M-Cores bislang noch nicht kannte. Dazu wurde ein 64 Einträge umfassender Sprungziel-Adressen-Puffer (BTAC) implementiert, aus dem zu einem frühen Zeitpunkt (in der Fetch-Einheit) in der Pipeline potentielle Sprungadressen gelesen werden. Trifft die Sprungvorhersage zu, gibt es keinerlei Verzögerung, bei einer Sprungfehlvorhersage in Abhängigkeit der Sprungart 4, 6 oder 7 Taktzyklen, da die Pipeline ganz oder teilweise gelöscht und neu befüllt werden muss. Um ein „Verhungern“ der Pipeline zu verhindern, wurde die Fetch-Einheit mit einer Pre-Fetch-Warteschlange von 4x64 bit ausgestattet. Zu der in Bild 2 abgebildeten Pipeline kommt wie beim Cortex-M4 noch ein Hardware-Dividierer für Integer-Divisionen in einem Taktzyklus hinzu.
Am Ende steht eine fast doppelt so hohe Rechenleistung wie beim Cortex-M4. Der legale DMIPS-Wert (also ohne Inlining oder andere Compiler-Tricks) wurde von 1,25 auf 2,14 gesteigert, das ist mehr als der Cortex-A8 liefert (2,0 DMIPS/MHz), der immerhin im iPhone 3GS zum Einsatz kam. Der CoreMark-Wert steigert sich von 2,7 auf 4,45 (mit dem ARMs Development-Studio 5.03.) bzw. von 3,4 auf 5,0 (mit dem IAR-Compiler), dazu werden natürlich auch in CMSIS implementierte Funktionen wie FIR (von 1,35 auf 0,64 Taktzyklen pro Tap) oder IIR (von 11,0 auf 9,00 Taktzyklen/Biquad bei Q15-Daten) schneller.
Jobangebote+ passend zum Thema
- 40-nm-STM32H7 bringt ARMs Cortex-M7 auf 400 MHz
- Sicherheit wird großgeschrieben
- ARMs Cortex-M7 im Detail
Lesen Sie mehr zum Thema
