Hardware-Emulation beschleunigt das Design von Netzwerk-ASICs

Die erweiterte Simulation für Netzwerk-ASICs verlangsamt den gesamten Designprozess. In der Vergangenheit hatte Cisco für jedes neue IC ein eigenes Verifizierungskonzept angewendet. Um Aufwand und Zeit zu sparen, arbeitete das Unternehmen bei der Standardisierung einer Methode, die sich auf mehrere Designs anwenden lässt, eng mit seinem Lieferanten Mentor Graphics zusammen.

Die Umstellung auf einen standardisierten Emulationsansatz war besonders beim Bring-up-Prozess für große Chips und Systeme vorteilhaft. Das Core-ASIC-Team bei Cisco befasst sich unter anderem mit ASIC-Applikationen für Switching-Netzwerke von Unternehmen und Universitäten. Die Catalyst-9000-Serie ist hier eine der erfolgreichsten Produktlinien von Cisco.

Das Team nutzt die Emulation, um schwer auffindbare Deep-Cycle-Fehler zu ermitteln. Ohne eine Emulation werden solche Fehler letztlich ins Silizium implementiert – und dann wird die Fehlerbehebung äußerst kostspielig. Das gesteckte Ziel ist es, alle Fehler durch Emulation zu erkennen und durch die Kombination formaler Verifikationssimulation und Hardware-Emulation eine hundertprozentige Coverage vor dem Tape-out zu erreichen. Wenn dieses Ziel erreicht wird, verkürzt sich die Produkteinführungszeit (Time-to-Market).

Herausforderungen bei Performance-Tests

Die Herausforderungen beginnen schon bei den Performance-Tests von Bandbreite und Latenz, denn diese verursachen lange Simulationslaufzeiten. Aufgrund viel zu langer Entwicklungs- und Laufzeiten sind in komplexen Systemen Interaktionen zwischen mehreren Chips mit einer Simulation schwer zu überprüfen. Da sich die Schnittstellen ständig weiterentwickeln, haben die Design-Verifizierungsteams viel Zeit damit verbracht, Treiber und Monitoring-Funktionen zu entwickeln. Einige Netzwerkprotokolle, wie PTP 1588, Link Pause und Priority Flow Control (PFC), sind sehr simulationsintensiv, das heißt, die Laufzeiten für ein finales Ergebnis sind äußerst lang.

ASICs für Netzwerke sind in der Regel komplexe Designs, das bedeutet, es wird mehr Zeit für Code- und funktionale Coverage benötigt. Darüber hinaus erfordert die Verifikation der neuen Netzwerkstandards zusätzliche Testbench-Komponenten. Eine Herausforderung ist letztlich auch die Co-Verifizierung von Hardware und Software, bei der die tatsächliche Software vor dem Tape-out auf der Hardware läuft.

Eine Simulation ist für die Verifizierung auf Blockebene und für grundlegende Integrationstests unersetzlich. Mit zunehmender Größe des Designs verschlechtert sich jedoch die Simulationsleistung, insbesondere bei Systemen mit mehreren ASICs. Um die Herausforderungen zu meistern, reicht eine Simulation nicht aus.

Hintergründe zum Verfizierungsprozess

Es gibt einige Begriffe, die im Zusammenhang mit dem Verifizierungsprozess festzulegen sind. Die Begriffe Backdoor- und Frontdoor-Initialisierung weisen darauf hin, wie die Inhalte geladen oder aus dem Speicher extrahiert werden. Ein Frontdoor Flow bedeutet, dass die Daten über das Design in den Speicher geladen und aus dem Speicher heraus bewegt werden. Ein Backdoor Flow bedeutet, dass das Laden der Daten in und das Bewegen aus dem Speicher heraus nicht über das Design, sondern über eine Testbench oder eine Software erfolgt. Testingenieure möchten Daten oft vorab in den Speicher laden oder am Ende oder bereits während eines Testlaufs aus dem Speicher extrahieren. Hierfür wird häufig ein Backdoor Flow verwendet.

Cisco setzt bei der Simulation in mehr als 90 Prozent aller Tests die Backdoor-Initialisierung ein. Die Frontdoor-Verifizierung ist für eine Simulation nicht ideal. Eine Frontdoor-Initialisierung ist notwendig, wenn die Software den ASIC konfiguriert und Produktionssoftware ausführt.

Veloce-Emulationsumgebung

Um mit diesen Anforderungen beim ASIC-Design zurechtzukommen, haben die Verifizierungsingenieure von Cisco den Veloce2-Emulator von Mentor Graphics eingeführt. Die Emulation läuft damit tausendmal schneller als die Simulation und auch mit zunehmender Designgröße verschlechtert sich die Laufzeit nicht.

Anders als ein FPGA-System bietet die Veloce-basierende Emulationsumgebung vollständige Transparenz beim Debuggen. Das Kompilieren und Ausführen einzelner Schritte funktioniert ähnlich wie bei der Simulation; daher ist die Bedienung sehr einfach. So lassen sich beispielsweise viele Verifizierungskomponenten, insbesondere Scoreboards, Checker und funktionale Cover Points, in der Emulation wiederverwenden.

Zum Einsatz kommt die Simulation beim Design-Bring-up. Dabei ist allein schon die Multi-Unit-Level-Verifikation in der Simulation ein guter Ansatz, um erste Pakete auf die Chipebene zu bringen. Die Emulation hilft beim Auffinden von Deep-Cycle-Fehlern, die ansonsten nur unter großem Zeitaufwand zu erkennen wären, sowie bei der Ausführung realer Software, bei den Chip-Level-Performance-Tests und bei der Verifizierung auf Systemebene. Die Emulation ist auch praktisch für Line-Rate-Tests, für den Flow-Control- und Internet-Mix-Test (IMIX). In der Emulation lassen sich Pause- und Datenpfad-Tests sowie Lastausgleiche effizient durchführen.

Funktionale Verifikation

Hinsichtlich der funktionalen Verifikation hat Cisco einige wichtige Punkte umgesetzt. So wurde eine Testbench für die Frontdoor-Initialisierung entwickelt. Cisco portierte all seine C++-/SystemC-Checker sowie die Simulationschecks, auch die Echtzeitchecks, in den Emulator. Zum Einsatz kommt außerdem der Ethernet Paket Generator Monitor (EPGM) von Mentor zum Erzeugen von Ethernet- und verschiedenen anderen Paketen.

Die Abläufe, die Cisco für die Designerstellung umgesetzt hat, beinhalten:

• Auswahl eines Modells aus der Modellbibliothek mit den Spezifikationen des Speichermodells, das für den Tape-out gewählt wurde.
• TCAM-, SRAM-Modelle müssen auf die von Veloce2 unterstützten synthetisiert werden.
• minimale Anpassungen bei der Taktung und PLL
• Identifizieren von Teilen des Designs, die nicht emuliert werden, zum Beispiel die Design-for-Test-Logik (DFT). Bestimmte Teile lassen sich durch Konfiguration vom Compiler ignorieren und entfallen für den Emulator.

Zu den Themen der Testbench gehören unter anderem:

• Erstellen eines zu Veloce passenden Transactors für die Konfiguration der ASICs
• Einsatz des EPGM zum Senden und Analysieren der Ethernet-Pakete
• Erstellen von Checks für das Simulationsende in SystemC und C++
• Synthetisieren der funktionalen Coverage für den Emulator

Die wichtigsten Funktionen für das Debugging des Designs sind:

• EPGM-Analysefenster
• Transactor-Trigger zur Signalerfassung
• andere benutzerdefinierte Trigger für die Signalerzeugung
• hardwareseitig implementierte Assertions und Monitoring-Funktionen, die sich generieren lassen. Diese kritischen Assertions sind Ausnahmen, die ausgelöst wurden und automatisch Signale für das Debugging generieren können.
• vollständige Signal-Uploads

Virtuelle Lösung für Netzwerk-ASICs

Cisco arbeitete mehrere Jahre lang mit Mentor am EPGM, einer virtuellen Lösung für Netzwerk-ASICs. Dieser unterstützt Multicore-Modelle und bietet eine skalierbare Performance. Er verfügt über eine TCL-basierende Schnittstelle, mit der sich komplexe Testfälle sowie vordefinierte Trigger zur Signalerfassung schnell erstellen lassen. EPGM wurde kürzlich um eine Mutable Port Group ergänzt, bei der es sich um einen Super-Port-Modus handelt, der es einem einzigen Build ermöglicht, mehrere Port-Modi zu unterstützen. Somit müssen nicht mehr mehrere Builds für alle möglichen Konfigurationen des Chips erstellt werden.

Bei der Debugging-Analyse erhalten Anwender für jeden Stream Statistiken, beispielsweise werden vom EPGM die Bandbreite, Latenz, alle Frames sowie alle Fehler erfasst und ausgegeben (Out-of-Sequenz-, CRC- und Präambel-Fehler). Darüber hinaus sind Custom Checker als auch Rate-Monitore im ASIC implementiert.

Je nach Größe des ASICs und der Anwendung kann die Beschleunigung der Simulation variieren. Eine Simulation mit Frontdoor-Initialisierung dauert etwa 6000 Minuten. Mit der Emulation ließ sich die Simulation auf 30 Minuten verkürzen. Bei komplexen ASICs laufen zehntausende Frontdoor-Writes. Mit einem optimierten Flow, der Mentors Inbound Streaming verwendet, beträgt der Zeitaufwand weniger als fünf Minuten. Die Simulation allein würde normalerweise mehrere Tage benötigen.

Mit dieser Laufzeit-Performance kann Cisco in einer Simulation für eine bestimmte Konfiguration 40 Pakete pro Minute verarbeiten. In einer Emulation sind mehr als 600.000 Pakete pro Minute möglich – das ist 15.000-mal schneller als mit einer Simulation.

Erfahrung auf andere Aufgaben übertragen

Das erworbene Wissen lässt sich auch für andere Verifikationsaufgaben verwenden. Hier sind speziell die Themengebiete Presilizium-Softwareentwicklung, Multichip-Systemverifikation sowie Einsatzfähigkeit der Silizium- und Presilizium-Power-Analyse interessant. Beispielsweise können Anwender während der Presilizium-Softwareentwicklung nun das unveränderte Betriebssystem booten und Anwendungen vor dem Tape-out auf dem eigentlichen ASIC ausführen. Diese Anwendung ist insbesondere für Diagnose- und Systemsoftware-Teams von Vorteil.

Für Cisco war es wichtig, eine Diagnosesoftware zu entwickeln und zu validieren, die vor dem Tape-out zum Einsatz kommt. Ebenso mussten neue Verifizierungsfunktionen vor dem Tape-out mit aktueller Systemsoftware in Hardware validiert werden. Die Teams für Diagnose-, Kernel- und Anwendungssoftware können dank der Emulationsplattform jetzt schnell mit dem Debugging beginnen.

Die Multichip-Verifikation ist ein weiterer Anwendungsbereich. Komplexe, modulare Systeme verfügen über Supervisor- und Line Cards mit mehreren ASICs, die miteinander kommunizieren. Es handelt sich um skalierbare Systeme, und der Versuch, sie in einer Simulation zu verifizieren, ist eine große Herausforderung.

Das Bring-up des Siliziums und dessen Einsatzfähigkeit sind ebenfalls mögliche Anwendungen. Wenn der Chip zurückkommt, führt das Team zur Validierung des Siliziums mehrere Tests und eine ASIC-Qualifizierung durch. Ist das Silizium dann wieder zurück im Labor, bietet die Emulation hier sogleich einen Vorsprung. Die Presilizium-Power-Analyse ist ein von Mentor unterstützter Bereich, den der Veloce-Anwender Cisco gerade noch eingehender untersucht.

Künftige Verifikations-Flows sollen die Regressions- und Coverage-Analyse vereinheitlichen. Ein solcher Ablauf erfordert einige Änderungen am standardmäßigen funktionalen Coverage Flow, bei dem die Coverage im Design zu synthetisieren und zu mappen ist.

(na)