Hardware-Verifikation Chip-Design mit Software-IDE

Amiq Consulting
Amiq Consulting

Eigentlich spricht nichts dagegen, eine Software-Entwicklungsumgebung auch für das Hardware-Design einzusetzen. Denn im Grunde genommen macht Hardware-Design nichts anderes, als Algorithmen statt in Programmcode in feste Schaltkreise zu „gießen“. Allerdings gab es für die im Hardware-Design verwendeten Beschreibungssprachen keine vernünftigen Lösungen. Doch das hat sich geändert.

Integrierte Entwicklungsumgebungen (Integrated Development Environment - IDE) sind in der Software-Gemeinschaft fest etabliert. Die Open-Source-IDE Eclipse wurde mehr als fünf Millionen Mal heruntergeladen. Die Daten, die der Mitbewerber NetBeans 2008 veröffentlichte, zeigten eine Benutzung seiner IDE von über zwei Millionen Benutzern in der ganzen Welt. Kommerzielle IDEs, etwa Visual Studio von Microsoft, sind ebenfalls weit verbreitet.

Die Benutzung einer IDE hat für Software-Ingenieure viele Vorteile und erweisen sich auch für die Hardware-Verifikation als sinnvoll. Die dabei benutzten Sprachen umfassen C, C++ und SystemC, darüber hinaus die auf Verifikation spezialisierten Sprachen e und SystemVerilog. Da sich Software- und Hardware-Entwicklung bzw. Hardware-Verifikation ähneln, wird allgemein angenommen, dass auch in der Hardware-Entwicklung der Einsatz einer IDE vorteilhaft ist.

Die moderne IDE

Eine moderne IDE ist viel mehr als ein bloßer Editor, sowohl in Bezug auf Features als auch auf Architektur. Zudem machen hoch optimierte grafische Schnittstellen die Einarbeitung intuitiv und erleichtern das Erlernen der zusätzlichen Funktionen. Bild 1 zeigt die Hauptfunktionen einer IDE. Außerdem ist eine IDE die zentrale Steuerungszentrale der Entwicklungswerkzeuge. Eine Schlüsselkomponente ist die kontextsensitive Benutzeroberfläche, die zu jedem Zeitpunkt die vom Benutzer gebrauchten Informationen und Steuerungselemente anzeigt und gleichzeitig ablenkende Informationen verbirgt. Vorteilhaft ist die Fähigkeit der IDE, die vorhandene Toolchain, einschließlich Simulatoren, zu steuern. Dies hat den Vorteil, dass andere bzw. zusätzliche Werkzeuge in die IDE integriert werden können, ohne die Werkzeuge zu ändern.

Wenn sie an Code-Entwicklung orientiert ist, überprüft eine IDE den Code auf die Syntax und kann Schlüsselwörter automatisch vervollständigen.

Im Vergleich zu normalen Texteditoren und anderen Tools der Dateiverarbeitung liegt der grundlegende Vorteil solcher kontextsensitiver IDEs darin, dass sie die Zusammenhänge zwischen vielen verschiedenen Aspekten des Designs wahrnehmen und verwalten. Das heißt, sie arbeiten auf einer Projektbasis, indem sie mehrere Informationsquellen mit der laufenden Datei verbinden und es dem Benutzer vermitteln. Wenn ein Ingenieur sich an die Vorteile eines solchen Systems gewöhnt hat, will er nicht mehr zum einfachen Texteditor zurückkehren!

Warum nicht auch für die Hardware-Verifikation?

Angesichts dieser beeindruckenden Features und Vorteile - warum kommen IDEs im Hardware-Bereich nicht häufiger zum Einsatz und besonders in der Hardware-Verifikation, die wesentlich eine Aufgabe der Software ist? Wir sind der Meinung, es gibt drei Hauptgründe dafür:

  • Der Grad an Komplexität in einer typischen Hardware-Verifikation ist erheblich kleiner als in vielen reinen Software-Projekten (Betriebssysteme, Finanztransaktionen, Spiele usw.). Bei den Software-Projekten sind sowohl die Code-Basis als auch die assoziierten Bibliotheken viel größer.
  • Frühe Open-Source-Plug-ins für Hardware-Architektur und Verifika-tionssprachen (VHDL, Verilog, e, SystemVerilog) waren enttäuschend umgesetzt und schlecht unterstützt.
  • Ingenieure für Hardware-Verifikation zögerten, Zeit zu investieren, um den Umgang mit IDEs zu lernen. Eine Verifikationsumgebung mit ihren unterschiedlichen Compilern, Simulatoren und Sprachen ist schon kompliziert genug, und es ist ein ständiger Kampf um das Minimieren der Anzahl der benutzten Werkzeuge.

Betrachtet man zunächst das Thema der IDE-Lernkurve, dann ist festzustellen, dass IDEs sich in den letzten Jahrzehnten kontinuierlich verbessert haben. Sie sind sehr benutzerfreundlich, und wer eine IDE zum ersten Mal verwendet, kann mit den Grundfunktionen des Systems beginnen. Eine moderne IDE „beleidigt“ man nicht, wenn man sie lediglich als Editor benutzt. Auch mit diesem Herangehen kann man von der Autovervollständigung, Syntaxhervorhebung usw. profitieren, weil das Tool die benutzte Sprache automatisch erkennt. Auf diese Weise kann ein Verifikations-Ingenieur damit beginnen, die Anzahl der Werkzeuge, die er direkt zu steuern hat, zu reduzieren - die IDE wird zuerst den aktuellen Editor des Benutzers ersetzen, später andere Werkzeuge wie sed, grep, awk, und make. Sie kann auch Quellcode-Werkzeuge wie SVN und CVS kontrollieren sowie Aufrufe des Compilers, Simulators, Debuggers usw. verwalten. Obwohl letztere Tools aus dem Fluss nicht verschwinden, wird deren Verwendung durchsichtig, sobald sie in die IDE integriert werden.

Das klingt sehr gut, aber - wie gesagt - die Unterstützung von Verifikationssprachen in IDEs durch Open Source waren enttäuschend. Die Ursache dafür dürfte der relativ kleine Umfang der Hardware-Communities sein. Während Eclipse und NetBeans alleine mehrere Millionen von Benutzern zählen, schätzen wir, dass die Anzahl der Hardware-Architektur- und Verifikationsbenutzer nur einige tausend beträgt. Die Gesamtzahl der Hardware-Architektur- und Verifikationsbenutzer ist wahrscheinlich geringer als die Zahl der Open-Source-IDE-Software-Entwickler weltweit - Eclipse alleine verzeichnet rund 200 Open-Source-Projekte, nahezu 1.000 „Committers“ (Entwickler, die Software Updates einreichen), und über 160 Mitgliedsfirmen (siehe www.eclipse.org).