Virtuelle Emulation von Software-Defined-Networking-Geräten

| Autor / Redakteur: Ron Squiers * / Sebastian Gerstl

Bild 1: Beispiel eines Block-Diagramms der SDN-Hardware.
Bild 1: Beispiel eines Block-Diagramms der SDN-Hardware. (Bild: Mentor Graphics)

Der Beitrag beschreibt Methoden zur Hardware/Software- Co-Verifikation und beschleunigten virtuellen Emulation von SDN-Geräten mittels Virtual PCIe.

Die enormen Veränderungen in der Netzwerkforschung und -entwicklung haben in den letzten Jahren zu einer völlig neuen Klasse von Netzwerkgeräten geführt, den SDN (Software Defined Networking) Switches und Routern.

SDN-Geräte werden von Softwareanwendungen verwaltet, die ihre Konfigurationen herunterladen. Dies geschieht in der Regel über die PCIe- (Peripheral Component Interconnect Express) Schnittstelle, die bei der Verifikation von Netzwerk-SoCs seit Jahren als bewährte Schnittstelle für einfachen Gerätezugriff, die Konfiguration und das Laufzeitmanagement verwendet wird.

SDN-SoCs (System on Chips) führen jedoch zu deutlich mehr Interaktionen zwischen der Software der Host-Anwendung und der Hardware des SoC, die über PCIe verwaltet werden. Neukonfigurationen per Software sind schnell durchführbar, weit verbreitet und unterstützen Tausende von einzelnen Schaltprofilen. Um diese komplexen Vorgänge zu validieren, ist die Co-Verifikation von Hard- und Software eine unverzichtbare Methode.

Traditionelle Methoden zur PCIe-Verifikation, insbesondere Vektor-basierte Verifikationsmethoden, reichen für die Co-Verifikation von großen Geräten nicht aus. Vektor-basierte Verifikationsplattformen eignen sich weder für die Co-Verifikation von Hard- und Software noch funktionieren sie für SDN. Diese Einschränkungen lassen sich am besten überwinden, wenn man mit Hilfe von Virtual PCIe auf ein virtuelles Paradigma wechselt. Virtual PCIe beschleunigt den Einsatz der virtuellen Emulation. Damit können Anwendungen mit dem emulierten Testobjekt (Device Under Test, DUT) so interagieren, als ob es echte Hardware wäre. Virtual PCIe ist die ideale Methode für die Co-Verifikation von Hard- und Software.

SDN trennt die Steuerungs- und Weiterleitungsfunktionen eines Netzwerk-Switches und zentralisiert die Steuerung in einer Softwareanwendung auf einem externen Host. Die Zentralisierung der Steuerung und die Fähigkeit, das Verhalten des Netzwerks mit genau definierten Schnittstellen zu programmieren, sind wichtige Eigenschaften des SDN-Paradigmas (siehe Bild 1).

Eine zentrale Komponente ist die Software, die zur Konfiguration der blau dargestellten Elemente verwendet wird. Im Wesentlichen ist es so, dass der Chip „aufwacht“ und nicht weiß, welche Funktion er ausführen soll. SDN-SoCs sind keine traditionellen Geräte mit festen Funktionen, sondern hochkonfigurierbare Match-Action-Devices, die von einer SDN Control Plane Application oder einem Orchestrator programmiert werden. Der Orchestrator managt alles, von der ersten Gerätekonfiguration bis zur Echtzeitsteuerung. Er kann einen einzelnen SoC oder ein Netzwerk von Geräten verwalten.

Virtuelle Emulation von SDN-Geräten

SDN-Geräte arbeiten während der Emulation im Vergleich zur Taktrate des Produkts mit einer viel geringeren Geschwindigkeit. Aus der Perspektive des DUT läuft das SDN-Gerät mit voller Geschwindigkeit, da alle Takte über die PCIe-Schnittstelle und Emulationstakte des DUT aufrechterhalten werden (siehe Bild 2).

Der von Mentor unterstützte virtuelle PCIe Root Complex (RC) wird in einer als VirtuaLAB bezeichneten Lösung geliefert. Diese Bibliothek unterstützt verschiedene Arten von virtuellen Maschinen (VM), die sich für viele Technologien wie Vernetzung, Multimedia, Speicher, Automotive und CPU eignen.

Bei der Verwendung von VirtuaLAB PCIe kommt für die PCIe Software Under Test (SUT) genau der gleiche Treiber zum Einsatz, den auch die Kunden erhalten. Der Treiber spezifiziert den Bus und findet das SDN-DUT so vor, als ob es das echte Produkt wäre. Um das DUT zu initialisieren und die Host-Software dynamisch zu konfigurieren verbindet sich die SDN-Software über den PCIe-RC nahtlos mit dem PCIe-Endpunkt (EP) des SoC. Diese Vorgehensweise ist für Hard- und Software-Entwickler zur Designverifizierung, Laborvalidierung und Kundenbetreuung sehr interessant.

Durch die Verwendung von VirtuaLAB PCIe lässt sich die Kluft zwischen Pre- und Post-Silizium überwinden. Als Beispiel dient ein Fall, wo Hunderte von Tests auf Hunderten von Geräten ablaufen müssen, bevor diese Muster nach dem Fab-Out an die Kunden ausgeliefert werden können. Tests hinsichtlich Funktion, Ausbeute, Spannung und Temperatur (DVT) sowie SDN-Goldstandard-Anwendungen müssen sofort auf jeder Probe laufen und zwar bevor die automatisierte Prüfung und Messung (Automated Test and Measurement, ATM) verfügbar ist. Alle Tests, die während der Pre-Silizium-Entwicklung validiert wurden, können für die Post-Silizium-Tests verwendet werden, da sie unter dem Virtual-PCIe-VM-Paradigma identische logische Plattformen nutzen.

Manchmal müssen Anwendungen, die in der QEMU VM laufen, verlangsamt werden, damit sie bei der Emulation besser mit der tatsächlichen Taktrate des DUT übereinstimmen. Auf diese Weise werden Software-Timeouts erfüllt, die innerhalb von Applikationen eingebaut sein können. Wenn die anvisierten Applikationen keine Timeout-Anforderungen haben, laufen diese Anwendungen mit der voreingestellten VM-Taktrate im QEMU mit Bezug auf den Emulationstakt des DUT.

Sobald Designteams die erweiterten Funktionen der VM kennen lernen, wollen sie mit VirtuaLAB PCIe Produktsoftware und Treiber parallel zum Hardware-Entwicklungszyklus entwickeln. Hard- und Softwarearchitekturen können frühzeitig im Entwicklungszyklus zusammen verifiziert und bestätigt werden, was weniger Code-Rip-up erfordert. Funktionelle Software-APIs, die mit Vektor-basierter Verifikation nicht möglich waren, lassen sich nun mit VirtuaLAB PCIe testen. Hochverfügbare (High Availability, HA) APIs sind solch ein Beispiel.

Um zu verifizieren, dass die API unter allen Traffic-Szenarien, Instandhaltungs- und Parallelprozessen wie erwartet arbeitet, muss eine HA-API jederzeit Geräte programmieren können, während der Traffic gestreamt wird. Betreiber können einen HA-API-Server zu Wartungszwecken herunterfahren. Eine untergeordnete CPU erfasst den Zustand des SDN bevor die primäre CPU abschaltet. Sobald die Wartung abgeschlossen ist, bootet die primäre Management-CPU wieder und führt die gesamte Initialisierungssequenz erneut aus, ohne den Zustand der Hardware zu verändern. Die Management-CPU stellt den Zustand ihrer SDN-Software aus dem Ruhezustand wieder her, der in der noch laufenden SDN-Hardware gefunden wurde. Ohne virtuelle PCIe-Tests wären solche Hardware/Software-Interaktionen zur Validierung des Pre-Siliziums nicht möglich.

Das Testen aller Software-Zustandsräume in Bezug auf die Hardware ist eine enorm große und komplexe Aufgabe. Für diese und viele andere dynamische Verifikationsaufgaben, die eine reaktive Konfiguration des DUT mittels VirtualLAB PCIe ermöglichen, benötigen Entwicklungsteams einen Test, der den Wert der Sequenzierung durch den Produktcoderaum vor dem Tape-Out erkennt. Das „Shift left“-Paradigma für die Veloce-Emulation ist ein wichtiger Aspekt in der Unternehmenskultur von Mentor.

Leistungsaspekte, Debugging und Benutzerfreundlichkeit

Je nachdem, wie die SDK-Software geschrieben ist, funktioniert sie unter Umständen nicht wie eine typische PCIe-EP-Anwendung. Ein vom EP initiierter DMA hat viele Vorteile: Die CPU wird nicht geladen, weil sie lokalen Speicher nur bei Bedarf nutzt, und der EP kann alle Transport-Latenzen durch mehrfache Leseanforderungen ausblenden.

Unabhängig von der Optimierung des EP über den PCIe-DMA ist das eigentliche Ziel für VirtuaLAB Ethernet plus VirtuaLAB PCIe die Verifizierung großer SDN-Designs, bei denen die Emulationszeit für Ethernet-Tests vermutlich viel größer ist als die Download-Zeiten der PCIe-Konfigurationen für die meisten Testszenarien. Dies ist wichtig, weil es den Unterschied von Mentors Out Of the Blue (OOB) Transaktor-Methode gegenüber den Simulations-Verhältnis-Modellen bei der Arbitrierung zwischen mehreren VMs aufzeigt. Dies ist etwa bei PCIe- und Ethernet-VMs auf der gleichen Host-Workstation der Fall.

Wie erwartet, wird die OOB-PCIe-Performance nie gedrosselt. Wenn Ethernet und PCIe denselben Kanal für die Co-Modellierung nutzen, wird ein OOB-PCIe-VM die Taktrate der Ethernet VM sicherlich mehr beeinträchtigen als das Simulationsverhältnis zwischen den VM. Dies kann passieren, wenn sowohl Virtual Ethernet als auch Virtual PCIe auf demselben Co-Modellierungskanal laufen, um gleichzeitig mit dem DUT zu kommunizieren (Bild 3).

PCIe und Ethernet laufen aber meist getrennt voneinander. PCIe muss für die Konfiguration sehr schnell ablaufen, während die Ethernet-Taktrate nicht so wichtig ist. Die OOB-Performance wurde für VirtuaLAB PCIe optimiert. Das Hauptinteresse der meisten Kunden liegt aber auf dem Funktionsumfang von VirtuaLAB PCIe, zum Beispiel das Speichern/Wiederherstellen von Kontrollpunkten, dem Protokollanalysator, der Flexibilität und dem erweiterten Debugging.

Bei der Migration von der InCircuit-Emulation (ICE) zur VirtuaLAB-Emulation hatte eine Kundenanwendung bei der ICE einen Ausgangswert von zehn Minuten für die Initialisierung des Chips. VirtuaLAB PCIe benötigte für die gleiche Initialisierung und das Booten 14 Minuten. Mit der Kontrollpunkt-Speicher-/Wiederherstellungs-Funktion von VirtuaLAB konfigurierte die Lösung den Chip in nur vier Minuten. Auf diese Weise wandelte die Verwendung eines Initialisierungs-Checkpoint-Images also eine vierminütige Verzögerung in eine sechsminütige Beschleunigung.

Um ein Gefühl für den virtuellen Durchsatz im Vergleich zum Echtzeit-Durchsatz zwischen Emulation und Prüftisch zu bekommen, dient ein Anwendung, die auf dem Prüftisch eine Laufzeit von 15 Sekunden hatte. Das entspricht bei der in Bild 2 dargestellten PCIe-VM-Implementierung einer Emulationszeit von 30 Minuten.

Die wesentlichen Qualitäten einer VM-Emulationsplattform sind das einfache Debuggen schwieriger Probleme und weniger spezifische Verifikationsplattformen. VirtuaLAB PCIe kann für Pre- und Post-Silizium verwendet werden. Zudem bietet VirtuaLAB PCIe den Vorteil, dass alle Transaktionen zwischen Host und Emulator zu 100 % als Plattform-Software existieren. Deshalb sind auch alle Transaktionen zu 100 % sichtbar.

Das VM-Paradigma verbessert die Debugging-Fähigkeiten. VirtuaLAB gestattet auch eine dedizierte Anwendung des Protokoll-Analysators, der dem PCIe-Analysator von LeCroy sehr ähnlich sieht. Ein detailliertes GUI-Frontend fasst diese Informationen in einem Dienstprogramm zusammen, das auf den gesamten PCIe-Stack zugreifen kann. Der Analysator ist direkt mit dem VM-PCIe-Stack gekoppelt und bietet somit für alle Traces und Analysen eine extrem schnelle Time-To-Visibility (siehe auch Bild 4).

Verifikation von Hard- und Software

Bei der gemeinsamen Verifikation von Hard- und Software in Veloce-Emulation erfüllen VirtuaLAB PCIe und Ethernet VM die großen Anforderungen hinsichtlich des Kanalmanagements der Geräte. VM decken dabei jedoch mehr Funktionen ab. Moderne Entwicklungsaspekte zeigen auf, wie Speicherung/Wiederherstellung von Kontrollpunkten, Protokollanalysator, Flexibilität bei der Softwarekonfiguration, Benutzerfreundlichkeit und erweiterte Debug-Funktionen deutlich verbessert werden und sich in einer einzigen Virtualisierungs-Plattform kombinieren lassen.

* Ron Squiers ist Network Solutions Specialist bei Mentor Graphics.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken

 

Copyright © 2017 - Vogel Business Media