Code mit Portable Stimulus schnell testen und wiederverwenden

Anbieter zum Thema

Siemens EDA

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Schnelle Verifikation, leichte Portierbarkeit: Der Portable Stimulus Standard verspricht hohe Produktivität für die Embedded-Entwicklung. Doch wie lässt sich die Methode am effizientesten umsetzen?

In der Embedded-Branche hat sich das Produktivitätsversprechen des Accellera Portable Stimulus Standard (PSS) schnell herumgesprochen. Entwicklern soll es hiermit möglich sein sicherzustellen, dass alle Gedanken, der Aufwand und die Zeit, die in den Aufbau neuer Verifikationsumgebungen und die Erstellung aussagekräftiger Tests investiert wurden, wiederverwendet und auf verschiedene Technologien und Projekte übertragen werden können. In diesem Artikel beschreiben wir eine Methodik und einen Planungsprozess, um doppelten Aufwand zu minimieren und die Vorteile der Wiederverwendung durch den Einsatz von PSS zu maximieren.

Erste Schritte – Testziele beschreiben und erfassen

Zunächst sollten Sie eine Bestandsaufnahme der vorhandenen Ressourcen durchführen, um so frühere Investitionen zu erhalten. Sie könnten überrascht sein von der Menge an Daten in Ihren Entwicklungsumgebungen, die zur Implementierung einer Portable Stimulus-Umgebung verwendet werden können. SystemVerilog (SV)-Constraints und Test-Implementierungscode sind zwei gute Quellen, um mit PSS-Beschreibungen zu beginnen.

PSS Testziele werden in einer erklärenden Weise erfasst. Erklärende Beschreibungen eignen sich, wie wir bei der Nutzung von deklarativen SV-Constraints festgestellt haben, sehr gut für die Wiederverwendung und Automatisierung. Das Format der SV-Constraints ist den PSS-Constraints so ähnlich, dass die Wiederverwendung so einfach wie das Kopieren und Einfügen der SV-Constraints in das PSS-Modell sein kann. Typische Beispiele für die Wiederverwendung sind Konfigurationsklassen, welche die Regeln für die Konfiguration von IP- und Subsystem-Betriebsmodi festlegen. Mit wenig Aufwand können selbst Informationen, die in einem maschinenlesbaren Format erfasst wurden, leicht in PSS-Constraints umgewandelt werden.

Existierende Umgebungen haben eine Vielzahl von Beschreibungen für Tests. Diese liegen häufig in einer Weise vor, die für die Verwendung mit einer PSS-Beschreibung überarbeitet werden müssen. Der Code zur Implementierung von Tests für Portable Stimulus-Testbeschreibungen wird fast immer in einer der folgenden Sprachen implementiert, z. B. SV, C++ oder C. In UVM-Umgebungen sollten Sie nach Nutzsequenzen suchen, die einfache Operationen an einem IP durchführen. Mitunter werden diese Sequenzen mit zufälligen Constraints und Variablen erstellt. In anderen Fällen erhalten Unterprogramme Argumente zur Steuerung der verschiedenen Betriebsmodi. In beiden Fällen kann diese Testimplementierung problemlos von einer PSS-Beschreibung genutzt werden.

Prüfstrategien planen und Tests implementieren

Die Definition einer Prüfstrategie, die von IP- bis auf SoC-Ebene angewendet werden kann, wird wichtig, wenn die vertikale Wiederverwertung (d. h. die Wiederverwendung der Testziele von der IP-Blockebene bis zur SoC-Ebene) für Ihre Organisation eine hohe Priorität hat. In diesem Fall wird dringend empfohlen, sich darauf zu konzentrieren, die Typen von Tests, die ihre Gültigkeit bis auf die SoC-Ebene behalten, in die PSS-Beschreibung einzubauen. Üblicherweise basieren diese Tests auf speicherinternen Daten und beziehen sich auf den allgemeinen Erfolg (oder Misserfolg) einer Operation.

Es ist jederzeit möglich, funktionale Tests mit Implementierungstests zu erweitern. Beispielsweise kann auf Blockebene der Betrieb der DMA-Engine aus Portable Stimulus-Sicht durch rein funktionale Tests abgedeckt werden (d. h., ob die Daten am Zielort mit den Daten in der Quelle übereinstimmen.) Das Blocklevel Scoreboard kann weiterhin aktiv sein, um Details der DMA-Übertragung zu überprüfen. Diese Strategie kann auch auf Subsystem- und SoC-Ebene ausgeweitet werden.

Es ist praktisch obligatorisch, mehrere Implementierungen von Tests verfügbar zu haben. Für die mit UVM arbeitenden Verifikationsingenieure ist es wichtig, dass sie die von UVM angebotenen Dienstleistungen, wie z. B. Registermodelle, nutzen können. Ebenso wichtig ist es für Verifikationsingenieure, die mit Embedded-Software arbeiten, dass sie die ihnen bekannten Registerzugriffsmechanismen nutzen können.

Das Definieren von gemeinsamen APIs für Testcode und die Sicherstellung, dass Tests für verschiedene IPs kompatibel sind, gewährleistet die Wiederverwendung von Portable Stimulus. Es ist wichtig, eine größtmögliche Übereinstimmung zwischen den verschiedenen Implementierungen der Tests zu erreichen. Die Entwicklung eines gemeinsamen API, das von allen Implementierungen genutzt werden kann, ist ein erster Schritt in diese Richtung. Die Nutzung eines funktionsgleichen API, selbst wenn die zugrunde liegenden Details ein wenig abweichen, vereinfacht die Aufgabe der Abbildung von PSS auf die verschiedenen Implementierungen der Tests erheblich.

Anlegen einer zusätzlichen Zwischenebene

Die UEX-Hardware-Access Layer bietet ein C-API für verschiedene Zugriffsarten auf Speicher und die Threading-Funktionen von Plattformen. Durch die Nutzung eines solchen Kompatibilitäts-Layers ist es möglich, den Code für Tests einer Embedded-Software-Umgebung viel früher im Verifikationsprozess zu entwickeln und zu debuggen und wiederzuverwenden. Unabhängig davon, ob es sich um einen Kompatibilitäts-Layer handelt, der sich über mehrere Plattformen erstreckt, oder um eine Reihe umgebungsspezifischer APIs, ist es wichtig zu überlegen, wie die Tests für verschiedene IPs zusammenwirken. Wahrscheinlich benötigt der Code für alle IPs Zugriff auf den Speicher. Tests für viele IPs werden Benachrichtigungen benötigen, falls ein Interrupt auftritt.

Der folgende Code zeigt eine Interrupt Service Routine für ein DMA-IP, die das UEX-API nutzt, um die DMA-Register auszulesen und Warteschleifen aufruft, wenn ein DMA-Transfer abgeschlossen ist. Die UEX-Bibliothek ermöglicht die Ausführung desselben Codes in einer UVM-Umgebung, einer reinen Embedded-Software-Umgebung oder einer betriebssystembasierten Umgebung. Diese Wiederverwendung von Tests ermöglicht ein frühzeitiges Debuggen von Code für den Zugriff auf IPs und verringert die Nacharbeit.

Aktionen und Tests für einen bestimmten IP-Typ sollen mit mehreren Instanzen dieses IPs interagieren. Das Spezifizieren eines einheitlichen Verfahrens, um vom PSS Layer die IP-Instanz, auf die zugegriffen wird, auswählen zu können, ist wichtig, um die Durchgängigkeit über verschiedene Implementierungen der Tests hinweg zu gewährleisten. Die Definition einer wiederverwendbaren Basiskomponente und eines Aktionstyps stellt sicher, dass alle in Ihrer Organisation entwickelten PSS-Beschreibungen gleichermaßen angeben, welche IP-Instanz verwendet wird.

Eine bewährte Methode bei der Entwicklung von PSS-Testcode ist die Minimierung des Datenvolumens, das zwischen dem PSS-Modell und dem Testcode ausgetauscht wird. Üblicherweise ist die PSS-Beschreibung ein Ausführungsplan, der Operationen auf einem übergeordneten Level spezifiziert. Die Details dieser Operationen setzt die Testimplementierung um.

Nehmen wir die Aktionen, die zu einem DMA Transfer gehören. Vor der Übertragung von Daten von einem Speicherort sollte dieser Speicherort initialisiert werden. Anstatt eine PSS-Beschreibung zu verfassen, um den Speicher byteweise aufzufüllen, gibt die PSS-Beschreibung einen Speicherbereich zur Initialisierung an und delegiert die Details der Speicherinitialisierung an die Funktion der Testimplementierung.

Dieser Beitrag ist erschienen in der Fachzeitschrift ELEKTRONIKPRAXIS Ausgabe 9/2020 (Download PDF)

* Matthew Ballance ist Produktingenieur und Techniker für Portable Stimulus bei Mentor Graphics.

(ID:46492043)