Vereinfachung der Assertionsvalidierung durch UVM-Callbacks

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Siemens EDA

Assertions bringen unmittelbare Vorteile für den gesamten Design- und Verifizierungszyklus. Sie erleichtern das Erkennen funktioneller Fehler, ermöglichen es dem Anwender, Fehler näher an der eigentlichen Ursache zu finden, und sorgen dafür, dass Fehler frühzeitig im Entwicklungsprozess gefunden werden. Alle Herausforderungen, vor denen Ingenieure bei der Kodierung und Prüfung von Assertions stehen, sind es wert, gelöst zu werden.

Eine Assertion ist eine bedingte Anweisung, die auf das Fehlverhalten innerhalb eines Designs hinweist, indem sie diesen Fehler kennzeichnet und dadurch erfasst. Assertions werden zur Validierung eines Hardware-Designs in verschiedenen Phasen seines Lebenszyklus verwendet, wie formale Verifizierung, dynamische Validierung, Laufzeitüberwachung und Emulation. Um die Assertions im Verifikationszyklus effektiv einsetzen zu können, müssen sie während der Prüfung des legalen Designverhaltens ausgeübt werden und auch dann ausgelöst werden, wenn illegales Verhalten im Design festgestellt wird.

Wenn eine Vielzahl von Assertions für das Auslösen unter illegalen Umständen validiert werden muss, ist ein Callback-Mechanismus zum Erstellen dieser Szenarien besonders effektiv, da sie nur minimale Veränderungen der Testbench-Umgebung erfordern und dadurch den Aufwand für die Erstellung komplexer Szenarien zur Validierung der Assertions minimieren.

Ein Callback ist per Definition eine „Call-after“-Funktion, die die Absicht des ursprünglichen Funktionsaufrufs verändert. Callbacks sind ein gängiger Mechanismus bei der funktionalen Verifikation, um den ursprünglichen Inhalt eines Sequenzelements so zu ändern damit ein gewünschtes Szenario herbeigeführt wird. Dies ermöglicht eine dynamischere und feinkörnigere Kontrolle bei der Auswahl, welches Sequenzelement fehlerhaft modifiziert wird und wie viele solcher „Fehler“ in einem Test auftreten, um das Design einem Belastungstest zu unterziehen. Da Callbacks die einfache Erstellung nuancierter und komplexer Stimulusbildung ermöglichen, sind sie entscheidend für die Assertionsverifikation.

In diesem Artikel wird beschrieben, wie in Verifizierungs-IPs implementierte Callbacks für die Validierung von Assertions in Designs mit PCIe und anderen paketbasierten Protokollen verwendet werden können.

Die Verifizierung mit Assertions ist in der Regel ein integraler Bestandteil des Verifizierungs-IP-Entwicklungszyklus. Im ersten Schritt erfolgt das Codieren der Assertions. Im zweiten Schritt werden die Assertions validiert, indem Szenarien erstellt werden, in denen die Assertions vollständig ausgeführt werden, um sicherzustellen, dass sie nicht unter dem beabsichtigten Designverhalten jedoch unter fehlerhaften Szenarien ausgelöst werden. Während der Phase der Szenarien-Generierung bieten Callbacks enorme Vorteile, da der Verifikationsingenieur keine zusätzlichen Tests schreiben muss. Stattdessen werden Callbacks benutzt, die die ursprünglichen Stimuli ändern und dadurch neue interessante Szenarien generieren. Dies wird durch eine einfache Erweiterung der Callback-Klasse erreicht, um die virtuelle Methode (do_callback(...)) zu überschreiben, die aufgerufen wird, wenn ein Sequenzelement vom BFM ausgeführt wird. Dies ist besonders bei paketbasierten Protokollen wie PCIe nützlich, wo Paketfelder beschädigt werden müssen und Callbacks dafür eine feinkörnige Steuerung ermöglichen.

Die Aufgabe des Validierungsingenieurs ist es, sicherzustellen, dass die Assertions in jedem relevanten Szenario validiert werden. Callbacks können extrem wichtig sein, wenn die Assertionsvalidierung durch Manipulation der Felder eines Sequenzelements oder durch Initiierung eines Sequenzelements in einem Zustand durchgeführt wird, in dem dies nicht zulässig ist. Callbacks beschleunigen die Assertionsvalidierung, indem sie die gesamte Struktur für eine solche Manipulation in einer UVM-Testbench mit minimalen Updates und ohne Interaktion mit den bestehenden Sequenzen bereitstellen, die für die Generierung der Sequenzelemente verantwortlich sind.

Bei einem mehrschichtigen Protokoll wie PCIe, bei dem die Kommunikation zwischen Sender- und Empfänger-Elementen über sogenannte Pakete erfolgt, verbessert der Einsatz von Callbacks zur Assertionsvalidierung die Wirksamkeit erheblich. Durch den Einsatz eines Verifizierungs-IPs können die Paketinformationen über Callbacks geändert werden und alle paketbasierten Assertions lassen sich mit diesem Mechanismus einfach verifizieren. Werfen wir nun einen Blick auf ein Szenario aus jedem Transaktionsschicht-, Datenlink- und physischen Schichtpaket.

Fall 1: Transaktionsschichtbasierte Callbacks

Die übergeordneten Transaktionen im Gerätekern werden als Transaktionsschichtpakete (TLP) bezeichnet. Ein Verifizierungs-IP, wie der Questa Verification IP, ermöglicht die Änderung aller Felder eines TLP (sowohl Anfrage- als auch Fertigstellungs-TLPs). Möchte der Anwender eine Assertion zu den Feldern eines TLP validieren, kann er dies einfach tun, indem er die TLP-Felder über einen Callback fehlerhaft modifiziert.

Das PCIe-Protokoll besagt beispielsweise, dass für eine Anforderung von „Länge = 1 DW” der Wert des Feldes „Last Byte Enable“ Null sein sollte; wobei „Last Byte Enable“ der Byte-Enable-Wert für das letzte DWORD der Anforderung ist. Wenn Benutzer in der Simulation diesen Fehler in jedes Memory-Write-Paket der Länge 1 DW injizieren möchten, können sie dies wie in Abbildung 2 dargestellt tun.

Fall 2: Datenlinkschichtbasierte Callbacks

Datenlinkschichtpakete (DLLP) werden für eine Vielzahl von Zwecken verwendet, z. B. zur Gewährleistung der Integrität von TLPs, Flowkontrolle und Leistungsmanagement. Ebenso wie bei TLPs können Callbacks verwendet werden, um Fehler in DLLP-Pakete zu injizieren. Zum Beispiel wird lcrc zur Prüfung der Datenintegrität von TLPs und DLLPs verwendet. lcrc wird im TLP an die Datenlinkschicht (DLL) angehängt. Wenn der Wert des mit einem Paket verbundenen lcrc nicht mit dem berechneten Wert übereinstimmt, handelt es sich um eine Protokollverletzung. Dieses Fehlverhalten bzw. Auslösen von Assertions kann verifiziert werden, wie in Abbildung 3 dargestellt.

Fall 3: Auf der physischen Schicht basierende Callbacks

Die vielleicht effizienteste Nutzung von Callbacks ergibt sich aus der Änderung geordneter Satzfelder. Bei DLLPs und TLPs kann ein Paket weiterhin über eine Sequenz ausgeführt werden, sobald der Linkup stattgefunden hat. Die Verwendung einer Sequenz, um einen Fehler in einen geordneten Satz zu injizieren, bevor der Linkup stattgefunden hat, kann jedoch komplizierter und fehleranfälliger sein, da sich die Regeln für den geordneten Satz mit jedem LTSSM-Status ändern.

Callbacks hingegen ermöglichen es dem Anwender, einen Fehler viel kontrollierter zu injizieren. Soll beispielsweise anstelle eines TS2 OS ein CTRL_SKP Satz versendet werden, kann man dazu einfach Callbacks nutzen. Daher kann dieses ungültige Protokollszenario einfach über Callbacks validiert werden, wie in Abbildung 4 dargestellt.

Verwendung von Callbacks mit Verifizierungs-IP

Sehen wir uns nun genauer an, wie Callbacks in einem kommerziell erhältlichen Verifizierungs-IP (VIP) verwendet werden, in diesem Fall einem Questa Verification IP, von Mentor, einem Siemens-Unternehmen. Mit dem Questa VIP werden zunächst die Callback-Methoden und -Richtlinien so definiert, dass sie für alle Protokolle gelten. Für jedes spezifische Protokoll werden anschließend die Callback-Methoden von diesen Basisklassen abgeleitet.

Eine dieser Basisklassen heißt cb_policy, die sich von uvm_object ableitet. Sie definiert Methoden wie Register, Get und Return Callbacks. Diese Methoden werden als reine virtuelle Tasks oder Funktionen deklariert, damit die abgeleitete Klasse die Basisklassendefinition überschreiben kann.

Eine zweite Basisklasse wird von uvm_component abgeleitet und heißt cb_manager. Die run_phase() dieser Klasse ist eine Endlos Schleife, in der wir zuerst das Sequenzelement vom BFM erhalten und dann das geänderte Sequenzelement an das BFM zurücksenden. In separaten externen Tasks, die innerhalb der cb_manager-Klasse definiert sind, werden Callback-Sequenzelemente hinzugefügt und aus der Callback-Warteschlange gelöscht. Die Register-Callback-Methode wird basierend auf der Warteschlangengröße aktiviert.

Für jede protokollspezifische Callback-Implementierung wird jedes dem Protokoll eigene Sequenzelement aus der oben genannten Basisklassen abgeleitet. Die Namen werden vergeben als: <sequence_item_name_>_ cb_manager für die Klasse, die von cb_manager und <sequence_item_name>_cb_policy für die Klasse, die von cb_policy abgeleitet wird.

In der Klasse <sequence_item_name>_cb_policy werden die Register-, Get- und Return-Callback-Methoden je nach Art des jeweiligen Protokolls verbreitet. Die Aktivierung von Callbacks für ein bestimmtes Sequenzelement selbst beginnt mit der Aktivierung der Agenteneinstellungen in der build_phase eines Tests (die Klasse, wird von uvm_test abgeleitet), wodurch der

<sequence_item_name_>_cb_manager instanziiert wird. In der run_phase des Tests wird die Register-Callback-Methode durch den Aufruf der Add-Callback-Task (definiert innerhalb von cb_manager) aktiviert.

Das Hauptziel der Register-Callback-Methode besteht darin, die Callback-bezogene Task innerhalb des BFM zu initiieren, die eine Statusvariable setzt. Die Get-Callback-Methode wird aufgerufen, sobald die Statusvariable innerhalb des BFM gesetzt ist und dient dazu, das Sequenzelement vom BFM über DPI-Calls zu erhalten. Die gesamte Logik zur Bearbeitung der Felder des Sequenzelements befindet sich in der do_callback task, die in <sequence_item_ name_>_cb_manager definiert ist. Das geänderte Sequenzelement wird dann über DPI-Calls an das BFM zurückgegeben um anschließend auf den Bus geschrieben zu werden.

Fazit

Wenn eine Vielzahl von Assertions validiert werden soll, bieten Callbacks dem Verifikationsingenieur die Möglichkeit Zeit zu sparen, weil er nicht für jedes Szenario eine neue Sequenz schreiben muss. Sie sorgen für eine dynamischere und feinkörnigere Kontrolle. Die in diesem Artikel behandelten Szenarien sind sehr grundlegende Methoden, wie Callbacks umgesetzt werden können. Ein weiterer Vorteil von Callbacks ist die Kontrolle darüber, welche Pakete mit einem Fehler injiziert werden sollen. Ebenso lässt sich leicht die Anzahl der Pakete steuern, in die ein Fehler injiziert werden soll. Callbacks ermöglichen die mühelose Erstellung nuancierter und komplexer Stimuli und sind daher für die Assertionsverifizierung entscheidend.

Als Teil von Xcelerator, dem umfassenden und integrierten Software- und Dienstleistungsportfolio von Siemens Digital Industries Software, unterstützen Questa VIPs Unternehmen jeder Größe bei der Erstellung und Nutzung eines digitalen Zwillings, der Unternehmen neue Einblicke, Möglichkeiten und Automatisierungsebenen bietet, um Innovationen voranzutreiben und die Designs von morgen schon heute zu realisieren.

Die Autoren

* Akshay Sarup ist Product Engineer für CXL und PCIe bei Siemens EDA, mit Fokus auf dem Einsatz und der Produktdefinition der Questa Verification IP. Akshay Sarup verfügt über mehr als 20 Jahre Erfahrung im Bereich der funktionalen Verifikation, mit einem Hintergrund in der Entwicklung von Schnittstellenprotokollen nach Industriestandard unter Verwendung der UVM-Methodik.

* Mark Olen ist Product Marketing Group Manager der ICVS Division bei Siemens EDA. Sein Team ist verantwortlich für Produktmanagement und Marketing von der Enterprise-Verification-Plattform, einschließlich Simulation, formaler Verifikation, Verifikations-IP, portabler Stimulus-Generierung, einheitlichem Verifikationsmanagement und gemeinsamer Debug-Technologie. Mark hat über 30 Jahre in Vertriebs-, Marketing- und Managementpositionen in der Halbleiterdesign-, Fertigungs- und Testindustrie verbracht. Er hat einen Abschluss vom Massachusetts Institute of Technology.

Verifikation von Embedded Software durch Integration von Test und Beweis

Code mit Portable Stimulus schnell testen und wiederverwenden

(ID:47043453)