Angesichts der aktuellen Trends werden die Entwicklungsanforderungen für SoC-Designs in den kommenden Jahren durch die steigende Komplexität der fortgeschrittenen Prozesstechnologien, einer Kombination verschiedener Komplexitätsbereiche bei sehr großen SoCs, die mit erheblichen Investitionen verbunden sind, sowie von kleineren IoT-Designs wie zum Beispiel für Edge-Knoten, angetrieben. Die Entwickler verwenden im Durchschnitt 180 IP-Blöcke und immer komplexere Subsysteme in Kombination von Software und Hardware.
Sie müssen sich mit immer mehr und kleineren Speicherblöcken auseinandersetzen, verwenden mehr als 80 Prozent der SoCs aus schon existierenden oder lizensierten Blöcken und investieren mehr als 60 Prozent des Entwicklungsaufwandes für Software, die Multicore-Prozessoren unterstützen muss und zudem über verschiedene Prozessoren zu verteilen gilt. Komplexe Interconnect-Strukturen mit Cache-Kohärenz, strenge Verlustleistungsanforderungen, ein wachsender Anteil von analogen und gemischten Signalen auf einem Chip plus eine steigende Bedeutung von anwendungsspezifischen Anforderungen, tragen erschwerend zu den Chip-Design-Herausforderungen bei. Um diese Vielzahl von Aufgaben zu bewältigen, benötigen Anwender die am besten passenden Entwicklungswerkzeuge für ihre jeweiligen Tätigkeiten – typischerweise eine Kombination der formalen Verifikation, Simulation, Emulation und FPGA-basiertem Prototyping.
Ein SoC mit komplexen Prozessor-Subsystemen, kundenspezifischen Beschleunigern, externen Schnittstellen und komplexen Verbindungs- und Busstrukturen ist mit einer Umgebung verbunden, die entweder physisch oder virtuell modelliert sein kann. Zur Verifikation auf der IP-und Subsystem-Ebene werden Tests in SystemVerilog, e, VHDL, SystemC oder UVM geschriebenen und über Verifikations-IP (VIP) mit dem zu verifizierenden Design verbunden. Die Tests für die Verifikation auf der SoC-Ebene können automatisch als portabler Stimulus, mit der vom Accellera Standardisierungsausschuss definierten Technologie, generiert und auf den Prozessoren, die sich bereits im SoC befinden, als Software ausgeführt werden.
Moderne Verifikationsabläufe
Die Verifikation wird auf vier zentrale Entwicklungswerkzeuge ausgeführt – statisch mit formaler Verifikation und dynamisch mit Simulation, Emulation und FPGA-basiertem Prototyping. Alle diese Entwicklungswerkzeuge haben, jedes für sich, unterschiedliche Vor- und Nachteile, wie Ausführungsgeschwindigkeit, Sichtbarkeit für das Debugging, Genauigkeit und die Möglichkeit nicht implementierbare Verhaltenstests auszuführen. Im besten Fall werden alle zugehörigen Module über eine zentrale Verifikations-Management-Umgebung gesteuert, die einen Verifikationsplan ausführt und Coverage-, Performance-und Debug-Informationen von allen Modulen sammelt. Um die Verifikationsproduktivität weiter zu verbessern, können die verschiedenen Module kombiniert werden. Die Entwickler suchen zudem nach der Möglichkeit, während eines Projektes möglichst viel von ihrer Verifikationsumgebung wieder zu verwenden. Dies geschieht von Phase zu Phase und oft sogar in Kombination mit dem tatsächlichen Silizium.
Verbesserung von Entwicklungswerkzeugen
Für die formale Verifikation sind „Proof Capacity“ und „Proof Success Rate“ die wichtigsten Parameter. In 2017 allein sahen wir eine Verbesserung um das 1.7-fache bei Gattern/Sekunde mit 44 Prozent reduziertem Speicheraufwand für die Front-End-Kompilation, das 1.4-fache bei Eigenschaften/Sekunde für die Kompilation und eine um den Faktor 1.3 höhere “Proof Success Rate“. Die Schlüsselparameter für die Simulation umfassen Kompilationszeit und Simulationsgeschwindigkeit sowie die Möglichkeit, die Simulation auf einzelnen und mehreren Prozessoren auszuführen. Abhängig von der Art des Designs wurde in den letzten 6-9 Monaten für die Einzel-Prozessor-Simulation die Geschwindigkeit um einen Faktor 1.4 bis hin zum Faktor 2.5 verbessert. Die Geschwindigkeit der Multi-Core-Ausführung konnte bis zu einem Faktor 6 auf der RTL-Ebene und bis zu einem Faktor 8 auf der Gatter-Ebene verbessert werden.
Für die Emulation sind die Schlüsselparameter Kapazität, Kompilationszeit und das Debugging. Das Hauptziel der Emulation besteht darin, die Hardware zu debuggen. Eine vorhersagbare schnelle Kompilationszeit ist zwingend notwendig, da das Design aufgrund von neuen RTL-Bug-Fixes mindestens einmal über Nacht aktualisiert werden muss; manche Kunden verlangen sogar mehrere Aktualisierungen pro Tag. Weiterhin ist eine hohe Kapazität auf SoC-Level erforderlich, da IP-Level-Simulationen in der Regel bereits schnell genug laufen. Für einen vollständiges Debug ist es erforderlich, vollständige Traces von Transaktionen erstellen zu können sowie umfangreiche Laufzeit-Debug-Kontrollen zu ermöglichen. Erst vor kurzem wurde die Kompilierungszeit um bis zu einem Faktor 3 erhöht und lag damit über den bereits schnellen 140 Millionen Gattern pro Stunde, die durch den Einsatz von parallelen Kompilierungstechniken erreicht wurden.
Fokus liegt auf der Software-Entwicklung
Für FPGA-basierte Prototypen sind die wichtigsten Parameter Geschwindigkeit und Kosten. Da das Design bereits stabil ist und in der Regel nur noch alle 1-2 Wochen aktualisiert werden muss, spielen Kompilierungszeit und Hardware-Debug eine kleinere Rolle, da der Fokus hier auf der Software-Entwicklung liegt. Dennoch dauerte die Entwicklung von klassischen, manuell entwickelten Prototypen oft Monate. Ein wesentlicher Durchbruch in den letzten zwei Jahren bot die Möglichkeit eine Kompilierung der Emulation wiederzuverwenden und somit die Zeit bis zum funktionalen Prototypen von Monaten auf wenige Wochen oder sogar Tage zu reduzieren.
Die Geschwindigkeit von FPGA-basierten Prototypen ist von entscheidender Bedeutung, da das Software-Debug längere Simulationsläufe erfordert. Die Kosten spielen für Entwickler auch eine große Rolle, da Prototypen für viele verschiedene Softwareentwickler repliziert werden müssen. Während in der Vergangenheit Entwickler von FPGA-basierten Prototypen bereit waren, die Größe der Designs so zu reduzieren, dass sie in FPGAs passten, sehen wir indes einen Trend hin zu SoC-Level-Prototypen, da immer mehr Software-Komplexität in Kombination mit der Hardware auf SoC-Ebene verifiziert werden muss.
Simulationsbeschleunigung für schnellen Test
Nach der sogenannten In-Circuit-Emulation (ICE), das am meisten verbreitete Benutzungsmodell der Emulation, ist die Verbindung von RTL-Simulation und Emulation, die sogenannte Simulationsbeschleunigung, das zweithäufigste angewandte Benutzungsmodell zur Erzielung einer beschleunigten Ausführung. Das zu testende Design befindet sich dabei im Emulator und die Tests auf dem Host. Die Geschwindigkeit wird durch die Ausführung der Tests auf dem Host bestimmt. Die Anwender berichten in der Regel über eine 200- bis 300-fache Beschleunigung im Vergleich zu einer puren Simulation.
Eine Variante der Simulationsbeschleunigung, in der Simulation und Emulation parallel ausgeführt werden, bietet die Hot-Swap-Funktion mit der Möglichkeit, für eine bestimmte Zeit im Simulationsmodus zu laufen, diesen dann zu stoppen und zur Emulation zu wechseln. Broadcom hat einen Ansatz für die Beschleunigung auf der Gatter-Ebene beschrieben in dem mittels Emulation ohne Timing zu dem Punkt der Ausführung simuliert wird der genauer angeschaut werden muss. Dann wird mit Hot-Swap zurück in den Simulator gewechselt, in dem dann die Ausführung mit Timing fortgesetzt werden kann.
Eine weitere geschickte Kombination der zentralen Entwicklungswerkzeuge ist die Multi-Fabric-Kompilierung, die sowohl für Emulation als auch FPGA-basierte Prototypen für klassische ICE-Anwendungen benutzt werden kann. Damit können Anwender sich jetzt von den Nachteilen klassischer, manueller FPGA-basierter Prototypen verabschieden, und mehrere Monate von Umkodierung des RTL, Neumodellierung der Speicherbeschreibungen und dem komplexen Management der Clocks im Design einsparen. Die Entwickler können nun den gleichen Flow für Emulation und FPGA-basierte Prototypen verwenden, wie auch zuletzt NVIDA in einer Präsentation: „Push-Button Prototyping in Days vs. Months“ demonstriert hat.
Ausblick
Während die Verbesserungen der zentralen Entwicklungswerkzeuge für die Verifikation enorm wichtig sind, wird die nächste Produktivitätsstufe in der SoC-Verifikation durch intelligente Kombinationen der zentralen Entwicklungswerkzeuge, in Verbindung mit einer Verifikationsumgebung für deren effiziente Integration, erreicht. Einige Integrationen sind heute schon vorhanden, viele weitere sind möglich.
