Bild 2 zeigt die verschiedenen Anforderungen in gesamten Ablauf, der vom Konzept bis zum fertigen Produkt reicht. Heute wird Software noch überwiegend auf der jeweiligen Hardware entwickelt, sobald diese verfügbar ist. Echte Hardware arbeitet mit der vorgesehenen Geschwindigkeit – was vorteilhaft für die Software-Entwicklung ist – allerdings ist das Debugging nicht ganz so einfach, da man nur schwierig in die Hardware hineinsehen kann. Noch entscheidender ist, dass durch diese Art der Software-Entwicklung diese erst zum spätmöglichsten Zeitpunkt verfügbar ist und damit Hardware-Änderungen immer ein Re-Design erfordern.
Im Gegensatz dazu erlaubt das virtuelle Prototyping eine Software-Entwicklung zum frühest möglichen Zeitpunkt. Das Software-Debugging ist hervorragend und schnell, aber die Hardware-Genauigkeit und ein detailliertes Debugging sind unpraktisch, wodurch eine Hardware-Verifikation unmöglich wird. Sobald im Design-Verlauf das Register-Transfer-Level-Modell (RTL) zur Verfügung steht, ist der Zeitpunkt für das Set-up und das Hardware-Debugging in der RTL-Simulation optimal. Schließlich gilt RTL heute auf Grund der Genauigkeit als die Referenz. Wegen der geringen Geschwindigkeit eignet sich die RTL-Simulation allerdings meist nicht für die Software-Entwicklung. Deshalb wollen die Anwender für die Hardware-Software-Verifikation Emulations- und Hardware-basierte Beschleunigungsplattformen nutzen. Diese ermöglichen eine höhere Geschwindigkeit, die zumindest für Subsysteme ausreicht. Außerdem wird das Software-Debugging jetzt praktikabler, obwohl es nun später im Ablauf als bei der RTL-Simulation stattfindet. Hinzu kommen die große Hardware-Genauigkeit und gute Zeit für das Set-up, so dass ein Design schneller an die Emulations- und Beschleunigungs-Engines weitergegeben werden kann.
Für die Hardware/Software-Validierung wird eine noch höhere Geschwindigkeit benötigt, da mehr Software über eine längere Zeit ausgeführt werden muss. Hier haben sich FPGA-basierte Prototyping-Plattformen als nützlich erwiesen, die noch höhere Geschwindigkeiten ermöglichen und folglich die Produktivität bei der Software-Entwicklung und -Validierung steigern. Jedoch sind die Debug Möglichkeiten- und die benötigte Zeit für das Set-up nicht so gut wie bei Emulatoren.
Damit werden die grundlegenden Unterschiede der verschiedenen Möglichkeiten deutlich. Und zwar im Hinblick auf den Zeitpunkt der Verfügbarkeit während eines Projektes, dem Software-Debugging, der Ausführungsgeschwindigkeit, der Hardware-Genauigkeit und dem Debugging sowie der Durchlaufzeit des Designs. Darin liegt auch eine Chance und die Anwender haben auch vollkommen verstanden, dass es keine »universelle« Lösung gibt. In einer idealen Welt würden die Anwender eine nahtlose Kopplung der Engines bevorzugen, mit denen sich die jeweiligen Vorteile der einzelnen Engines kombinieren lassen.
Wie der letzte Abschnitt verdeutlicht hat, besteht eine entscheidende Chance der EDA-Industrie darin, eine engere Verbindung zwischen Hardware und Software herzustellen. Eine weitere Möglichkeit wären die Entwicklungsplattformen effizienter mit der Systemumgebung des zu entwickelnden Chips zu verbinden. Diese Herausforderung wird heute mit virtualisierten Umgebungen in virtuellen Prototypen, Verbindungen zu Real-Live-Umgebungen mit Beschleunigung, Emulation und FPGA-basiertem Prototyping, sowie einer Virtualisierung mittels Transaktions-basierter Beschleunigung adressiert.
Bild 3 zeigt einen Hardware/Software-Stack und stellt einige der heute verfügbaren EDA- und Embedded-Software-Tools den verschiedenen Komponenten eines Systems gegenüber. Wie die vertikalen Pfeile zeigen, kann EDA heute die Treiber und Betriebssysteme mit der zugehörigen Hardware gut zusammenbringen.