Hardware-Verifikation
Chip-Design mit Software-IDE
Fortsetzung des Artikels von Teil 1
Zielgruppe: für Open Source zu klein
Die Hardware-Gemeinschaft ist einfach nicht groß genug, um IDE-Projekte in Form von Open Source auf die Beine zu stellen. In diesem Fall lohnt es sich viel mehr, auf kommerzielle Lösungen zu setzen. Glücklicherweise gibt es diese nun für alle wesentliche Sprachen (VHDL, Verilog, e, SystemVerilog). Trotzdem ist Open Source eine gute Sache für die Hardware-Gemeinschaft. Viele kommerzielle Plug-ins für Hardware-Sprachen fügen sich in Open-Source-IDEs ein, so dass die resultierenden IDEs funktionsstark und relativ fehlerfrei sind. Durch die Verfügbarkeit solcher kommerzieller Plug-ins wurde ein bedeutendes Hindernis für den Einsatz von IDEs in der Hardware-Gemeinschaft beseitigt (siehe zum Beispiel www.dvteclipse.com).
Das letzte Hindernis für den Einsatz von IDEs war die relativ geringe Code-Komplexität bei der Hardware-Verifikation - im Gegensatz zu Software-Projekten. Hardware-Ingenieure behaupten, sie bräuchten keine Hilfe von einer IDE zur Entwicklung und Verwaltung ihres Codes. Für moderne Verifikationssprachen trifft das jedoch nicht mehr zu.
Moderne Verifikationssprachen wie e und SystemVerilog sind erheblich umfangreicher als VHDL und Verilog-Sprachen, die für das Design der Schaltungen selbst benutzt werden. Zudem benutzt ein Hardware-Architekt hauptsächlich eine synthesefähige Untergruppe von entweder VHDL oder Verilog, und dies bedeutet eine noch größere Einschränkung der Sprachenmöglichkeiten. Hingegen sind e und SystemVerilog komplexe Verhaltenssprachen mit besonderen Konstrukten zur Unterstützung von Hardware-Testing. Dazu gehören die Erzeugung von constraint-basierten Zufallstests, Coverage, Events, temporal Expressions und Assertions. Die Verwendung solcher Konstrukte vereinfacht erheblich die Aufgabe der Beschreibung von Verifikationskomponenten.
Tatsächlich ist es nicht ungewöhnlich, dass der Code einer Verifikationsumgebung den Code des Design under Test (DUT) überwiegt - in Bezug auf Code-Zeilen, Compile-Zeit, Laufzeit und anderen Metriken. Es liegt ja auf der Hand, wenn man bedenkt, dass eine Verifikationsumgebung üblicherweise ein komplettes funktionales Modell des DUT (als Referenz) umfasst, zusammen mit dem Code für die Tests. Außerdem enthält ein Verifikationssystem oft eine Menge redundanten Codes, da Verifikationsumgebungen möglichst wiederverwendbar und deshalb für mehrere, ähnliche DUTs anwendbar sein müssen. Alles in allem ist viel Code zu verwalten.
Und wenn der Umfang der Sprachen und der Verifikationsumgebungen ungenügend wäre, gibt es nun immer mehr Verifikations-IP und zugehörige Standards, die beim Coding einer Verifikationsumgebung zu berücksichtigen sind. Im Gegensatz zu Silizium-IP hat eine Verifikations-IP keine harten oder festen Varianten - es ist immer „soft“, und aus diesem Grund muss man sich eine erhebliche Code-Datenbank aneignen und wiederverwenden. Eine IDE erweist sich als sehr hilfreich, wenn man mit eingehender Verifikations-IP zu tun hat. Sie kann rasch Statistiken über ein Package liefern, die Navigation im Code und seiner Klassenhierarchie ermöglichen und jegliche Inkonsistenzen mit den Coding-Standards des Benutzers auffinden.
Codierungsstandards sorgen für Wiederverwendbarkeit
Jobangebote+ passend zum Thema
Heute können Codierungsstandards aus den Standards der Universal Verification Methodology (UVM) oder deren Vorgängern (z.B. OVM und VMM) aufgebaut werden. Die mit diesen Standards assoziierten Klassenbibliotheken und Methoden sind zu wichtigen Referenzen für die Hardware-Verifikation mit e und SystemVerilog geworden. Sie stellen einen hoffnungsvollen Schritt in Richtung erhöhter Wiederverwendung von Verifikations-IP und besonders einer Neutralität des Simulators für Verifikationsumgebungen dar. Damit können die Benutzer ihre Verifikationsumgebungen zwischen Simulatoren unterschiedlicher Hersteller leichter portieren. Mit der Nutzung der Bibliotheken und der Unterstützung der Methoden kann eine IDE eine maßgebliche Hilfe für den Benutzer darstellen (Bild 2), und IDE-Plug-ins, die diese Standards überprüfen, sind im Handel erhältlich.
Drei Einsatz-Szenarien
Zunächst kann man sehen, dass der Faktor Codekomplexität, der IDEs in der Software-Entwicklung populär gemacht hat, nun auch in der Welt der Hardware-Verifikation einzieht. Seitdem die früheren Hindernisse für deren Einsatz im Hardware-Bereich erheblich reduziert worden sind, ist zu erwarten, dass IDEs eine viel breitere Anwendung erleben werden, zuerst von Verifikations-Ingenieuren und dann von Entwicklern.
Drei Anwendungs-Szenarien zeigen, wie die Verwendung einer modernen IDE zur Wertschöpfung beitragen kann. Überlastete Verifikations-Ingenieure sind die deutlichsten Nutznießer der IDE. Für sie stellt die Beherrschung einer mächtigen IDE einen erheblichen beruflichen Vorteil dar. Freilich gilt dieses Argument auch für die Architekten, insbesondere für die, die komplexe Verifikationsumgebungen erstellen. Heute müssen sowohl die Architekten der Verifikationsumgebungen als auch die Verifikation-Ingenieure mehrere Computersprachen, Bibliotheken und Standards routinemäßig beherrschen, und eine gute IDE hilft dabei, dies unter Kontrolle zu halten.
Ein zweites Szenario stellt der technische Leiter dar. Sein Beitrag zum Codieren der Verifikationsumgebung mag zwar begrenzt oder sogar null sein, aber er muss in der Lage sein, Verständnis von Architektur- und Verifikationsthemen mit seinem Team zu teilen, Fortschritte zu messen und Krisen vorherzusehen und auch externe Verifikations-IP zu bewerten. Eine IDE, von Natur aus ein projektbezogenes (statt dateibezogenes) Werkzeug, kann sich dabei als ausgezeichneter Helfer erweisen.
Das letzte Szenario ist das eines internen oder externen Beraters, der eingesetzt wird, um an einem Verifikations-Projekt mitzuarbeiten und der deshalb einen großen Umfang von Code in kurzer Zeit überblicken muss. Die Fähigkeit der IDE, den Code zu profilieren und im Code zu navigieren, ist wesentlich für ihn. Unerlässlich ist auch zum Beispiel die Möglichkeit zum Refactoring, die es ermöglicht, weitreichende Änderungen in einer Codebasis mit stark reduziertem Risiko vorzunehmen.
Starkes Wachstum erwartet
Als Fazit zeigt sich, dass IDEs sich in der Verifikationsgemeinschaft weiter verbreiten werden und mit kurzer Verzögerung auch in der Hardware-Entwicklung. Obwohl der Einsatz von IDE-Technologie in diesen Bereichen gegenüber der allgemeinen Software-Entwicklung deutlich zurückliegt, wird ihre Nutzung durch die rasche Entwicklung der Hardware-Verifikationssprachen, -IPs und -Standards stark gefördert. Dank der Verfügbarkeit von kommerziellen Plug-ins für Open-Source-IDEs für wesentliche Sprachen und Standards (e, System-Verilog, UVM, OVM, VMM, VHDL, Verilog) sind frühere Hürden für die Annahme spürbar reduziert worden. Am ehesten bieten die auf Open-Source-Stiftungen basierenden Marktprodukte das beste Kosten-/Nutzenverhältnis, und da erwarten wir in den nächsten Jahren ein starkes Wachstum.
Die Autoren:
| Christian Amitroaie |
|---|
| ist Co-Gründer von Amiq Consulting (www.amiq.ro) und kürzlich von Amiq EDA (www.dvteclipse.com). |
| Andrew Betts |
|---|
| ist eigenständiger Consultant, tätig im Bereich von technischem Vertrieb und Marketing für EDA (www.icondasolutions.com). |
andrew.betts@icondas.com
- Chip-Design mit Software-IDE
- Zielgruppe: für Open Source zu klein
