.jpg)
Die Analystenfirmen IBS und Semico schätzen, dass bereits im Jahr 2015 Design-Teams im Durchschnitt mehr als 130 IP-Blöcke integrieren müssen und mehr als 70 Prozent ihres Designs wieder verwendet wird. Über 60 Prozent des Chip-bezogenen Entwicklungsaufwandes wird sich in Software verschieben, welche über Multiprozessoren verteilt werden muss. Entwickler müssen erhebliche Anforderungen zur niedrigen Stromaufnahme erfüllen, und Entwicklungen werden immer mehr anwendungsspezifisch, mit einem stark wachsenden Anteil von Analog/Mixed-Signal-Komponenten und sehr komplexen On-Chip-Interconnect-Strukturen. Abbildung 1 skizziert beispielhaft ein Chip-Design-Projekt. Der untere Teil der Abbildung illustriert die wichtigsten Projektschritte, deren Länge als Mittelwert aus einer Analyse von zwölf Projekten berechnet wurde. Einer Spezifikations-Phase von acht bis zwölf Wochen folgt eine Kombination von RTL-Design, Integration und Verifikation, eine Phase die heutzutage als wesentlichen Faktor auch die Qualifizierung von IP beinhaltet. Die Gesamtdauer von RTL bis zur Daten-Übergabe ("Tape-Out") zur Chip-Produktion variiert zwischen 49 und 83 Wochen. Es ist wichtig zu verstehen, dass in den letzten zehn bis zwölf Wochen nur Engineering Change Orders (ECOs) erlaubt sind, da sich der Schwerpunkt der Entwicklung von der funktionellen Verifikation auf die Implementation des Chips verschoben hat. Nach elf bis 17 Wochen Produktion folgen 14 bis 18 Wochen zur Validation des Chips.
Die linke Achse zeigt die wesentlichen Komponenten der Hardware/Software-Entwicklung. Das System-on-Chip (SoC) integriert die Teil-Systeme und IP-Blöcke und wird in seine Systemumgebung integriert. Verschiedene Arten von Software laufen auf dem SoC - von Software, die direkt mit der Hardware verbunden ist und mit ihr die Funktionalität definiert, hin zu Treibern und Betriebssystemen wie Linux, Android, iOS, Windows oder Echtzeit-Betriebssystemen wie OSE oder vxWorks. Auf diesen Betriebssystemen laufen dann "Middleware" für Audio, Video, Grafik und Netzwerkfunktionen, die wiederum die End-Applikationen ermöglichen, welche wir als Benutzer heutzutage nicht mehr missen wollen.
Abbildung 1 verdeutlicht auch zwei weitere Schlüsselabhängigkeiten. Nachdem die Beschreibung auf der Register-Transfer-Ebene (RTL) stabilisiert wurde, kommt man an einen Punkt, an dem Hardware-Funktionalität fixiert werden muss damit sich Entwicklungs-Teams auf die Silizium-Implementierung konzentrieren können. Da zu diesem Zeitpunkt auch alle Aspekte des Chips in seiner Systemumgebung überprüft worden sein müssen, stellt dies spezielle Herausforderungen an die Ausführungs-Plattformen dar, die zu diesem Zeitpunkt für RTL zur Verfügung stehen. Der zweite Aspekt bezieht sich auf die Softwareentwicklung. Die Wechselwirkungen an der Schnittstelle zwischen Hardware und Software muss man so früh wie möglich prüfen. Heutzutage wird die korrekte Ausführung von Betriebssystemen zu einer De-facto-Pflichtanforderung, bevor ein Tape-Out für den Chip erlaubt ist. Dies stellt wiederum besondere Herausforderungen an die Ausführungs-Plattformen für RTL dar, da zu diesem Zweck eine große Anzahl von Zyklen ausgeführt werden müssen. Oft läuft diese Verifikationsphase parallel zum Chip-Layout, und sollte zu diesem Zeitpunkt noch ein Fehler gefunden werden, sollte sehr sorgfältig abgewogen werden, ob das Layout wiederholt werden kann. Sobald der Chip zurück aus der Produktion kommt, kann die Software-Entwicklung auf dem eigentlichen Chip abgeschlossen werden.
Vier Kern-Ausführungs-Plattformen
In den oben erwähnten Projektphasen erfolgt die Verifikation und Software-Entwicklung im Wesentlichen auf vier verschiedenen Ausführungs-Plattformen.
"Virtuelle Prototypen" sind Repräsentationen der Hardware auf der Transactions-Ebene, die in der Lage sind, den gleichen Code auszuführen, der später auf der eigentlichen Hardware läuft. Sie können Geschwindigkeiten von deutlich über 50 MIPS auf x86-basierten Rechnern unter Windows oder Linux erreichen. Virtuelle Prototypen sind für Software-Entwickler voll transparent, da sie die Hardware Register korrekt repräsentieren und die Funktionalität genau, aber abstrahiert, nachbilden. Als Beispiel sind oft Prozessor-Pipelines und Speicher Arbitration nicht mit voller Genauigkeit nachgebildet.
"Register-Transfer-Level(RTL)-Simulation" führt die gleiche Hardware-Darstellung aus, die später in der logischen Synthese den eigentlichen Chip implementiert. Dies ist typischerweise die erste Ausführungs-Plattform für die Hardware-Verifikation und simuliert die Hardware mit Geschwindigkeiten im Hertz-Bereich. RTL ist normalerweise das "goldene" Referenz-Modell für die Implementation und erlaubt detailliertes Austesten ("Debugging") des Chips.
"Simulations-Beschleunigung" führt eine Mischung aus RTL-Simulation und Hardware-unterstützter Verifikation aus, in der die Test-Umgebung sich auf dem Rechner befindet und das Design unter Test (DUT) in Hardware ausgeführt wird. Wie der Name schon sagt, ist der Hauptanwendungsfall die Beschleunigung der Simulation. Diese Kombination ermöglicht es Ingenieuren, die erweiterten Möglichkeiten der sprach-basierten Test-Umgebung zusammen mit einem beschleunigten DUT zu nutzen. Typische Beschleunigung im Vergleich zur RTL-Simulation kann das Tausendfache erreichen, ist aber in der Regel auf den Bereich von mehreren zehnfachen KHz begrenzt.
"Emulation" führt das DUT auf spezialisierten Hardware-Verifikations-Plattformen aus, in welche RTL automatisch abgebildet wird und für die Hardware-Debugging so leistungsfähig ist wie in der RTL-Simulation. Schnittstellen zur System-umgebung (Ethernet, USB, usw.) können unter Verwendung von Raten-Adaptern ("Speedbridges") hergestellt werden. "In-Circuit"-Emulation bildet die komplette Entwicklung einschließlich der Test-Umgebung in die Hardware-Verifikations-Plattform ab. Als Resultat lassen sich viel höhere Geschwindigkeiten bis in den MHz-Bereich erreichen, so dass Hardware/Software -Entwicklung möglich wird.
"FPGA-basierte Prototypen" verwenden ein Array von FPGAs, in die das Design direkt abgebildet wird. Aufgrund der Notwendigkeit, das Design zwischen FPGAs aufzuteilen und die RTL-Beschreibung wesentlich zu manipulieren, um eine Abbildung zu ermöglichen, kann der Prozess der Abbildung in einem FPGA-basierten Prototypen mitunter Monate dauern - im Gegensatz zu Stunden oder Minuten in der Emulation. Hardware-Debugging ist sehr eingeschränkt, aber dafür sind Geschwindigkeiten im zehnfachen MHz-Bereich möglich, die FPGA-basierte Prototypen sehr attraktiv für die Software-Entwicklung machen. Die wesentlichen Anwendungs-Aufgaben, die während der Entwicklung durchgeführt werden, umfassen System-Modellierung und Trade-offs, frühe Software-Entwicklung, IP-Auswahl und -Verifikation, SoC- und Sub-System-Verifikation, Gate-Level-, Timing- und Power-Abnahme, HW/SW-Validierung für den Chip mit hardwarenaher Software, Software-Integration und Qualitäts-Sicherung sowie System- und Silizium-Validierung.
Frühe Software-Entwicklung
Je nach dem, ob Modelle der Hardware verfügbar sind, ermöglichen Virtuelle Prototypen die Software-Entwicklung sehr früh - ein paar Wochen nachdem die Spezifikation verfügbar ist. Sie sind schnell, ermöglichen gutes Software-Debuggen und Kontrolle der Simulation und sind in der Regel der schnellste Weg, um Software für ein neues Design zu entwickeln. Allerdings erlauben sie kein detailliertes Hardware-Debuggen, die Stärke der RTL-Simulation. Diese wird zunächst für RTL-Entwicklung, IP-Integration und -Verifikation verwendet, kann aber auch für Teil-Systeme verwendet werden und ist ein Abnahme-Kriterium für die Gate-Level-Simulation und das Timing. Sie bietet hervorragendes Hardware-Debugging, ist aber typischerweise zu langsam, um angemessene Zyklen von Software auszuführen.
Um Teil-Systeme und den vollständigen Chip besser auszuführen, verschieben Entwickler mit der Simulations-Beschleunigung das DUT in Hardware und erreichen ausreichende Geschwindigkeiten für die Basis-Software-Entwicklung. Mit seinen "In-Circuit"-Fähigkeiten ermöglicht die Emulation die Verifikation des kompletten Chips und des Chips in seiner System-Umgebung, indem Verbindungen zu echten System-Schnittstellen wie PCI, USB und Ethernet hergestellt werden. Die Hauptvorteile der Prozessor-basierten Emulation sind die schnelle Abbildung des Designs in die Hardware, die sie ideal für die Projektphasen machen, in denen RTL ist noch nicht ganz ausgereift ist und mehrmals täglich verändert wird. Darüber hinaus ermöglichen Multi-Benutzer-Zugriff und sehr gutes Hardware-Debuggen im Kontext der realen Software, die mit Geschwindigkeiten im MHz Bereich ausgeführt werden kann, sehr effiziente Hardware/Software-Debug-Zyklen. Standard-Software-Debugger können direkt via JTAG-Adapter oder virtuelle Verbindungen angeschlossen werden.
FPGA-basierte Prototypen ermöglichen Geschwindigkeiten im zehnfachen MHz-Bereich und bieten oft die niedrigsten Kosten pro Gatter pro MHz für Software-Entwicklung und Hardware-Regressionen. Das prädestiniert sie für die Projektphasen, wenn RTL stabil genug geworden ist. Der Nachteil an FPGA-basierten Prototypen sind Kapazitätsgrenzen sowie die aufwändigere Abbildung des Designs aufgrund der notwendigen Veränderungen.
Wie deutlich wurde, gibt es keine Ausführungs-Plattformen, die alle Anforderungen erfüllen. Nutzer müssen die für ihre Anwendungen passende Plattform sorgfältig wählen. Es überrascht daher nicht, dass die Plattformen immer mehr in hybriden Kombinationen verwendet werden, um die jeweiligen Vorteile in Kombination nutzen zu können. Z. B. macht die Kombination von virtuellen Prototypen und Emulation eine deutliche Beschleunigung der Ausführung von Betriebssystemen möglich, was dann Software auch für die Hardware-Verifikation nutzbar macht. Da die verschiedenen Plattformen näher zusammenwachsen, werden die effiziente Übertragung von Entwicklungen von Plattform zu Plattform, kombiniert mit effizienter Wiederverwendung von Testumgebungen sowie hybrider Ausführung der Plattformen, in Zukunft weiter an Bedeutung gewinnen.
