Optimierung der Pre-Silicon-Softwareentwicklung

Im heutigen schnelllebigen Technologiezeitalter ist der gängigste Ansatz zur Bewältigung der Marktanforderungen ein System-on-Chip (SoC). Ein SoC ist im Grunde ein Prozessor, der von Funktionsbeschleunigern und vielen I/Os für die zugehörige Peripherie umgeben ist, die er unterstützt. Seit der mobilen Datenrevolution im Jahr 2002 ist es zu einer Voraussetzung geworden, SoCs zu verwenden, um die wichtigsten Funktionen zu ermöglichen, die ein Smartphone ausmachen. Auf die gleiche Weise sind SoCs seitdem zum bevorzugten Gerät für die Entwicklung „intelligenter“ Verbraucherprodukte wie Fernseher, Autos und den ständig wachsenden Internet-of-Things-Markt (IoT) geworden.

Die wachsende Nachfrage nach SoCs hat einen hart umkämpften Markt geschaffen. Aus diesem Grund werden SoCs komplexer, die Peripherie in den SoCs entwickelt sich ständig weiter und die Time-to-Market verkürzt sich. Eine entscheidende Komponente, um der Komplexität der SoC-Entwicklung gerecht zu werden, ist die Verfügbarkeit von Software. Es gibt wenig Raum für Fehler, und die Software muss so schnell wie möglich fertig sein. Um dieser Herausforderung zu begegnen, muss die Softwareentwicklung eingeleitet werden, bevor der SoC-Teil verfügbar ist.

SoC-Softwareentwicklung

Traditionell begann die Softwareentwicklung, nachdem das erste Siliziummuster aus der Fertigung eingetroffen war. Wenn die SoC-Muster eintrafen, begannen die Software- und Validierungsteams mit ihren Entwicklungsaktivitäten, und es begann eine große Anstrengung zur Einführung von SoCs. Teams, die am SoC arbeiten, würden aus der ganzen Welt zusammenkommen, um für eine begrenzte Zeit unter einem Dach zu sein, um die SoC-Aufbringung zu unterstützen.

Die Softwareentwicklung dauerte im Allgemeinen Monate, nachdem das erste Muster eingetroffen war, bevor es produktionsreif war. In der Zwischenzeit würde die Siliziumvalidierung abgeschlossen, was ein begrenztes Vertrauen in die Einleitung der Massenproduktion der zugehörigen Produkte geben würde.

Aufgrund der zunehmenden Komplexität des SoC-Designs kann sich die Softwareentwicklung, die normalerweise Monate in Anspruch nehmen würde, jedoch zu Jahren hinziehen, bevor die Software serienreif war. Die zunehmende Anzahl unterstützter Peripheriegeräte und die Entwicklung dieser Peripheriegeräte führten auch zu Lücken in der Fachkompetenz. Softwareteams müssten diese speziellen Lücken schließen, indem sie neue Entwickler mit Fachwissen in diesen Bereichen (Audio, Video, USB, Ethernet usw.) anwerben.

Um frühzeitig im Projekt serienreife Software liefern zu können, kann die Softwareentwicklung nicht warten, bis das erste Siliziummuster verfügbar ist. Ein Shift-Left-Ansatz muss verfolgt werden, bei dem die Softwareentwicklung so früh wie möglich beginnt und noch besser, gleichzeitig mit dem SoC-Hardwaredesign. Die Entwicklung von Pre-Silicon-Software kann auch dazu beitragen, Fehler bei der SoC-Implementierung zu identifizieren und möglicherweise die Kosten für Metallfixierungen oder Vollmasken-Tapeouts zu reduzieren. Es werden mehrere Methoden in Betracht gezogen, um diese Anforderungen zu erfüllen.

Prä-Silizium-Entwicklungsansätze

Um mit der Softwareentwicklung vor dem SoC-Tapeout zu beginnen, können Entwickler einige Ansätze wie Software-Prototyping, RTL-Testbench, FPGA-Boards, Hardware-Emulatoren usw. verwenden. Da sich diese Ansätze typischerweise auf einzelne Module konzentrieren, hat jeder dieser Ansätze seine eigenen Herausforderungen, da die Zielsetzung besteht darin, Software für die Bereitstellung des gesamten SOC zu entwickeln, anstatt einzelne Module. Wenn wir das Problem in kleinere Module aufteilen, müssen wir zunächst jeden Prozessor, Beschleuniger oder jedes Peripheriegerät kennen, das sich in der Entwicklung befindet, bevor die Treiberentwicklung beginnen kann.

System C-Modelle

C-Verhaltensmodelle können für jede IP des SoC erstellt werden, und eigenständige Softwaretreiber können an diesen Verhaltensmodellen getestet werden. Aber dieser Ansatz hat ein paar Probleme. Erstens ist ein enormer Softwareaufwand erforderlich, was bedeutet, dass ein großes Softwareteam oder ein dediziertes Modellteam erforderlich ist, um die Implementierung des Modells selbst zu unterstützen. Daher wäre die Entwicklung von Modellen nicht wirtschaftlich. Zweitens hängt die Genauigkeit der Verhaltensmodelle von der Interpretation des Entwicklers ab. Jegliche Kommunikationslücken zwischen dem IP-Design-Inhaber und dem Modellentwickler können zu ungenauem Verhalten führen. Dies führt zu viel verschwendetem Aufwand, um Probleme im Zusammenhang mit der Fehlinterpretation des Designs zu beheben.

RTL-Testbench

Um dieses Problem mit der Ungenauigkeit zu beheben, können Sie auch eine Verilog-Testbench verwenden. Die Testbench wird in der Regel vom SoC-Designteam zur Verifizierung entwickelt und gewartet. Die Verilog-Testbench basiert auf der Register Transfer Language (RTL)-Spezifikation des SoC, die den vollständigen SoC darstellt, nicht nur einige IP-Blöcke. Folglich ist es von Zyklus zu Zyklus genau. Mit der Entwicklung von RTL bewegt sich die Testbench im Gleichschritt. Dadurch wird sichergestellt, dass es sich um die aktuellste und genaueste Darstellung des SoC in der Entwicklung handelt. Für Softwareentwicklungszwecke kann die Testbench von Verilog auch verwendet werden, um Softwaretreiber zu entwickeln.

Software, die mit dieser Methode entwickelt wurde, ist genau und kann dazu beitragen, die Software-Startzeit zu verkürzen, wenn SoC-Proben nach dem Herstellungsprozess eintreffen. Aber dieser Ansatz hat ein Problem. Da die Verilog-Testbench zyklusgenau ist, ist sie sehr langsam. Die Entwicklung von Software in einer solchen Umgebung ist möglich, aber die Entwicklung und das Debuggen werden extrem langsam sein. Es kann Monate dauern, einen Treiber mit dieser Methodik zu entwickeln. Verilog Testbench kann durch einen viel früheren Start verwendet werden – im Wesentlichen erhöht sich die Zeit, die in Pre-Silicon benötigt wird, um die langsame Geschwindigkeit der Lösung zu berücksichtigen (aber hängt von der Verfügbarkeit der Testbench ab). In einem alternativen Ansatz kann ein anderes Softwareteam diese Methodik verwenden (nur an der Prä-Silizium-Entwicklung arbeiten) – im Wesentlichen die Anzahl der benötigten Ressourcen erhöhen, wodurch dieses Problem nicht ähnlich dem Problem mit der C-Verhaltensmodellmethode beseitigt wird.

In der Praxis können wir weder ungenaue oder lange Entwicklungszyklen akzeptieren, noch können wir die zusätzlichen Kosten akzeptieren, die erforderlich sind, um die Anzahl der Ressourcen zu duplizieren oder zu erhöhen, um einen normalen Zeitplan für den Designzyklus einzuhalten. Folglich müssen wir einen anderen Ansatz für die Entwicklung von Pre-Silicon-Software in Betracht ziehen. Dieser Ansatz würde die Emulation jedes SoC-IP-Blocks auf einem feldprogrammierbaren Gate-Array (FPGA) beinhalten.

FPGA-Prototypen

Moderne FPGAs sind ziemlich schnell, und da die FPGAs aus RTL aufgebaut sind, sind sie von Zyklus zu Zyklus genau. Mit zunehmender Designkomplexität haben IP-Blöcke viel mehr Tore als noch vor Jahren. Vor Jahren waren FPGAs durch die Anzahl der ASIC-Gates begrenzt, was bedeutete, dass es nicht möglich war, größere Logikblöcke in einem einzigen FPGA unterzubringen. Jetzt ist es möglich, für jeden Block ein FPGA zu bauen und darauf einen Treiber zu entwickeln, der schnell und genau ist.

Diese Methode ist schneller und erfordert nicht, dass Softwareteams ihre Zeit frühzeitig einsetzen. Da dieser Ansatz mit jedem einzelnen IP-Block und nicht mit dem gesamten integrierten SoC-Design arbeitet, beschränkt dieser Ansatz die Software darauf, eine vollständige Entwicklung auf SoC-Ebene durchzuführen. Es enthält keine Integrationsdetails, wie verschiedene IP-Blöcke zusammen funktionieren. Obwohl diese Methode den Bereitstellungsaufwand verringert, bestehen daher immer noch Lücken, da relevante Details zur SoC-Integration fehlen. Diese Methode könnte ein akzeptabler Ansatz für abgeleitete SoCs sein, die eine begrenzte Anzahl von Änderungen aufweisen, aber keine vollständige Abdeckung haben, die für die SoC-Softwareentwicklung erforderlich ist.

Klicken für größeres Bild

Abbildung. Synopse von Pre-Silicon Softwareentwicklungslösungen. (Quelle:Nitin Garg)

SoC-Emulatoren

Um das Problem der Genauigkeit, Geschwindigkeit und Abdeckung anzugehen, könnte ein robusterer Ansatz gewählt werden, der SoC-Emulatoren verwendet. Es gibt viele kommerziell erhältliche SoC-Emulatoren, die sehr große und komplexe SoCs emulieren können. SoC-Emulatoren basieren auf RTL, sind also genau und 100-mal schneller als die Verilog-Testbench, was sie für die Softwareentwicklung viel besser macht. Da sie ziemlich schnell sind, kann eine vollständige Betriebssystemportierung und Treiberentwicklung in angemessener Zeit durchgeführt werden. SoC-Emulatoren können das gesamte SoC skalieren, sodass die Softwareentwicklung besser an das endgültige Produktions-SoC angepasst ist.

Die Verwendung von SoC-Emulatoren für die Entwicklung und das Design von Pre-Silicium-Software reduziert die Zeit und den Aufwand für die Softwareeinführung, da sie Gesamtentwicklungslücken beseitigen oder reduzieren können. Software kann auch mit Standard-JTAG-Tools auf einem SoC-Emulator debuggt werden. Emulatoren können für mehrere Aufgaben wie ROM-Entwicklung und -Verifizierung, Firmware- und Betriebssystem-Entwicklung und Verifizierung auf IP- oder SoC-Ebene verwendet werden. Ein weiteres interessantes Merkmal von SoC-Emulatoren ist, dass sie den SoC mit realen Komponenten wie denen auf einem Entwicklungsboard verbinden können. Es ist beispielsweise möglich, ein reales oder virtuelles NAND-Gerät mit dem SoC in einem Emulator zu verbinden und ROM, Betriebssystemtreiber und dergleichen zu entwickeln.

SoC-Emulatoren bieten weit mehr Möglichkeiten als andere Softwareentwicklungsansätze. Emulatoren können den SoC gleichzeitig mit UART, I2C, verschiedenen Displays, Speichergeräten, PCIe-Geräten, Konnektivitätsgeräten wie Ethernet und Wi-Fi und Erfassungsgeräten wie Kameras und Sensoren verbinden. Mit anderen Worten, SoC-Emulatoren können ein tatsächliches Entwicklungsboard darstellen, sodass man ein vollständiges Framework wie Android aufrufen und einen vollständigen Anwendungsfall ausführen kann, bevor man das SoC aufnimmt. Das Booten von Android und das Dekodieren einiger Videoframes auf dem SOC-Emulator kann beispielsweise einige Stunden dauern, kann aber bei der Analyse der SOC-Leistung sehr nützlich sein.

Aufgrund der zunehmenden Verfügbarkeit von Peripheriegeräten auf einem SoC ist die SoC-Emulation auch sehr nützlich für Performance-Benchmarking, das die Schwächen im Design vor dem Tapeout aufzeigen kann. Diese Funktionalität kann Risiken oder spätere Tapeouts im Zusammenhang mit nicht identifizierten Leistungsmängeln im SoC reduzieren. SoC-Emulatoren ermöglichen es auch, den SoC bei Bedarf für Drittanbieter-IP mit einem FPGA oder Soft-Modell eines Drittanbieters zu verbinden.

Das Debuggen eines Problems nach dem Eintreffen des SoC-Beispiels ist auch bei einem Emulator hilfreich, da er das gleiche Betriebssystem, die gleichen Treiber und das gleiche Framework wie die echte Hardware ausführt. Häufig besteht die Notwendigkeit, im Silizium beobachtete Probleme auf die Emulatoren zu replizieren, damit sie auf Signalebene untersucht werden können. Die Verwendung der gleichen Software zwischen Emulator und Silizium ermöglicht eine schnellere und genauere Reproduktion der Probleme und bietet vollen Zugriff auf die Details im Inneren des Chips.

Vergleicht man die verschiedenen SoC-Softwareentwicklungsansätze, ist die Verwendung von SoC-Emulatoren aus Sicht der Prä-Silizium-Entwicklung und der Post-Silizium-Debugging-Perspektive die bessere Wahl. Die Kosten für Softwareteams zum Ausführen von SoC-Emulatoren können hoch erscheinen. Aber die Beiträge, die SoC-Emulatoren leisten, indem sie Produktionssoftware früher zur Verfügung stellen und zur Reduzierung von Risiken und Kosten beitragen, können sich bei der Betrachtung der Auswirkungen auf die Time-to-Market-Ziele als unschätzbar erweisen. Andere Softwareentwicklungsansätze haben nicht die gleiche Abdeckung, was riskant ist und möglicherweise größere Ressourcen für Softwareteams erfordert. Alle Faktoren berücksichtigt, kann sich die Verwendung anderer Softwareentwicklungsansätze als SoC-Emulatoren im Vergleich als viel kostspieliger erweisen.

Abbildung 2. Vergleichende Ausführungsgeschwindigkeit jeder Lösung. (Quelle:Nitin Garg)

Nach dem Mooreschen Gesetz verdoppelt sich die Transistorzahl in einem integrierten Schaltkreis (IC) aufgrund der erhöhten Funktionalität des IC alle zwei Jahre. Die meisten ARM-basierten 64-Bit-SoCs haben heute 100-300 Millionen Logikgatter. Von den aktuellen SoC-Softwareentwicklungsansätzen haben sich SoC-Emulatoren als skalierbar erwiesen und unterstützen die Anforderungen von Softwareentwicklungsteams, die sich den Herausforderungen im Zusammenhang mit der zunehmenden Komplexität von SoCs auf dem heutigen wettbewerbsorientierten Markt stellen.

Referenzen

1. Trimberger, Stephen M. „Drei Zeitalter der FPGAs.“ IEEE Xplore Volltext-PDF: 2015, ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7086413.
2. BRUNET, JEAN-MARIE. „Warum moderne SoC-Designs Embration unterstützen.“ Embedded Computing Design , 5. September 2018, embedded-computing.com/embedded-computing-design/why-modern-soc-designs-embrace-emulation.
3. "Soz. Emulation". Soc-Emulation , 2019, www.aldec.com/en/solutions/hardware_emulation_solutions/co-emulation–soc-emulation.
4. „Mehr Komponenten in integrierte Schaltkreise stopfen.“ http://www.cs.utexas.edu/ , 2006, cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf.