Suchen

Standardisierung für VHDL-Testbench-Architekturen

| Autor / Redakteur: Espen Tallaksen * / Sebastian Gerstl

Die Architektur eines FPGA-Designs spielt eine entscheidende Rolle hinsichtlich Qualität und Entwicklungszeit von FPGAs. Dasselbe gilt für Testbenches, die jedoch meist alles andere als strukturiert sind. Die Open-Source-Methodik UVVM (Universal VHDL Verification Methodology) soll dies ändern.

Firmen zum Thema

Üblicher Aufbau einer UVM (Universal Verification Methodology). Für deren Anwendung ist erst einmal eine neue Sprache (System Verilog) zu erlernen - obwohl mehr als die Hälfte aller FPGA-Entwicklungen sich auf VHDL statt System Verilog berufen. Eine eigene, auf VHDL spezielisierte Verification-Methodik (Universal VHDL Verification Methodology, UVVM) bietet sich also an.
Üblicher Aufbau einer UVM (Universal Verification Methodology). Für deren Anwendung ist erst einmal eine neue Sprache (System Verilog) zu erlernen - obwohl mehr als die Hälfte aller FPGA-Entwicklungen sich auf VHDL statt System Verilog berufen. Eine eigene, auf VHDL spezielisierte Verification-Methodik (Universal VHDL Verification Methodology, UVVM) bietet sich also an.
(Bild: Bitvis )

Die Verifikation macht im Schnitt 50% des gesamten Workloads in einem FPGA-Projekt aus. Und gewöhnlich entfällt nahezu die Hälfte des Verifikationsaufwands auf das Debuggen. Es gibt also enormes Verbesserungspotential bei der Verifikation im Allgemeinen und besonders beim Debuggen.

SystemVerilog vs VHDL

Die großen Technologie- und Toolanbieter kennen diese “Verifikationslücke” und bieten entsprechende “Lösungen” an. Diese beinhalten aber oft eine äußerst komplexe Methodik – die UVM (Universal Verification Methodology). Für deren Anwendung ist erst einmal eine neue Sprache (System Verilog) zu erlernen, und sehr kostspielige Tools sind anzuschaffen. Eine überwältigende Mehrheit der FPGA-Designer in Europa verwendet VHDL als Entwurfs- und Verifikationssprache (50% weltweit) – warum sollte man also davon abkommen?

Bildergalerie

Effiziente Erweiterung mit VHDL

VHDL eignet sich für fast alle FPGA-Projekte, und FPGA-Entwickler können VHDL weiterhin als Sprache nutzen, die sie schon beherrschen. Bei Bedarf lassen sich schrittweise neue Funktionen hinzufügen – eine behutsame und effiziente Erweiterung der vorhandenen Testbench und Sprache. Der Erfolg einer FPGA-Entwicklung steht und fällt mit der Struktur und Architektur.

Designstruktur und -architektur

Bild 2 zeigt die kritischsten Faktoren für Entwurf und Verifikation über ein Projekt. Während der Designphase sind wir uns dieser Faktoren am meisten bewusst. Wir unterteilen unser Design daher in mehr oder weniger autonome Module mit eigenständigen Funktionen, z.B. UART, SPI, DMA-Controller, ADC, etc. Diese Module (bzw. VHDL-Einheiten/-Komponenten) erhalten von der Software Befehle und führen dann ihre Aufgaben aus. Die Software selbst erledigt in dieser Zeit völlig andere Aufgaben. Tritt eine Störung auf, schlägt das entsprechende Modul normalerweise Alarm, meist in Form eines Interrupts. Großer Vorteil: Das Top-Level-Design eines FPGAs ist einfach zu verstehen. Wir kennen die Module und deren Funktionen. Das Bussystem zu den Modulen ist standardisiert (z.B. AXI4-lite oder Avalon), und die Busschnittstelle der Module ist standardmäßig mit dem Bus kompatibel. Gesteuert wird alles über High-Level-Softwarebefehle.

Verifikationsstruktur und -architektur

Die oben beschriebene Designstruktur ist also äußerst effizient und gewährleistet eine hohe Produktqualität. Für Testbenches jedoch gibt es nach wie vor kein entsprechendes System bzw. keine solche Methodik. Die meisten Testbenches sind recht unstrukturiert – und hier kommt die UVVM ins Spiel.

  • Bei der UVVM wird die Designarchitektur gespiegelt. Daraus ergibt sich eine übersichtliche Testbench-Architektur, in der auch die Vorzüge einer guten modularen Struktur erhalten bleiben:
  • Verifikationsmodule mit verständlicher Funktionalität und Schnittstelle
  • Standardisiertes Bussystem vom Sequencer zu den Verifikationsmodulen
  • Standardisierte Busschnittstelle auf allen Verifikationsmodulen

In der UVVM werden diese Verifikationsmodule VHDL Verification Components, kurz VVC, genannt.

Architektur der Testbench UVVM

Die UVVM-Architektur ähnelt der FPGA-Designarchitektur mit externem Software-Sequencer wie oben beschrieben.

Der Test(fall)-Sequencer verteilt Befehle an die VVCs so, wie auch die Software Befehle an die FPGA-Module verteilt. Die VVCs führen dann ihre Tasks aus wie die FPGA-Module auch. Normalerweise ist dafür ein Zugriff auf ihre physikalische Schnittstelle zu behandeln. Beispiele: Ein FPGA-Modul soll Daten übertragen; das könnte auch Aufgabe eines VVC sein. Bei der oben beschriebenen UART-Testbench könnte der Test-Sequencer einen Befehl an das UART_TX_VVC senden, mit der Aufforderung, ein Byte an den RX-Eingang des UART zu übertragen.

Test-Sequencer-Schnittstellenbefehle

In der UVVM gibt es zwei Möglichkeiten, auf eine Schnittstelle des Prüflings zuzugreifen; am einfachsten erfolgt dies mit einer simplen BFM-Prozedur (Bus Functional Model), z.B.:

uart_transmit(x"4C", "Apply byte on UART RX"));

(Der letzte Parameter dient als Codezeilen-Kommentar und wird bei Bedarf ins Transcript geschrieben). Diese Prozedur wird direkt ausgeführt und liefert mithilfe des UART-Protokolls die Daten „x4C“ zum UART-RX. Wenn also der Test-Sequencer diese Prozedur aufruft, wird das UART-Protokoll bitweise ausgeführt. Dies nimmt eine gewisse Zeit in Anspruch. Der Test-Sequencer kann in dieser Zeit keine anderen Aufgaben ausführen.

Die CDM-Methode (Command Distribution Method) ist etwas erweitert und sieht wie folgt aus:

uart_transmit(UART_TX_VVC,1 x"4C",Apply byte on UART RX"));

Ruft der Sequencer diese Methode auf, wird erst einmal nur der Befehl an das als Zieladresse festgelegte VVC (rot dargestellt) übertragen, einschließlich Namen und Instanznummer des VVC, das den Befehl auf dem Prüfling ausführen soll. Die Übertragung des Befehls vom Test-Sequencer zum VVC beansprucht keine Zeit, daher steht der Test-Sequencer sofort für andere Aufgaben zur Verfügung und kann z.B. den Zugriff auf eine weitere Schnittstelle initiieren. Das zeitintensive UART-Protokoll wird durch das VVC behandelt.

Vollständiger Kurztest

Die nachfolgenden Test-Sequencer-Codezeilen zeigen einen kurzen Test, mit dem sich der gleichzeitige Zugriff auf alle Schnittstellen prüfen lässt. Dieses Beispiel stammt aus einer Testbench, die sich von der vorherigen etwas unterscheidet; die VVCs für UART-TX und -RX sind hier in einem VVC zusammengefasst, um die Wiederverwendbarkeit zu verbessern. In diesem Beispiel haben wir einen weiteren Zielparameter zur Angabe des Kanals (RX vs. TX) hinzugefügt.

sbi_write(SBI_VVCT,1, C_ADDR_TX_DATA, x"A0", "Send byte UART TX");
uart_expect(UART_VVCT,1,RX x"A0", "Check byte from UART TX");
uart_transmit(UART_VVCT,1,TX x"A1", "Apply byte on UART RX");
wait for C_FRAME_PERIOD;
sbi_check(SBI_VVCT,1, C_ADDR_RX_DATA, x"A1", "Check UART RX byte");

Die Mikroarchitektur ist entscheidend

Eine gute Top-Level-Architektur ist in einem FPGA-Design immer wünschenswert, reicht aber nicht aus. Ebenso wichtig ist eine durchgängig gute Mikroarchitektur bis zur untersten Ebene. Dies gilt natürlich auch für die Testbench: Die Architektur der VVCs muss leicht verständlich, modifizierbar und wiederverwendbar sein. Eine Standardisierung wäre auch hier mehr als hilfreich.

Ein VVC beinhaltet grundsätzlich die in Bild 4 gelb gekennzeichneten Blöcke. Das VVC sieht die vorher gezeigte CDM-Prozedur und akzeptiert ausschließlich Befehle, die genau an dieses VVC gerichtet sind. Dann stellt es den uart_transmit() Befehl in die Queue, und der Test-Sequencer kann weiterarbeiten. Der Executor holt den Befehl aus der Queue, identifiziert ihn als uart_transmit() Befehl und führt dann mit den übermittelten Parametern die BFM-Prozedur auf dem Prüfling aus.

Strukturierte VVC-Erweiterungen

Die hochstrukturierte VVC-Architektur bietet noch einen Vorteil: Weitere strukturierte Funktionen, z.B. für komplexere Schnittstellen, oder wiederverwendbare Funktionen, z.B. diverse Checker, lassen sich einfacher hinzufügen.

Ein Split Transaction Protocol, wie z.B. Avalon MM, sorgt häufig für Chaos in der Testbench. Es kann beispielsweise sein, dass die erste Leseantwort erst nach mehreren Leseaufrufen erfolgt. Bei der oben beschriebenen VVC-Architektur lässt sich dies extrem einfach und strukturiert handhaben. Der Base-Executor holt den Lesebefehl aus der Queue und identifiziert ihn als Split-Transaction-Zugriff. Er ruft die Read-Request BFM-Prozedur auf und übergibt gleichzeitig den Lesebefehl an die nächste Queue. Der Response-Executor holt diesen ab, ruft dann die Read-Response BFM-Prozedur auf und wartet die Antwort ab. So können beliebig viele Leseaufrufe zwischen beliebig vielen Leseantworten erfolgen, und trotzdem bleibt alles übersichtlich und strukturiert.

VVC-Implementierung

In der UVVM wird ein Skript bereitgestellt, mit dem sich ein VVC für neue Schnittstellen erzeugen lässt. Der generierte Code ist ein Template, in dem die Stellen, an denen der Anwender eigene BFMs und Anpassungen hinzufügen muss, eindeutig gekennzeichnet sind. Im Falle von BFM-Prozeduren, welche der Anwender ja ohnehin auf einer Testbench vornehmen muss, dauert es nur etwa 30 Minuten, um ein komplettes VVC neu zu erzeugen. Nach Aussage von Doulos dauert es beim ersten Mal etwas länger, danach aber jeweils etwa 30 Minuten.

Vorläufige Zusammenfassung: Bestandteile einer Testbench

Die wichtigsten Bestandteile einer Testbench sind:

  • Top-Level Test-Harnisch – und ein umfassender Überblick
  • Verifikationsmodule – und deren Verständnis und Erstellung
  • Testfälle – Schreiben der eigentlichen Tests und Verständnis der gesamten Event-Sequenz

Die ersten beiden Punkte lassen sich mithilfe einer gut strukturierten Architektur umsetzen, sowohl auf oberster Ebene sowie innerhalb der VVCs. Beim letzten und wohl wichtigsten Punkt (mit dem Sie am längsten beschäftigt sein werden) muss man jedoch dafür sorgen, dass eindeutige High-Level-Befehle die gesamte Testbench steuern, einschließlich gleichzeitiger Aktivitäten auf mehreren Schnittstellen.

Standardisierung und anerkannte Methodik

Im Bereich der FPGA-Entwicklung hat die Standardisierung über mehrere Jahrzehnte auf einem hochwertigen Architekturkonzept mit Kontroll- und Status-Registern, Bussystem, autonomen Modulen und High-Level-Softwarebefehlen stattgefunden. Dies hat nicht nur eine effiziente FPGA-Entwurfsmethodik hervorgebracht, sondern auch eine effizientere Softwareentwicklung, bei der der Softwareentwickler nicht mehr jedes Detail der zu steuernden Module kennen muss. Die Vorteile liegen auf der Hand. Es stellt sich also die Frage, warum dies nicht auch für FPGA-Testbenches umgesetzt wurde, wo letztlich dasselbe Szenario anzutreffen ist, mit einem Sequencer, der mehrere Schnittstellen regelt.

Genau das leistet heute die UVVM und sorgt darüber hinaus für eine Standardisierung der wichtigsten Komponenten:

  • Kontroll- und Status-Schnittstelle für VVCs
  • Protokoll zwischen Sequencer und VVCs
  • Befehle für den Sequencer (für gemeinsame Tasks)
  • Interne VCC-Architektur
  • Befehlsqueue-System
  • Handling der Multithread-Schnittstellen (z.B. Split Transactions)
  • Synchronisationsmethoden zwischen den VCCs (oder anderen Prozessen)
  • Waiting und Timeout
  • Messaging (Transcript) und Alarmbehandlung
  • Multicast- und Broadcast-Befehle
  • Debugging-Support

Internationale Unternehmen mit einem starken Fokus auf VHDL und Verifikation setzen jetzt auf die UVVM. Aldec und Mentor Graphic, die beiden wichtigsten Anbieter für VHDL-Simulatoren, sind an dieser Methodik sehr interessiert. Aldec bietet bereits Webinare zur UVVM an und setzt diese in Kürze auch für seine Simulatoren ein. Doulous, führender internationaler Schulungsanbieter im Bereich FPGA und ASIC, empfiehlt die UVVM für VHDL-Testbench-Architekturen. Der endgültige Beweis dafür, dass die UVVM richtig Fahrt aufnimmt, kommt von der ESE (European Space Agency): Sie steuert als Sponsor über 200.000 Euro für eine Erweiterung der UVVM-Methodik bei und wird ihren Zulieferern nahelegen, bei der FPGA-Verifikation die UVVM einzusetzen.

Eine praktische, strukturierte Testbench fürs FPGA-Design

UVVM bietet eine leistungsstarke, universelle Testbench-Architektur, die für jeden FPGA- oder Hardwaredesigner einfach zu verstehen ist. Standardisierte Verifikationsmodule werden wie Legosteine zusammengefügt, und ein zentraler Test-Sequencer (oder mehrere) kann direkt danach High-Level-Befehle zur Steuerung der Verifikationsmodule und damit mit der gesamten Testbench ausgeben. So sind auch Entwickler, die keine FPGAs entwerfen, in der Lage, umfassende Testfälle zu schreiben. Entwickler können einen eigenen Test-Harnisch bzw. Testfälle erstellen, und zwar schneller, effizienter und mit einem höheren Grad an Wiederverwendbarkeit als bisher.

Eine strukturierte Verifikation ist ausschlaggebend für Effizienz, Qualität und Wiederverwendbarkeit. Die kostenfreie Open-Source-Lösung UVVM bietet eine sehr strukturierte Methodik und offen zugängliche Bibliothek auf GitHub. Zudem ist die UVVM mit kostenfreien Open-Source-VVCs und -BFMs für UART, I2C, SPI, SBI, AXI4-lite, AXI4-stream, GPIO und Avalon MM verfügbar. Einer erfolgreichen Umsetzung von Projekten, in denen diese (oder ähnliche) Peripherals zum Einsatz kommen, steht also nichts im Wege.

Die UVVM wurde erst vor 2 Jahren vorgestellt; heute ist sie schon auf der ganzen Welt im Einsatz – und das mit sehr positivem Feedback. Wir sind jetzt bereit für die nächste Phase. Im 2. Quartal 2018 bieten wir einen Mechanismus an, über den sich VVCs (Open-Source und kommerziell) in der VHDL-Community gemeinsam nutzen lassen. Dank der Standardisierung, die die UVVM ermöglicht, lässt sich dies nun umsetzen.

Der Autor, Espen Tallaksen, ist auch als Referent auf demFPGA-Kongress 2018vertreten, wo er mehrere Vorträge zum Thema VHDL Testbench Verification halten wird. Nähere Informationen können Sie dem Programm zum FPGA-Kongress entnehmen.

* Espen Tallaksen ist Gründer und CTO von Bitvis AS, einem führenden Designzentrum für Embedded Software und FPGA in Norwegen.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 45327363)