Eine Optimierung des Systems ist laut einer von Brian Bailey, dem auf EDA spezialisierten Technologieeditor bei Semiconductor Engineering, veröffentlichten Analyse nicht mehr möglich, wenn Hardware und Software jeweils für sich betrachtet werden. Software-Arbeitslasten verändern sich schneller als die Entwicklungszyklen von Chips, während Energie, Leistung und Wärme zu miteinander verknüpften Faktoren geworden sind, die eine frühzeitige Zusammenarbeit zwischen Software- und Hardwareteams erfordern, anstatt das Design nach Abschluss jeder Phase von einem Team an das nächste zu übergeben.
Die Analyse beschreibt das wiedererwachte Interesse am sogenannten Hardware-Software-Co-Design, allerdings unter anderen Bedingungen als vor etwa 30 Jahren. Damals waren die verfügbaren Technologien nicht in der Lage, einen großen Unterschied zu bewirken, weshalb die Industrie dazu überging, vorab verifizierte IP-Blöcke zusammenzustellen und zu integrieren. Einige Überreste des früheren Ansatzes bestehen weiterhin, etwa virtuelle Modellierung sowie ungetaktete oder annähernd getaktete SystemC-Modelle. Diese Werkzeuge gelten jedoch allein nicht als ausreichend, um die heutigen realen Arbeitslasten abzubilden.
Von der Trennung der Teams zu virtuellen Modellen
Steve Roddy, Chief Marketing Officer bei Quadric, sagt, die Zeit, in der ein Hardwareteam sein Design entwickelte und anschließend an ein Embedded-Softwareteam übergab, sei seit mehr als zwei Jahrzehnten vorbei. Die virtuelle Modellierung wurde im vergangenen Jahrzehnt erweitert und umfasst nun auch physikalische Eingaben und Sensorschnittstellen, im Rahmen dessen, was als virtuelle Zwillingsmodellierung bezeichnet wird.
Die aktuelle Herausforderung ist jedoch komplexer: Systeme sind erheblich größer geworden und werden für softwaredefinierte Arbeitslasten entwickelt, während Software schneller iteriert als Hardware entwickelt wird. Dadurch wird Co-Design zu einem Prozess, bei dem die Hardware der Software ständig folgt. Arvind Srinivasan von Normal Computing zufolge haben Abstraktionsebenen, die Teile des Software-Stacks von Teilen des Hardware-Stacks trennten, historisch dabei geholfen, Komplexität zu verwalten sowie Entwicklungseffizienz und Zuverlässigkeit zu verbessern. Der Bedarf, aus jedem Teil der Toolchain die maximale Optimierung herauszuholen, insbesondere für leistungssensible KI-Arbeitslasten, verändert dieses Gleichgewicht jedoch.
Die Lösung des Problems erfordert ein umfassenderes Verständnis des Wortes „Architektur“. Es bezeichnet nicht nur die übergeordnete Systemstruktur oder die Mikroarchitektur und den Befehlssatz, sondern umfasst auch die Softwarearchitektur und die Arbeitslast, die tatsächlich ausgeführt wird. Andy Meier von Siemens EDA zufolge sollte die Auswahl der Architektur von der Anwendung oder Arbeitslast ausgehen und davon, wie diese Arbeitslast die Systemstruktur, den Befehlssatz und die verschiedenen darin enthaltenen Elemente beeinflusst.
Eine neue Spezialisierungswelle, angetrieben von Energieanforderungen
Die Analyse stützt sich auf eine Beobachtung von Tsugio Makimoto, der in den 1990er-Jahren als Chief Technology Officer bei Sony tätig war, zur Bewegung der Industrie in Wellen zwischen Spezialisierung und Generalisierung. Nachdem Universalprozessoren weite Bereiche dominiert hatten, begannen die Anforderungen an Edge-Computing und anschließend an Rechenzentren, stärker spezialisierte Lösungen voranzutreiben.
Bei Edge-Geräten steht der Antrieb im Zusammenhang mit der Verlängerung der Batterielebensdauer innerhalb der verfügbaren Leistungsgrenzen. In Rechenzentren begrenzen dagegen Leistungsdichte und Wärme die verfügbaren Optionen für den Betrieb von KI-Arbeitslasten. Infolgedessen sind Universalprozessoren allein nicht mehr die Antwort. Stattdessen entsteht der Bedarf an heterogenen Rechenzentren mit mehreren Chiptypen, wobei Arbeitslasten entsprechend den Eigenschaften jedes Chips verteilt oder gebündelt werden.
Patrick Coles, Chief Scientist bei Normal Computing, weist darauf hin, dass Grafikprozessoren möglicherweise nicht das Ende der Entwicklung des Computing darstellen, da die Hinweise auf eine zunehmende Rolle von ASICs zunehmen. Frank Schirrmeister von Synopsys erklärt außerdem, dass Hyperscaler eigene Chips und Beschleuniger entwickeln, um eine gemeinsame Optimierung von Schlüsselkennzahlen wie Leistung und Energieverbrauch zu erreichen, anstatt sich ausschließlich auf Geschwindigkeit zu konzentrieren.
Spezialisierung ist jedoch nicht nur eine technische Entscheidung. Es muss bestimmt werden, welcher Grad an Anpassung wirtschaftlich die Kosten rechtfertigt und ob er ausreichende Leistungs- und Energiegewinne bringt. Purna Mohanty, CEO von SignatureIP, weist darauf hin, dass die Komplexität der Spezifikationen dazu führen kann, dass der Kunde selbst nicht genau formulieren kann, was er benötigt. Dies erfordert eine kontinuierliche Abstimmung zwischen dem IP-Anbieter und den Kundenanforderungen sowie eine Abwägung der Vorteile vorgefertigter Lösungen gegenüber den Gewinnen aus der Entwicklung neuer Eigenschaften.
RISC-V als Beispiel für arbeitslastbezogene Anpassung
RISC-V wird in der Analyse als Beispiel für den Trend zu „für die Arbeitslast entwickelten Chips“ hervorgehoben. Unternehmen entwickeln benutzerdefinierte Erweiterungen für Kerne, um Leistung oder Energieverbrauch zu verbessern. Diese Erweiterungen erfordern jedoch ebenfalls Teile des Ökosystems, etwa Compiler und Werkzeuge für die Softwareintegration.
Andrea Gallo, CEO von RISC-V International, erklärt, dass die Verwendung benutzerdefinierter Befehle dem Unternehmen die gesamten Betriebskosten aufbürdet, einschließlich der Toolchain und der Softwareintegration. Dieser Ansatz kann ein schneller Weg zur Innovation sein. Später könnte das Unternehmen jedoch versuchen, die Erweiterung in einen Standard umzuwandeln, sodass sich die Kosten für ihre Wartung auf das breitere Ökosystem verteilen. Die Analyse weist außerdem darauf hin, dass die vorherige Kenntnis der Software-Arbeitslast eine anwendungsgerechte Auslegung der Verarbeitungselemente ermöglicht, während allgemeine und skalierbare Rechenwerke weiterhin wichtig sind, wenn unbekannte oder veränderliche Software ausgeführt wird.
Energie und Wärme erweitern den Umfang des Co-Designs
Die Auswirkungen des Co-Designs beschränken sich nicht auf die Leistung. Softwareingenieure verstehen möglicherweise die Bedeutung von Energie, verfügen jedoch nicht immer über die Werkzeuge, mit denen sie die Auswirkungen ihrer Entscheidungen frühzeitig messen können. Daher arbeiten Teams daran, während der Softwareentwicklung parallel zur Hardware Zahlen zum Energieverbrauch bereitzustellen und Kennzahlen wie TOPS pro Watt zu verbessern, nicht nur die rohen TOPS.
Die Schwierigkeit nimmt bei heterogenen Anwendungen zu, die mehrere Ebenen von Caches umfassen, ebenso wie bei weiteren Funktionen wie Design-for-Testability (DFT), da Energie und Leistung innerhalb einer realistischen Arbeitslast analysiert werden müssen, die auch diese Funktionen einschließt. Wenn sich die Analyse auf Wärme, elektromagnetische Interferenzen und multiphysikalische Aspekte ausweitet, wird die Vereinigung der Hardware- und Softwareteams zu einer neuen Einheit, der zusätzlich multiphysikalische Analysen hinzugefügt werden.
Einige an der Analyse Beteiligte erwägen den Einsatz künstlicher Intelligenz, um die komplexen Beziehungen zwischen Hardware, Software, Energie und Leistung zu verstehen. Dafür sind jedoch Daten erforderlich, die beschreiben, wie viel Energie die Software auf verschiedenen Ebenen verbraucht hat – vom Chip und Server bis zum Rack, Fahrzeug und Rechenzentrum. Bis ausgereifte, KI-gestützte Lösungen verfügbar sind, könnte die Industrie weiterhin auf die Integration von IPs und die Auswahl unterschiedlicher Spezialisierungsgrade angewiesen sein.
Die Diskussion über Matrixerweiterungen in RISC-V zeigt, dass eine einzige Lösung nicht für alle Anwendungen geeignet ist: Eine kleine Erweiterung kann den Energieverbrauch senken, während ein größerer Satz von Registern, Operationen und Akkumulatoren einen höheren Durchsatz bietet, jedoch auf Kosten der Chipfläche und des Energieverbrauchs. Die Auswahl hängt letztlich davon ab, wie Kerne und Beschleuniger verteilt werden und welche Arbeitslast angestrebt wird. Die Analyse kommt zu dem Schluss, dass der Weg zur vertikalen Integration noch lange nicht abgeschlossen ist, sich jedoch zu einer notwendigen Richtung entwickelt hat, um das Design moderner Systeme auf Software, Energie und Leistung abzustimmen.