Damit Verifikationsumgebungen während des Projektablaufs effizient wieder verwendet werden können, verlagern Entwicklungsteams heutzutage ihren Aufwand von der Benutzung klassischer, hardwareorientierter Verifikationssprachen in Software als Werkzeug für die Hardware-Software-Verifikation. Software ist somit die wahrscheinlich wichtigste neue Komponente, die mehr und mehr Einfluss auf das Chip-Design in den vergangenen zehn Jahren gewonnen hat. Die Kosten für ihren Entwicklungsaufwand und die für sie benötigte Entwicklungszeit können insbesondere in komplexen Entwicklungen im Bereich der Chips für Mobiltelefonie, Server und Netzwerke höher und länger sein als für Hardware. Wo ein Halbleiterhersteller vor 15 Jahren für seine Halbleiter-Bausteine nur Software-Treiber lieferte, erwarten Kunden heutzutage validierte Portierungen für komplexe Betriebssysteme wie Android, Linux und Windows, zusammen mit Middleware für Graphik, Netzwerk und Video/Audio Anwendungen.
Ein komplexes Beispielsystem
Abbildung 1 illustriert ein Beispielsystem aus dem Bereich der Mobiltelefonie. Ein komplexer Applikations-Prozessor besteht aus einem Multi-Prozessor-Teilsystem für die Applikationssoftware, einem Modem für die Kommunikation, anwendungsspezifischer Logik, peripherer Logik und komplexer Verbindungslogik. Der Halbleiter-Baustein muss in seiner Systemumgebung arbeiten und ist durch periphere Schnittstellen mit der Außenwelt verbunden. Zwei grundlegende Arten von Software sind wichtig im Zeitalter der „softwaregesteuerten Systementwicklung“, siehe auch Abbildung 2.
Auf den Prozessoren im Chip laufen verschiedene Sorten von Software, die Wesentlich zur Gesamtfunktion beitragen und an den Benutzer ausgeliefert werden. Zum einen wird die für den Benutzer sehr sichtbare und die gesamte Benutzerempfindung bestimmende Applikationssoftware auf dem Multiprozessor-Teilsystem ausgeführt. Hier laufen iOS, Windows oder Varianten von Android und Linux; der Benutzer sieht und benutzt die „Apps“ die er installiert hat. Zum anderen, mehr im Hintergrund und nicht direkt für den Benutzer sichtbar, läuft die Kommunikationssoftware welche die Ebenen des OSI(Open Systems Interconnection)-Software-Stapels implementiert, sowie „bare-metal“-Software, die direkt ohne Betriebssystem in programmierbare Komponenten des Chips geladen wird.
Außerdem gibt es Software, die nicht mit dem System ausgeliefert wird und nur zum Überprüfen der Hardware und seiner Interaktion mit der Software verwendet wird. Mehr und mehr Entwickler führen heutzutage softwaregetriebene Tests aus, die entweder direkt („bare-metal“) auf der Hardware oder als Software auf Android-, Windows-, Linux- oder oder sogar dedizierten Test-Betriebssystemen laufen.
Das Entwickeln einer Spezifikation bis zum Silizium einschließlich Produktion und Post-Silizium-Validierung kann für komplexe Systeme schon einmal 18 bis 24 Monate dauern.
Ein typisches Entwicklungsprojekt
Wesentliche Schritte in der Hardwareentwicklung sind die Integration von Intellectual-Property(IP)-Blöcken in Teilsysteme, Integration der Teilsysteme in Systeme-auf-Chip (SoC), sowie die Integration der SoCs in Systeme. Die schon besprochenen komplexen Software-Stapel von „bare-metal“-Software zu Betriebssystemen, Middleware und Anwendungen für die Endbenutzer werden auf den verschiedenen Prozessoren im System ausgeführt. Es gibt keinen Königsweg in Form eines einzigen Entwicklungswerkzeugs, das alle Anforderungen für die Verifikation von Hardware, Software sowie auch der Integration von Hardware und Software erfüllt, bevor ein Halbleiter-Baustein zur Fertigung freigegeben wird. Alle Werkzeuge – von virtuellen Plattformen basierend auf Simulation von Transaktionsmodellen, Simulation von RTL(Register Transfer Level)-Modellen, hardwareunterstützter Simulations-Beschleunigung, Emulation bis zu FPGA(Field Programmable Gate Array)-basierten Prototypen – haben alle ihre individuelle Stärken und Schwächen:
TLM(Transaction-Level-Modeling)-virtuelle Prototypen laufen mit Hunderten MIPS (Millionen Instruktionen pro Sekunde) und eignen sich daher gut für die Softwareentwicklung und Debug – sie bilden die Hardware zwar Register-akkurat, aber bezüglich Timings nur ungenau ab.
RTL-Simulation führt die „Goldene Spezifikation“ für die Hardware mit sehr akkuratem Debug aus und ermöglicht schnelles Laden in den Simulator sobald eine Korrektur im RTL gemacht wurde. Sie läuft aber nur im kHz- oder sogar Hz-Bereich und ist damit nicht gut verwendbar für die Softwareentwicklung, die Millionen von Zyklen benötigt, bevor der Entwickler zum Beispiel die Eingabeaufforderung für Linux erreicht.
RTL-Emulation ist ein guter Kompromiss zwischen Ausführungsgeschwindigkeit und Genauigkeit. Sie erlaubt einen guten Einblick für Debug in die Hardware und ist mit Geschwindigkeiten im MHz-Bereich auch für Hardware-Software-Integration anwendbar. Anwender berichten, dass die Abbildung von Designs in prozessorbasierte Emulation so effizient geworden ist, dass sie mehrere RTL-Versionen pro Tag abbilden können. Das macht Emulation anwendbar auch wenn RTL noch nicht stabil ist und sich noch oft ändert und kann den Debug-Zyklus stark beschleunigen. Emulation ist allerdings oft für lange Software-Zyklen nicht schnell genug und auch nicht so einfach an viele Softwareentwickler auslieferbar.
RTL-FPGA-basierte Prototypen laufen im Geschwindigkeitsbereich von 10 MHz und mehr, benötigen aber mehr Modifikation des RTL und brauchen daher länger als Emulation für die Abbildung von Designs in den Prototypen. Der Einblick in die Hardware ist auch begrenzt, sie eignen sich daher am besten für die Entwicklung von Software und für Hardware-Regressionen.
Die „Links-Verschiebung“
Innovationen in Entwicklungswerkzeugen geschehen derzeit in der Optimierung der System-Entwicklungs-Prozesse, insbesondere um ausführbare Hardware-Repräsentation früher im Entwicklungszyklus ausführen zu können – deshalb spricht die Industrie von einer „Links-Verschiebung“. Kernkriterien sind die Geschwindigkeit, um mehr Verifikationszyklen und frühere Softwareentwicklung zu ermöglichen, die Verfügbarkeit nach Projektstart und auch die Genauigkeit der Hardware-Repräsentation.
Als Innovationsbeispiel hat Cadence im September 2013 seine Emulationsplattform Palladium XP II eingeführt, mit erweiterter Kapazität – bis zu 2,3 Milliarden Gates –, verdoppelter Verifikationsproduktivität als Kombination von bis zu 50 Prozent höherer Geschwindigkeit, verdoppelter Speichertiefe für Debug-Informationen und zwei- bis dreimal höherer Übertragung von Debug-Informationen zur Nachverarbeitung. Im Rahmen dieser Markteinführung hat Cadence auch über zwei neue Nutzungsmodelle für Emulation berichtet – hybride Kombination von virtuellen Prototypen und Emulation sowie verteilte, synthetisierbare Verifikationsumgebungen die direkt in Emulation ausgeführt werden können. Die individuellen Verbesserungen innerhalb der Emulation selbst, als auch für ihre Verbindung mit RTL- und TLM-Simulation, dienen dem Trend der softwaregesteuerten Verifikation.
Das hybride Nutzungsmodell ist recht intuitiv sobald der Entwickler versteht, dass Prozessormodelle auf normalen x86-Rechnern sehr schnell sind – 100 MIPS und mehr. Der Schlüssel hier ist die Just-in-Time-Code-Übersetzung, die beispielsweise die Instruktionen von Software für einen ARM-Prozessor in x86-Befehle umsetzt. In einer Präsentation auf der Cadence-Anwenderkonferenz CDNLive in San Jose im März 2014, berichteten NVIDIA und ARM gemeinsam, wie die Kombination von Fast-Modellen mit Cadence-Palladium-XP-Emulation 60-mal schnelleres Laden von Betriebssystemen wie Android und Linux ermöglichen sowie zehnmal schnellere Ausführung von Tests, nachdem das Betriebssystem geladen wurde.
NVIDIA berichtete über seine Anforderungen: Betriebssysteme erfordern Millionen, manchmal Milliarden von Anweisungen, die ausgeführt werden müssen. In purer Emulation und RTL-Simulation gibt es einfach nicht genug Zyklen, daher hat das Unternehmen die hybride Kombination von virtuellen Plattformen für die Ausführung von Software auf dem Multi-Prozessor-Teilsystem mit einer Anbindung an die Emulation verwendet, in der periphere Blöcke und das Grafik-Teilsystems ausgeführt werden. Der Spezialist für Visual Computing zeigte auch den Software-Stapel, siehe Abbildung 2. Die hellgrauen Teile sind die Software, die der Anwender berührt – Android, Linux und Windows, Diagnose- und Verifikationssoftware werden verwendet, um Hardware-/Software-Interaktion zu validieren.
Beitrag zu höherer Produktivität
Wie bereits besprochen, ist keines der Entwicklungswerkzeuge, das vor der Silizium-Verfügbarkeit eingesetzt werden kann, perfekt. Softwaregetriebene Verifikation – mit hoher Wiederverwendbarkeit zwischen den Entwicklungswerkzeugen – sowie die geschickte hybride Integration von Entwicklungswerkzeugen können entscheidend zu höherer Produktivität beitragen.
Weitere Informationen zu Cadence Design Systems finden Sie im Business-Profil auf der Seite 20.
.jpg "Dreh und Sprich")
