Automatisierung des UVM Register Abstraction Layer (RAL)

Es gibt wohl kaum eine Innovation im Bereich der elektronischen Designautomatisierung (EDA), die so viel Einfluss hatte wie die Universal Verification Methodology (UVM). Nach Jahrzehnten der Ad-hoc-Simulation für Designer und einigen wenigen fortgeschrittenen Verifikationsteams, die automatisierte Methoden verwendeten, hat die UVM alle an der Chipentwicklung Beteiligten in eine neue Ära geführt. Verifikationsingenieure haben nun Zugang zu objektorientierter Programmierung, Constrained Random Stimulus, selbstüberprüfenden Tests, wiederverwendbaren Modellen, funktionaler Abdeckung, Assertions und vielem mehr. Sowohl UVM selbst als auch die SystemVerilog-Sprache, auf der es aufbaut, sind Industriestandards, die es den Teams ermöglichen, EDA-Tools verschiedener Hersteller zu kombinieren und auf Wunsch problemlos zwischen den Tools zu wechseln.

Dieser Beitrag konzentriert sich auf den UVM Register Abstraction Layer (RAL), auch UVM Register Layer genannt. Die heutigen großen System-on-Chip (SoC)-Entwürfe enthalten viele Steuer- und Statusregister, auf die oft sowohl von eingebetteter Software oder Treibern als auch von der Hardware aus zugegriffen werden kann. Die Überprüfung, ob diese Register korrekt funktionieren, ist ein wichtiger früher Schritt in der Verifikation. Anschließend müssen die Register manipuliert und verfolgt werden, während Funktionstests für den Rest des Designs durchgeführt werden. UVM RAL bietet einen standardisierten Satz von Basisklassenbibliotheken und -methoden, die den Aufbau eines objektorientierten Modells für den Zugriff auf speichergemappte Register und Speicher im Design erleichtern. Das Modell enthält Registerkomponenten, die die Werte der Register im Design widerspiegeln und die erwarteten Werte der Register zur Überprüfung der Testergebnisse enthalten.

• write()/read()
  Ausführen eines physischen Schreib-/Lesevorgangs auf der Registertransferebene (RTL) des Designs
  Nach einem Schreibvorgang wird der gespiegelte Wert aktualisiert
• poke()/peek()
  Schreiben/Lesen direkt in das RTL-Register unter Umgehung der physikalischen Schnittstelle
  Nach einem Schreibvorgang wird der gespiegelte Wert aktualisiert
• set()/get()
  Direktes Schreiben/Lesen der gewünschten Wertkomponente, ohne Zugriff auf das Design
• update()
  Wenn sich der gewünschte Wert vom gespiegelten Wert unterscheidet, rufen Sie die Methode write() auf.
  Dadurch wird der gespiegelte Wert aktualisiert
• mirror()
  Aufrufen der read()-Methode, um den gespiegelten Wert zu aktualisieren, damit er mit dem RTL-Design übereinstimmt
  Kann den Designwert mit dem gespiegelten Wert vergleichen, bevor er aktualisiert wird

UVM RAL bietet viele Funktionen zur Erstellung von Modellen, die die komplexen Register- und Speicherstrukturen in modernen SoCs widerspiegeln. Jedes Register kann mehrere Felder enthalten, von denen jedes unabhängig gelesen oder geschrieben werden kann. Mehrere Register können in Registerdateien gruppiert werden, die eine beliebige Anzahl von Registern oder Unterdateien enthalten können. Registerblöcke können eine beliebige Anzahl von Registern, Registerdateien, Speichern oder Unterblöcken enthalten. Für jedes Element in einem Registermodell – Feld, Register, Registerdatei, Speicher oder Block – gibt es eine Klasseninstanz, die die Lese- und Schreiboperationen für dieses Element abstrahiert. UVM RAL unterstützt sowohl den Front-Door-Registerzugriff über die physikalische Hardwareschnittstelle als auch den Back-Door-Zugriff direkt auf das RTL-Register. UVM RAL enthält auch eine Registertestsequenzbibliothek mit vordefinierten Testfällen, die zur Verifizierung der Register und Speicher verwendet werden können.

Bei all dieser Flexibilität und Leistungsfähigkeit ist das Schreiben des UVM-RAL-Modells keine triviale Aufgabe. Die Standard-Basisklassen, -Methoden und -Sequenzen bieten eine hervorragende Grundlage, aber die Verifizierungsteams möchten die Erstellung von RAL-Modellen so weit wie möglich automatisieren. Glücklicherweise ist es einfach, diese Modelle und den RTL-Code gleichzeitig automatisch zu generieren, und zwar aus einer gemeinsamen Spezifikation. Die IDesignSpec (IDS)-Lösung von Agnisys bietet diese Möglichkeit und unterstützt zahlreiche Spezifikationsformate, darunter den SystemRDL-Standard. Für noch mehr Automatisierung können Verifikationsingenieure ein von Agnisys bereitgestelltes Plug-in für Microsoft Word oder Microsoft Excel verwenden, um ihre Register in einem intuitiven grafischen Format zu spezifizieren. In der Abbildung unten spezifiziert der Benutzer ein Register mit 6 verschiedenen, benannten Bitfeldern. IDS übernimmt diese Eingabe und generiert automatisch das rechts neben dem Pfeil gezeigte UVM-RAL-Modell.

Die Angabe einer Registerdatei ist ebenso einfach, wie in der folgenden Abbildung dargestellt. Die entsprechende SystemRDL-Beschreibung ist enthalten. SystemRDL ist eine der möglichen Ausgaben von IDS, kann aber auch als Eingabe für Benutzer dienen, die die Beschreibung manuell schreiben möchten, anstatt die Plug-ins oder den in der Agnisys IDS-NG-Lösung enthaltenen speziellen Editor zu verwenden. Die Definitionen für einen Registerblock, der mehrere Registerdateien enthält, und für einen Speicher werden ebenfalls dargestellt.

IDS bietet viele Optionen, um die Vielfalt der SoC-Designs zu berücksichtigen. Register, Felder und Bits können als lesend/schreibend oder nur lesend spezifiziert werden, wobei unterschiedliche Werte für Hardware- und Software-Zugriff möglich sind. Dies ist besonders nützlich für Konfigurationsregister, die von der eingebetteten Software beim Booten gesetzt und dann gelesen, aber nie vom Hardware-Design geändert werden. IDS unterstützt mehr als 20 spezielle Registertypen, darunter Shadow, Lock, Trigger-Buffer, Interrupt, Counter und External. Die generierten RTL-Designs und die UVM-RAL-Modelle spiegeln diese Optionen genau wieder. IDS kann optional eine funktionale Abdeckung in die generierten Registermodelle aufnehmen. Dies umfasst die Abdeckung der gelesenen oder geschriebenen Bits, der Werte in Feldern, der gelesenen oder geschriebenen Adressen in einer Adresskarte oder einer beliebigen Kombination davon. Der Benutzer hat die volle Kontrolle darüber, welche Art von Abdeckungscode für ein bestimmtes Register oder einen Block generiert wird.

RAL ist ein gutes Beispiel für die ausgefeilten Verifikationstechniken, die das UVM ermöglicht. SoC-Entwicklungsteams können beliebig komplexe Register und Speicher definieren, in der Gewissheit, dass sie die Designs, die diese Strukturen enthalten, auch verifizieren können. Agnisys IDS hebt das Register- und Speicherdesign und die Verifikation auf die nächste Stufe, indem es eine einfache Spezifikation und automatische Generierung von RTL-Code, UVM-RAL-Modellen, C/C++-Headern für Embedded-Programmierer und verschiedene Formen der Dokumentation ermöglicht. Diese Fähigkeit kommt jedem Mitglied des SoC-Teams zugute, insbesondere den Verifikationsingenieuren, die UVM-basierte Tests schreiben und ausführen.