System-on-Chip-Entwicklung Software vor Hardware

Mittlerweile steigen die Kosten für die Software-Entwicklung bei Systems-on-Chips deutlich schneller als für das Erstellen der Hardware. Die zurzeit angewandten Entwicklungsverfahren können die notwendige Leistung für softwareintensive SoCs für Smartphones, Tablet-PCs und ähnliches bei aggressiven Zeit- und Kostenzielen kaum erreichen.

Oft wird Software zu spät im Prozess entwickelt, in einigen Extremfällen erst nach der Verfügbarkeit des Halbleiters, obwohl die Software die Gesamtleistung und den Funktionsumfang des SoCs stark beeinflusst.

Bild 1 (unterste Zeile) verdeutlicht diesen SoC-Entwicklungsablauf. Im konventionellen SoC-Flow erfolgt die Softwareentwicklung und die Verifikation erst, nachdem der Halbleiter verfügbar ist.

In den vergangenen zehn Jahren wurden große Anstrengungen unternommen, um die Softwareentwicklung im Entwicklungsprozess vor die Fertigstellung des Halbleiters zu verlagern, und zwar mit virtuellen Softwareplattformen, FPGA-Prototyping-Umgebungen und 
Hardware-Emulation. Dieser um die Software erweiterte SoC-Ablauf (mittlere Zeile) ist heute gängige Praxis bei vielen Halbleiterunternehmen.

Trotz der Bemühungen, die Softwareentwicklung im Prozess weiter nach vorne zu verlagern, hat die Menge der Software, die vor der Fertigstellung des Halbleiters ausgeführt werden muss, zugenommen. In vielen Fällen wachsen die Anforderungen der wachsenden Softwarekomplexität schneller, als die erreichte Vorverlagerung Lösungen anbieten kann. Der Grund ist offensichtlich: Die Verfügbarkeit von leistungsfähigen Betriebssystemen wie »iOS« von Apple oder Open-Source-Software wie »Linux« und das daraus abgeleitete »Android« ermöglicht die Entwicklung von Konsumgütern wie Smartphones und Tablet-PCs in großem Maßstab.

Da immer mehr Transistoren verfügbar sind, integrieren die Halbleiterentwickler zusätzlich auch leistungsfähige Multicore-Prozessoren und Hardware-Subsysteme, die für Grafik, Videobearbeitung und drahtlose Vernetzung eingesetzt werden. Diese wiederum benötigen ebenfalls eine Unterstützung durch Software, um die neuen Hardwarefähigkeiten vollständig nutzen zu können. Somit muss eine riesige Menge leistungsfähiger und weit verbreiteter Systemsoftware für eine immer leistungsfähigere SoC-Hardware angepasst und optimiert werden, und das in immer kürzerer Zeit, um die immer kleiner werdenden Marktfenster zu erreichen.

Das Problem ist, dass die Betriebssysteme riesige Mengen von Software erfordern. Hunderte Megabyte ausführbaren Codes müssen abgearbeitet werden, damit das Softwareteam die von der SoC-Hardware abhängige Software entwickeln, testen und optimieren kann. Die Ausführung tausender Befehle mittels einer 10-kHz-Simulation ist wenig praktikabel, denn es sind Milliarden von Befehlen auszuführen, um Android booten sowie Systemsoftware und Apps auf dem zu entwickelnden Baustein ausführen und debuggen zu können. Die Emulation ist eine erste Lösung und bietet Ausführungsgeschwindigkeiten im Megahertzbereich an. Trotzdem kann das Laden eines vollständigen Linux, Android oder iOS Stunden dauern. Ein FPGA-basiertes Prototyping kann die Ausführungsgeschwindigkeit bis um einen Faktor 10 erhöhen, erlaubt aber gegenüber der Simulation oder Emulation einen geringeren Analyse-Einblick in die Hardware. Zudem ist sie deutlich später im Projekt verfügbar, wenn die Hardware-Beschreibungen bereits ausgereifter und stabiler sind.

Diese Anforderung hinsichtlich der Ausführung großer Software-Stacks hat einen hohen Druck auf virtuelle Softwareplattformen, FPGA-Prototyping-Umgebungen und Hardware-Emulation zur Folge. Deren Fähigkeiten zur Ausführung von Software müssen verbessert werden, während gleichzeitig deren Genauigkeit und Analysemöglichkeit im Hinblick auf die zu entwickelnde Hardware erhalten bleiben müssen.

Ideal wäre der in Bild 1 oben dargestellte softwaregesteuerte SoC-Flow. Dieser würde eine kontinuierliche Entwicklung von Hard- und Software mit der zum jeweiligen Zeitpunkt im Flow besten verfügbaren Hardwaredarstellung und mit einer angemessenen Ausführungsgeschwindigkeit erlauben, also eine Möglichkeit zur Ausführung von Android, Windows RT und anderen großen Betriebssystemen.

Der softwaregesteuerte SoC-Flow definiert einen neuen Entwicklungsablauf und verwendet neue Tools und Verfahren, mit denen sich eine umfangreiche Systemsoftware nicht nur starten, sondern auch frühzeitig verifizieren lässt. Zudem können die Entwicklungsteams die Software frühzeitig im Entwicklungszyklus nutzen, um die Hardware über die Software zu verifizieren (softwaregesteuerte Verifizierung). Sie können außerdem die Hardware/Software-Interaktionen analysieren. Auch die an den SoC-Kunden zu liefernde Software (beispielsweise ein auf das zu entwickelnde SoC portiertes und optimiertes Android) kann entwickelt, getestet und optimiert werden. Das bedeutet, dass der Schwerpunkt auf der Softwareausführung liegt, die während aller Phasen der Hardwareentwicklung unterstützt werden muss.

Softwareproduktivität und ihre Grenzen

Die Entwicklungsproduktivität für Software zu steigern, hat sich als schwierige Aufgabe erwiesen. Frederick Brooks teilt in »No Silver Bullet – Essence and Accident in Software Engineering« die Schwierigkeiten bei der Softwareentwicklung in zwei Kategorien ein: künstliche und natürliche. Die künstlichen Schwierigkeiten ergeben sich bei der Umsetzung der konzeptionellen Darstellung der Software in die Realität, damit sich diese (korrekt) auf einer bestimmten Hardware ausführen lässt. Der größte Fortschritt hinsichtlich der Produktivität wurde durch die Einführung von höheren Programmiersprachen erreicht, die diesen Umsetzungsprozess automatisierten. Was bleibt, sind die natürlichen Schwierigkeiten sowie die These von Brooks, dass es kein Tool gibt oder geben wird, das eben solche Produktivitätsverbesserungen wie bei der Einführung von höheren Programmiersprachen auch für die natürlichen Schwierigkeiten ermöglicht.

Brooks empfiehlt eine fundierte Abwägung hinsichtlich einer eigenen Entwicklung oder des Zukaufs als effiziente Möglichkeit, die Produktivität zu erhöhen. Wenn Entwickler gewisse Softwareanteile nicht selbst entwickeln müssen, dann ist dies eine einfache Möglichkeit, deren Produktivität zu erhöhen. Ein weiterer eher mechanischer Ansatz, um künstliche Schwierigkeiten zu verringern, besteht darin, die Zeit für die Fehlersuche und Behebung und die Zeit für das anfallende Testen der Korrekturen dramatisch zu verkürzen.

Abhängigkeit von der Hardware

Zahlreiche Diskussionen mit Softwareentwicklern von Halbleiterunternehmen haben Lösungsmöglichkeiten aufgezeigt. Für die Softwareentwickler dreht sich ironischerweise alles um die Hardware. Der gesamte Softwareaufwand, von der Erstellung einfacher Treiber bis hin zu Android-Multimedia-Apps, ist von der zugrunde liegenden Hardware und deren Verfügbarkeit für die Entwickler im Softwareteam abhängig. Diese Softwareentwickler befassen sich mit großen Betriebssystemumgebungen wie Android, Linux und Windows RT, die Millionen Zeilen von ausführbarem Code beinhalten. Damit ist es entscheidend, dass die Entwicklungsumgebung die notwendige Geschwindigkeit für die Ausführung derart großer und leistungsfähiger Betriebssysteme erfüllt und gleichzeitig eine möglichst genaue Darstellung der zugrunde liegenden Hardware gewährleistet.

Bild 2 zeigt ein typisches komplexes Design mit Hard- und Softwarekomponenten. Die SoC-Hardware besteht aus verschiedenen Blöcken, einige sind spezifisch, andere werden aus bisherigen Designs wiederverwendet, manche sind zugekaufte Blöcke. Manche Hersteller betrachten das Gesamtkonzept des SoCs als wesentlich, während sich andere Hersteller auf ein besonders wichtiges Hardware-Subsystem konzentrieren und für den Rest Standardblöcke verwenden. Die meisten dieser Hardwareblöcke sind mit dem Anwendungsprozessor verbunden, was bedeutet, dass die Software des Anwendungsprozessors eine Treiberunterstützung und manchmal mehr benötigt. Dies erfordert Änderungen im Betriebssystemkernel und der Middleware, damit alle Hardwareblöcke effizient arbeiten. Manche der Blöcke enthalten ebenfalls Prozessoren, die selbst komplexe Software-Stacks ausführen.

Bild 3 (linke Seite) zeigt eine Detailansicht von verschiedenen, normalerweise für ein modernes SoC entwickelten Software-Stacks.

Wie Bild 3 zeigt, entwickeln SoC-Entwickler nicht nur Software. Es wird zudem eine bedeutende Menge von Test- und Verifizierungssoftware für den Chip entwickelt und verwendet, zusätzlich zu anderen konventionellen Hardware-Verifizierungstechniken. Es ist nicht ungewöhnlich, dass Linux als »Test-Betriebssystem« auf ein neues SoC portiert wird, da es sehr umfangreiche Werkzeuge und Ausführungsfunktionen beinhaltet und dadurch die Ausführung von Verifizierungssoftware auf einem neuen Baustein stark vereinfacht. Es ist nicht vorgesehen, dass dieses Linux jemals an einen Kunden ausgeliefert wird; hier geht es nur um eine interne Verwendung. Diese softwaregesteuerte Verifizierung ist ein wichtiger Anwendungsfall und unterliegt derselben Genauigkeit und denselben Geschwindigkeitsanforderungen wie der kundenspezifische Software-Stack des SoCs. 

Lehren für die Hardwareentwicklung

Bild 2 zeigt die zahlreichen IP-Blöcke, aus denen ein modernes SoC besteht – Wiederverwendung ist auch bei der Hardwareentwicklung üblich. Eine weitere sinnvolle Lektion aus dem Softwarebereich ist die Erhöhung der Abstraktionsebene, um neue SoC-Blöcke zu implementieren. Wie RTL (Register Transfer Level) für einen Hardwareentwickler, so kann Assembler als vergleichbarer Abstraktionsgrad für einen Softwareentwickler betrachtet werden. Der Umstieg auf eine Synthese auf einer höheren Ebene wie SystemC sowie Tools wie »C-to-Silicon« von Cadence stellen den nächst höheren Abstraktionsgrad dar.

Die Verwendung von prozessorbasierten, softwareintensiven Blöcken ist ein anderer Ansatz. Ein Großteil der Funktionen verschiebt sich dann in die Software. Diese wird in C oder C++ erstellt und läuft auf einem speziell entwickelten und optimierten Prozessor, um die Funktion des Blocks mit nahezu RTL-Geschwindigkeit auszuführen. Der »Tensilica Xtensa«-Core von Cadence und »ARC« von Synopsys sind gute Beispiele für diesen Ansatz.

Das oben angeführte Modell von Brooks zeigt auch, warum in der »klassischen« EDA-Welt die Tools weiterhin die Produktivität der Entwickler steigern: Sie halten mit jeder Änderung in der Halbleiter-Prozesstechnologie Schritt. Der Backend-Entwicklungsprozess (Place&Route, Timing-Closure usw.) für Halbleiter wird von künstlichen Schwierigkeiten dominiert: den physischen Änderungen im Halbleiterprozess durch den Umstieg auf neue Fertigungstechnologien. Wie Brooks sagt, sind es diese künstlichen Schwierigkeiten, die dazu beitragen, dass sich mit den Werkzeugen deutliche Produktivitätssteigerungen erreichen lassen. Die EDA-Unternehmen nutzen diese Tatsache und stellen kontinuierlich neue Werkzeuge zur Verfügung.

Wo die SoC-Entwicklung durch die Physik dominiert wird, zum Beispiel bei Place&Route, Timing-Closing und anderen künstlichen Schwierigkeiten, lassen sich weiterhin Produktivitätssteigerungen bei der Entwicklung erreichen. Und wo die Hardwareentwicklung von essenziellen Schwierigkeiten dominiert wird, ermöglichen eine IP-Wiederverwendung und der Zukauf von IP Verbesserungen. Da immer mehr Hardware in Form von Software dargestellt wird, beim prozessorbasierten Blockansatz sogar immer als Software, wird die Ausführung der Software während der Entwicklung selbst auf der reinen Hardwareseite zunehmend wichtiger.

Der gesamte Ablauf

Die rechte Seite von Bild 3 zeigt einen softwaregesteuerten Flow und dessen Abhängigkeit von den Softwareprodukten für ein typisches SoC in einem mobilen Gerät. Virtuelle Plattformen, Emulation und FPGA-Prototyping (und der Halbleiter selbst) stellen eine Software-Ausführungsumgebung zur Verfügung, die sich für verschiedene Stufen des Entwicklungsablaufs eignet. Ein wichtiger Aspekt bei einem softwaregesteuerten SoC-Flow ist die Beobachtung, dass ein großer Prozentsatz der Millionen von Anweisungen, die beim Laden von Android ausgeführt werden, nur einen kleinen Teil der SoC-Hardware nutzt, hauptsächlich den Prozessor und Speicher. Der softwaregesteuerte SoC-Flow nutzt dies, indem diese Elemente einer schnelleren und damit aber weniger genauen Simulationsumgebung zugeordnet werden. Zum Beispiel wird ein ARM-»Fast Model« zusammen mit seinem Speicher aus der Emulation herausgenommen. Dieser hybride Ansatz wird sorgfältig umgesetzt und kann so perfekt mit dem Rest des RTLs interagieren, das in einem Emulations- oder FPGA-Prototyping-System ausgeführt wird.

SoC-Designs sind sich selten ähnlich, sodass die Konfiguration immer optimiert werden muss. In manchen Fällen ist es möglich, mit der Zeit verschiedene Hardware-Subsysteme aus der RTL-Emulation herauszunehmen und in eine schnellere Ausführungsumgebung zu verlagern, wo Emulationsgenauigkeit weniger wichtig ist wie die Software-Ausführungsgeschwindigkeit. Idealerweise lassen sich dieselben Werkzeuge (Debugger usw.) in verschiedenen Umgebungen nutzen und ermöglichen so den Softwareentwicklern und ihren Hardwarepartnern, die beste Stelle im Entwicklungsablauf für die jeweiligen Entwicklungsaufgaben auswählen zu können.

Über den Autor:

Jim Ready ist Chief Technology Advisor Software & Embedded Systems bei Cadence Design Systems.