Startseite > Halbleiter > Mikrocontroller > ARMs Cortex-M7 - der Schlüssel zu sicherheitskritischen Anwendungen?

STM32F7 von STMicroelectronics

ARMs Cortex-M7 - der Schlüssel zu sicherheitskritischen Anwendungen?

16. September 2014, 11:47 Uhr | Frank Riemenschneider

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Neue FPU des Typs FPv5 für doppelte Genauigkeit

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 bleiben der Registersatz (schon FPv4 enthielt 16 Register für Gleitkommawerte doppelter Genauigkeit) und die Lade-/Speicheroperationen unverändert. Die existierenden 15 Rechen-Instruktionen wurden für das Rechnen mit doppelter Genauigkeit erweitert; dazu gibt es auch noch acht neue Gleitkomma-Instruktionen (Tabelle 2).
Aufgrund 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.
Wegen 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 potenzielle Sprungadressen gelesen werden. Trifft die Sprungvorhersage zu, gibt es keinerlei Verzögerung; bei einer Sprungfehlvorhersage in Abhängigkeit von 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 4×64 bit ausgestattet. Zu der in Bild 2 gezeigten 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 für Vergleiche gültige 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 im iPhone 3GS zum Einsatz kam. Der CoreMark-Wert steigert sich von 2,7 auf 4,45 (mit 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. Bild 3 zeigt sechs beliebte Benchmarks von EEMBC. Bemerkenswert ist, dass der Cortex-M7 im Schnitt 40 % schneller nicht nur als der Cortex-M4, sondern auch als der Cortex-R5 ist.
Ein weiterer Vorteil des M7 gegenüber dem M4 besteht darin, dass er weniger System-Infrastruktur zwischen Prozessor und Speicher benötigt und die zeitlichen Vorgaben mehr Zeit für Speicher-Leseoperationen lassen. In einem 40-nm-LP-Prozess bei 0,99 V Core-Versorgungsspannung und bei 125 °C soll der Cortex-M7 380 MHz erreichen, und – was sehr wichtig ist – beim optionalen Einbau der MPU oder mehr Interrupts/Prioritäts-Ebenen wird diese Frequenz nicht sinken – anders als beim Cortex-M4, der die theoretischen 320 MHz in einer tatsächlichen Implementierung bis heute nicht erreichte.