Auf der Welle der Virtualisierungs-„Hysterie“

Rapid-Prototyping auf Software-Basis simuliert fast das gesamte Gerät – aber nur fast, denn die Ziel-Hardware wird nicht simuliert. Viele Probleme treten jedoch erst bei der Hard-/Software-Integration auf. Die virtuellen Prozessor-Prototypen von VaST Systems schließen diese Lücke.

Rapid-Prototyping auf Software-Basis simuliert fast das gesamte Gerät – aber nur fast, denn die Ziel-Hardware wird nicht simuliert. Viele Probleme treten jedoch erst bei der Hard-/Software-Integration auf. Die virtuellen Prozessor-Prototypen von VaST Systems schließen diese Lücke.

„Rapid Prototyping“ hat sich in vielen Bereichen der Geräteentwicklung etabliert. Dabei wird das Gerät am Bildschirm entworfen, visualisiert und getestet. Funktionen können ausprobiert werden, bevor eine erste Version des Gerätes in der Realität existiert. Die Software kann entworfen werden, während sich die Hardware noch in Entwicklung befindet. Fehler in der Spezifikation und Schwächen im Bedienkonzept treten zutage, bevor große Ressourcen in die Software-Entwicklung investiert werden. Grundlage des Rapid Prototyping ist die modellorientierte Entwicklung, wie sie üblicherweise mit UML-Werkzeugen oder Matlab/Simulink durchgeführt wird. Hierbei entsteht eine ausführbare Spezifikation, die – durch entsprechende Visualisierung ergänzt – zum virtuellen Prototpyen ausgebaut werden kann. Ein Grundkonflikt bleibt jedoch bei dieser Vorgehensweise: Rapid Prototyping und modellorientierte Entwicklung umfassen nur die Software. Der nur im Rechner existente Prototyp läuft auf dem Intel- oder AMD-Prozessor des Entwicklers ab. Das reale Gerät hat i.d.R. jedoch eine andere Hardware-Grundlage. Für fast jeden Anwendungsbereich haben die Halbleiterhersteller spezielle Chips im Angebot, die auf bestimmte Einsatzbereiche optimiert sind: ARM für mobile Geräte, PowerPC und Infineon sind bei Automobil- Steuergeräten beliebt, Mips, ColdFire, SH u.a. bieten je nach integrierter Peripherie Lösungen für fast jede erdenkliche Geräteart. Die entwickelte Software wird auf dem Entwicklungsrechner für das Zielsystem compiliert und übertragen.

Genau an dieser Stelle treten jedoch die meisten Probleme auf. Hier treffen Theorie und Praxis aufeinander: die theoretisch voll funktionstüchtige Software und der Prozessor aus der realen Welt. Ein solch realer Prozessor hat ein bestimmtes Timing-Verhalten, er optimiert den Ablauf von Instruktionen, indem er die Reihenfolge der Abarbeitung verändert, Warteschleifen bei Cache-Misses dreht, weil ein Sprung zu einer unerwarteten Zieladresse aufgetreten ist, usw. Diese „Macken“ werden von den gegenwärtigen Software-Tools nicht berücksichtigt. Möglich ist dies nur, wenn auch der Prozessor und seine Peripherie im Prototypen mitsimuliert werden. Genau darauf hat sich die Firma VaST Systems (www.vastsystems.com) spezialisiert.

Zyklusgenaue Simulation

VaST bietet sog. „virtuelle Prototypen“ von Prozessoren an (Bild) und arbeitet dazu mit Freescale, Renesas, Infineon und NEC zusammen. Die VaST-Prototypen modellieren den gesamten Prozessor so detailliert, dass eine zyklusgenaue Simulation möglich wird. Caches, Register, Pipeline, TLB (Translation Lookaside Buffer), BTB (Branch Target Buffer, Speicher für Sprungziele) – alles ist in den Modellen von VaST nachgebildet. Dementsprechend werden auch alle Effekte simuliert, die sonst erst bei der Hard-/ Software-Integration auftreten. Da die „virtuellen“ Prozessoren auf dem Entwicklungsrechner – also einem Inteloder AMD-System – nachgebildet werden, bezeichnet VaST seine Modellbildung als „Virtualisierung“. Dieser Begriff ist allerdings etwas irreführend, denn mit dem Begriff „Virtualisierung“ verbindet man eine virtuelle Maschine mit eigenem Speicher und Betriebssystem und Rationalisierungseffekte durch das Zusammenfassen mehrerer virtueller Maschinen, die auf einer gemeinsamen Hardware laufen. Als virtuelle Maschinen können die VaST-Prototypen durchaus durchgehen, aber ihre Zielrichtung ist nicht die rationelle Nutzung von Hardware im Sinne einer Gerätekonsolidierung, sondern die möglichst präzise Nachbildung der Prozessorinterna. Insofern trifft das Stichwort „Emulation“ eher den Kern der Sache.

Emulation hat aber immer den Nachteil eines signifikaten Overheads. Im Falle der VaST-Technologie sind zwei Schritte nötig, um den Zielprozessor nachzubilden: die Übersetzung des Binärcodes und die Modellierung des Prozessor-Status. Der erste Schritt, die Binär-Übersetzung, ist relativ einfach zu bewerkstelligen. Hierzu müssen lediglich die Instruktionen, die für den Zielprozessor bestimmt sind, in x86-Instruktionen für den Entwicklungsrechner umgesetzt werden. Was sich sonst noch im Zielprozessor tut, die Inhalte von Registern, Buffers, Caches – das Nachzubilden ist der komplizierte Teil der Emulation, über den VaST keine detaillierten Auskünfte erteilen will. Unterm Strich lassen sich mit der VaST-Simulation auf einem zeitgemäßen x86-PC etwa Rechenleistungen des simulierten Systems von 50 bis 200 MIPS erzielen. 50 MIPS bedeuten, dass z.B. ein ARM-Cortex-M1 in Echtzeit ablaufen könnte. Leistungsfähige Embedded-Prozessoren wie eine Cortex-A8-Architektur erzielen in der Realität bis zu 2000 MIPS – hier stößt die Simulationsgeschwindigkeit sicherlich an die Grenzen dessen, was einem Entwickler zumutbar ist.

Zielrichtung Automobil

Mit den genannten Halbleiter-Partnern (Freescale, Renesas, Infineon, NEC) hat VaST Systems vier der fünf wichtigsten Automotive-Chipzulieferer an der Angel. Lediglich ST fehlt noch. Mit NEC V850 und Freescale MPC 5554 wurden jüngst zwei Automotive-Controller der Liste verfügbarer virtueller Prototypen hinzugefügt. Auch durch die Zusammenarbeit mit The Mathworks dokumentiert VaST die automobile Zielrichtung seines Werkzeugs: Die virtuellen Prototypen lassen sich nahtlos in Matlab/Simulink integrieren und verhalten sich dann wie ein Hardware-Prototyp, auf den übrigens auch die gleichen Debugger angesetzt werden können wie auf das Zielsystem – der Entwickler bleibt also bei seiner gewohnten Arbeitsumgebung.

Die Methode der „Virtualisierung“ von Prototypen erlaubt gute Abschätzungen für das Systemdesign. Für ein Infotainment-System im Fahrzeug mit unzureichender Frame-Rate kann beispielsweise simuliert werden, wie sich die Erhöhung der Taktfrequenz des Prozessors auswirkt oder ob das Hinzufügen eines Coprozessors für Grafik- bzw. Video-Verarbeitung besser wäre. Ein solches alternatives Hardware-Modell zu bauen, dauert nach Angaben von VaST etwa ein bis zwei Tage und geht also wesentlich schneller als der Bau eines Hardware-Prototyps. (Joachim Kroll)

Siehe auch:

Virtualisierung im Embedded-Umfeld