»Artemis« zu gut für Konkurrenz? ARM Cortex-A73 toppt High-End-CPUs

In einem 10-nm-Prozess sollen ab 2017 erste SoCs mit ARMs neuer High-End-CPU Cortex-A73 von vermutlich Intel-Fabriken ausgeliefert werden. Für eine maximale Energieeffizienz wurde die Architektur des A72 an der einen oder anderen Stelle sogar zurückgebaut – mit bemerkenswerten Ergebnissen.

Die Knaller-Meldung des Monats August kam aus San Francisco: Intels CEO Brain Krzanich verkündete auf der Entwicklerkonferenz IDF, dass ab 2017 ARMv8-A-basierende SoC-Designs in Intels Fabriken in einem High-End-10-nm-FinFET-Prozess gefertigt werden. Der neue Cortex-A73 wird das CPU-Herz vieler dieser Designs darstellen, weshalb die IP bereits auf eine 10-nm-Fertigung optimiert wurde. Das Wichtigste vorweg: Die unter dem Codenamen »Artemis« entwickelte ARM-CPU ist im Vergleich zu den ARMv8-Eigenentwicklungen aus den Häusern Qualcomm und Samsung sehr konkurrenzfähig. Dies war in der Vergangenheit nicht immer so.

Das Problem vieler heutiger Mobilprozessoren besteht darin, dass die maximale Rechenleistung aus thermischen Gründen nicht dauerhaft gehalten werden kann: 5 W und in Einzelfällen sogar 10 W (bei Multicore-Cortex-A15-Designs) stehen zu Buche, immer dünnere Smartphones können diese Wärme nicht mehr ableiten. Die Folge: Nach wenigen Minuten taktet die CPU herunter, bis sich die thermischen Bedingungen normalisiert haben, was das Benutzererlebnis nachhaltig trüben kann.

Das Designziel des Cortex-A73 bestand daher darin, nicht nur eine hohe, sondern eine vor allen Dingen durchgängige Rechenleistung zur Verfügung stellen zu können. Erschaffen wurde er in ARMs CPU-Designcenter im französischen Sophia-Antipolis, das schon für die 32-bit-Cortex-A12 und -Cortex-A17 verantwortlich zeichnete (daneben gibt es noch ein Designteam in ARMs Firmenzentrale in Cambridge, das A5, A7 und A53 designte, und eines im texanischen Austin, das für A15, A57 und A72 verantwortlich war – die drei größten Energiefresser in der Historie der ARM-Cortex-A-Familie).

Abgespeckte Mikroarchitektur aus Frankreich

Waren die Vorgänger Cortex-A72 wie auch A15 und A57 noch ein Design mit drei Befehlsdecodern und 15 Pipelinestufen, erinnert der Cortex-A73 eher an eine 64-bit-Version der 32-bit-CPU A17 (Bild 1). Die erste Stufe zum Laden der Befehle umfasst statt fünf nur noch vier Stufen, die Decodierstufe kann die meisten Instruktionen in nur einem Taktzyklus verarbeiten (statt in drei beim A72). Lediglich Gleitkomma-Mikrobefehle (µOps) durchlaufen eine zusätzliche Decodierstufe, sodass für diese Befehle die gesamte Pipeline zwölf Stufen lang ist.

Wie beim A17 können seitens der Reservation-Station der Gleitkomma-Pipeline zwei µOps in die Ausführungs-Warteschlange für die beiden NEON-Pipelines eingespeist werden, seitens der Integer-Reservation-Station verdoppelte sich diese Zahl jedoch auf vier µOps, wobei jede der drei Ausführungswarteschlangen mit bis zu zwei µOPs gefüttert werden kann.

Im Backend gibt es anders als beim A72, wo für Laden und Speichern separate Einheiten vorhanden waren, zwei Adress-Computation-Einheiten (ACU), die beide jeweils Laden und Speichern beherrschen. Dazu gibt es eine ALU, die neben den Basisoperationen wie Addieren, Subtrahieren und Bit-Verschiebeoperationen nur Multiplizieren kann, während eine zweite daneben nur dividieren kann. MAC-Operationen werden nicht mehr unterstützt, eine solche Instruktion benötigt die parallele Ausführung in beiden ALUs.

Bild 2 zeigt eine typische Quad-Core-Konfiguration auf Systemebene. Auffällig ist die optionale Vergrößerung des L2-Caches bis hin zu 8 MB (wie bei A17; A72: 4 MB), bekannt die Snoop-Kohärenz-Einheit (SCU) für Kohärenz zwischen den Cores und der z.  B. für Netzwerk-Anwendungen wichtige optionale Accelerated-Kohärenz-Port (ACP) für die Anbindung von Hardware-Beschleunigern, die ebenfalls den L2-Cache nutzen wollen und Kohärenz zu den CPU-Cores benötigen. Der 4-Wege-assoziative L1-Cache beträgt für Befehle nunmehr 64 KB (optional 32/64 KB bei A17; 48 KB bei A72) und wurde von ARM weiter für maximalen Datendurchsatz und minimale Leistungsaufnahme optimiert. Wenn z. B. ein Zugriff erfolgt und die datenanfordernde Quelle die Daten nicht länger benötigt, kann der Zugriff on-the-fly abgebrochen werden. Alle vier Cores und der L2-Cache teilen sich Taktfrequenz und Versorgungsspannung, sie können aber individuell per Power-Gating abgeschaltet werden.

Keine Fehlerkorrektur im L1-Cache

Um Siliziumfläche und Energie einzusparen, wurde bei der Verbindung zu Schaltmatrizen wie der CCI-400 auf einen AMBA-5-Port verzichtet und sich auf einen AMBA-4-ACE mit bidirektionaler 128-bit-Schnittstelle beschränkt. Beim L1-Cache wurde im Gegensatz zum L2 auf fehlererkennende und -korrigierende Codes (ECC) verzichtet, was den Einsatz des A73 in vielen sicherheitsrelevanten Märkten ausschließen dürfte – für diese wird es 2017 erste CPUs auf Basis der ARMv8-R-Architektur geben. Davon abgesehen ist der Cortex-A72 für Embedded- und Server-Tasks, die rechenintensive Vektor-Operationen und große Datensätze nutzen, mit seiner komplexeren Mikroarchitektur ohnehin besser geeignet.

Einen Schwerpunkt der Optimierung setzte ARM in der Befehlscode-Ladestufe auf die Vermeidung sogenannter Lücken (»Bubbles«). Diese entstehen durch Ressourcenkonflikte, wenn Zugriff auf eine Ressource benötigt wird, die bereits von einer anderen Stufe belegt ist. Diese Konflikte erfordern es, dass entsprechende Befehle am Anfang der Pipeline warten (»stallen«), was die Bubbles in der Pipeline erzeugt. Dies führt dazu, dass die Pipeline nicht optimal ausgelastet ist und der Durchsatz sinkt. Indem die Instruktionen früher als bei A17 und A72 in µOps aufgeteilt werden, konnten Pipeline-Lücken laut ARM quasi vollständig eliminiert werden.

Fast schon traditionell investiert ARM viel Zeit in die Verbesserung der Sprungvorhersage (Bild 3). Dies ist kein Wunder, führt doch jede Fehlvorhersage zum Löschen der Pipeline, was die hohe IPC (Befehle pro Taktzyklus) ruiniert. Bedauerlicherweise werden diese Verbesserungen jedoch auch regelmäßig als Staatsgeheimnis behandelt. Was wir wissen ist, dass der Sprungzieladressen-Puffer (BTAC) weiter vergrößert wurde und dass ein zusätzlicher Micro-BTAC hinzugekommen ist, der nur 64 Einträge umfasst und Geschwindigkeitsgewinne bei wenigen aber häufig angesprungenen Zieladressen bringt. Um die immer noch verbliebenen Fehlvorhersagen möglichst energieeffizient abarbeiten zu können, wurde ein Stack mit Rücksprungadressen für verschachtelte Unterprogramme eingeführt.