Neue CPU-Architektur von ARM DynamIQ ersetzt big.LITTLE

Mehr Freiraum für SoC-Entwickler bietet ARM mit seiner neuen Mikroarchitektur „DynamIQ“.
Mehr Freiraum für SoC-Entwickler bietet ARM mit seiner neuen Mikroarchitektur „DynamIQ“.

Vor 5 Jahren stellte ARM seinen big.LITTLE-Ansatz vor, bei dem jeweils bis zu vier CPUs in separaten Clustern zusammengeführt werden konnten. Der Erfolg dieses Konzepts war trotz objektiver Schwächen groß. Der Nachfolger DynamIQ bietet deutlich mehr Flexibilität und beseitigt big.LITTLEs Schwächen.

Die neuen ARM-CPUs Cortex-A75 und A-55, die wir in den nächsten Ausgaben der DESIGN&ELEKTRONIK ausführlich vorstellen werden, können nicht mehr mit ARMs ursprünglicher big.LITTLE-Technologie verbaut werden. Sie müssen zwangsläufig den Nachfolger DynamIQ implementieren, an dem ARM seit 2013 gearbeitet hat, was angesichts der Vorteile weniger ein »müssen« als ein »dürfen« ist. 

Mit DynamIQ können statt bis zu 4 jetzt bis zu 8 CPUs in einem Cluster verbaut werden, insgesamt sind bis zu 256 CPUs in 32 Clustern möglich. Noch wichtiger ist dabei, dass jetzt auch unterschiedliche CPUs in einem Cluster gemischt werden können, was je nach Anwendungssoftware ganz neue Möglichkeiten bietet. Dazu später in diesem Beitrag.

Über die CCIX-Schnittstelle können theoretisch Multi-Chip-Designs mit Tausenden CPUs entwickelt werden. Dazu können pro Cluster bis zu 8 unterschiedliche Spannungs-/Frequenz-Domänen definiert werden, was auch bedeutet, dass bei einem 8-Core-Design in einem Cluster jede CPU individuell von der Spannungsversorgung getrennt werden (Power-Gating) und mit einer unterschiedlichen Taktfrequenz versorgt werden kann. Nur innerhalb einer Domäne müssen alle CPUs wie bei big.LITTLE mit derselben Frequenz versorgt werden. Da jede Domäne einen eigenen Spannungsregler benötigt, stellt sich in der Praxis die Frage, inwieweit diese Möglichkeiten von ARMs Lizenznehmern ausgereizt werden.

In Bild 1 ist eine 8-Core-Konfiguration dargestellt, wie sie heute ständig in SoCs zu finden ist. Bei big.LITTLE mussten diese über 2 Cluster aufgeteilt werden (1 Cluster mit 4 »big«-CPUs, 1 Cluster mit 4 »little«-CPUs oder 2 Cluster mit jeweils 4 »little«- CPUs), während sie nunmehr in einem Cluster untergebracht werden können, und zwar in jeder Kombination wie 1 Cortex-A75 plus 7 Cortex-A55, 2/7, 3/5 oder 4/4. Der große Vorteil liegt darin, dass die Kombination 1+7 die Single-Thread-Rechenleistung gegenüber einem heute üblichen 8 × Cortex-A53-Design um den Faktor 2,41 erhöht, während der Flächenbedarf an Silizium nur um den Faktor 1,13 ansteigt (im selben Fertigungsprozess und mit identischer Taktfrequenz). Wird allerdings berücksichtigt, dass die Skalierung zahlreicher Anwendungen über 8 Cores zurzeit reinem Wunschdenken entspricht, ist dies natürlich ein gewaltiger Fortschritt. Aber selbst wenn es sich um eine multicore-kompatible Anwendung handelt, steigt die Rechenleistung dank der gegenüber den A53 potenteren Cortex-A55 sowie architektonischer Vorteile der DSU (DynamIQ Shared Unit) um den Faktor 1,42 an.

Das Bild 2 zeigt eine DSU in einem CPU-Cluster. Während alle CPUs des gleichen Typs innerhalb eines Clusters einen eigenen L2-Cache aufweisen, der mit der CPU-Frequenz betrieben wird, stellt die DSU noch einen L3-Cache zur Verfügung, der von allen CPUs des Clusters geteilt wird. Jede Spannungs-/Frequenz-Domäne kann synchron oder asynchron zur DSU konfiguriert werden, wobei ein synchroner Betrieb für alle CPUs dieselbe Taktfrequenz erzwingt.

Über zwei jeweils 128 bit breite AMBA-5-ACE-Ports oder einen 256 bit breiten AMBA-5-CHI-Port ist die DSU an die cache-kohärente Schaltmatrix angebunden, dies können CCI, CCN oder CMN sein. Über den bereits bekannten ACP-Port können zusätzliche Hardware-Beschleuniger angebunden werden, die ebenfalls Cache-Kohärenz benötigen. 

Neue Cache-Architektur erhöht Datendurchsatz 

Alleine die im Vergleich zu big.LITTLE engere Anbindung des L2-Caches an den Core reduziert die Latenzzeiten um rund 50 % oder mehr (Bild 3). Der L3-Cache in der DSU kann auf 1 MB, 2 MB oder 4 MB konfiguriert (oder weggelassen) werden und arbeitet 16-fach assoziativ. Technisch gesehen ist er pseudoexklusiv, laut ARM arbeitet er real und sozusagen vollständig exklusiv, das heißt, die Cache-Line einer Adresse ist nur einmal in allen Cache-Leveln vorhanden. 

Eine Cache-Line zu Adresse A im L1-Cache ist nicht zusätzlich im L2- oder L3-Cache vorhanden. Wird sie aus dem L1-Cache verdrängt, so kann sie entweder gänzlich verworfen werden, oder muss explizit in den L2-Cache kopiert werden. Dort wird somit ebenfalls eine (andere) Cache-Line verdrängt, um für die aus dem L1 Platz zu machen. Diese andere kommt nun ihrerseits in den L3-Cache, wo somit eine dritte Cache-Line weichen muss.

Der L3-Cache kann in maximal 4 Gruppen partitioniert werden, was natürlich neben Netzwerkanwendungen vor allen Dingen auch Embedded-Anwendungen zu Gute kommt – unter anderem wenn unterschiedliche ADAS-Algorithmen auf getrennten Prozessen und jeweils einer Teilmenge aller CPUs laufen. Dabei kann z. B. eine CPU 2 MB von 4 MB allokieren und bis zu sieben weitere CPUs die verbleibenden 2 MB. Eine Cache-Gruppe kann neben CPUs sogar einem Hardware-Beschleuniger zugewiesen werden, der über den ACP angebunden ist. Wenn ein Teil des L3-Caches nicht dediziert CPUs und/oder Beschleunigern zugeordnet wird, wird er automatisch den restlichen CPUs zugewiesen. Die Gruppierung erfolgt übrigens dynamisch und kann jederzeit von einem Betriebssystem oder Hypervisor zur Laufzeit verändert werden. 

Direkter I/O-Zugriff auf Caches 

Eine weitere interessante Eigenschaft ist die Fähigkeit des Systems, korrigierbare und unkorrigierbare Fehler an Software zu melden. Der L3-Cache unterstützt wie auch die anderen Cache-Level fehlererkennende/fehlerkorrigierende Codes (ECC) und Paritätsprüfung (einen Fehler korrigieren, 2 erkennen), um kompatibel zu ASIL-D-Anforderungen zu sein. 

Neu ist auch das sogenannte Cache-Stashing, bei dem eine GPU oder ein anderer Hardwarebeschleuniger über den ACP bzw. AMBA-CHI-Port direkt Daten nicht nur aus dem L3-Cache lesen oder in diesen schreiben, sondern dies auch auf den L2-Cache spezifischer CPUs ausführen können. Als Beispiel sei eine Netzwerk-Anwendung mit einer TCP/IP-Engine für die Paketverarbeitung genannt.

Wenn diese Daten statt in den Systemspeicher in den L2-Cache schreibt, wird die Geschwindigkeit erhöht und die Leistungsaufnahme reduziert, da natürlich diverse Mechanismen zur Erhaltung der Cache-Kohärenz und Ladebefehle seitens der CPU quasi übersprungen werden (Bild 4).

Um den Zugriff von Hardware außerhalb des Clusters auf den L3- oder L2-Cache zu ermöglichen, braucht es natürlich entsprechende Treiber im Kernel, welche die Prozessor- und Cache-Topologie kennen. Anders formuliert: Das OS oder Hypervisor muss um Individualcode ergänzt werden, was bei Consumer-Anwendungen hinsichtlich Time-to-Market ein K.-o.-Kriterium sein dürfte, im gemächlicheren Embedded-Markt jedoch kein Problem darstellen dürfte.

DymanIQ vereinfacht natürlich auch den Datenaustausch zwischen CPUs in einem Cluster. Die Verschiebung von Cache-Lines innerhalb eines Clusters ist schneller, als sie zwischen Clustern bei big.LITTLE zu verschieben. Dies ist der wesentliche Grund, warum ARM unterschiedliche CPUs in einem Cluster ermöglichen wollte. Einen Thread von einer »großen« CPU auf eine »kleine« zu verschieben, geht eben so viel schneller.

Bei big.LITTLE sind während des Übergangs von einem zum anderen Cluster sind für einen bestimmten Zeitraum alle Cores aktiv. In dieser Zeit werden die Caches des Clusters, zu dem gewechselt werden soll, mittels Bus-Snooping mit den Daten des L2-Caches des noch aktiven Clusters gefüllt. Da die Scheduler in Software programmiert sind, kann die Überschneidungszeit programmiert werden.

Insgesamt werden dreistellige µs-Zeiten fällig, wobei die Zeitspanne, in der die Verarbeitung tatsächlich stoppt, »nur« eine zweistellige µs-Zeit beträgt (diese Zeit wird für den Wechsel des Prozessor-Status benötigt). 

Stromversorgung vom Feinsten 

Gegenüber der Stromversorgungs-Architektur von big.LITTLE ist die von DynamIQ, umgangssprachlich gesagt, ein Quantensprung. Statt in Software wird das Cache- und Kohärenz-Management von der DSU in Hardware umgesetzt, was bei einem Wechsel zwischen Power-Status der CPUs diverse Schritte erspart, wodurch diese wesentlich schneller an- und abgeschaltet werden können als bei big.LITTLE. Bild 5 zeigt den Vergleich der Übergangsprozesse vom herkömmlichen big.LITTLE (links) und DynamIQ (rechts). Durch eine Überwachung der L3-Cache-Nutzung kann die DSU dazu den L3-Cacxhe ganz oder teilweise abschalten, um dessen Leckströme zu reduzieren. Eine Umschaltung ist zwischen den Status »vollständig an«, »halb aus/an« oder »ganz aus« möglich. Die Snoop-Control-Einheit (SCU) wurde an die neue Cache-Topologie angepasst. 

Die von der DSU belegte Silizumfläche hängt natürlich primär von der Größe des L3-Caches ab, während die Logik mit der Anzahl der CPU-Cores skaliert. Grob gesagt kann festgestellt werden, dass sie im Vollausbau mit 4 MB L3-Cache ungefähr die Fläche eines Cortex-A55-Cores belegt, während sie in der Minimalkonfiguration ohne L3-Cache etwa 50 % der Größe eines A55-Cores haben soll. 

Fazit 

Bild 6 zeigt den Vergleich der Leistungsaufnahme bei einem realistischen Muti-Thread-Szenario zwischen big.LITTLE und DynamIQ, bei dem im Wesentlichen eine CPU belastet wird. Während bei big.LITTLE durch die in Relation zur Belastung viel zu hoch getakteten Cores ständig unnötig Energie verbrannt wird, wird bei DynamIQ der Takt der Belastung angepasst, was aufgrund des quadratischen Einflusses der Frequenz in die Leistung zu deutlichen Einsparungen führt (Bild 5, unten links). 
Das erste SoC mit Cortex-A75 und -A55 und DynamIQ-Technologie dürfte Qualcomms Snapdragon-845 sein, ein 10-nm-Chip, den wir Ende 2017/Anfang 2018 erwarten und der vermutlich gerade rechtzeitig für das Samsung Galaxy S9 in Massenproduktion gehen wird.