Institut für Technik der Informationsverarbeitung (ITIV)

2. Die Hardwarebeschreibungssprache VHDL

2.1 Geschichtliche Entwicklung von VHDL

Die Entwicklung von VHDL (V HSIC H ardware D escription L anguage) basiert auf einer Initiative des amerikanischen Verteidigungsministeriums, das durch eine einheitliche Sprache zur Dokumentation die enormen Kosten für Wartung und Weiterentwicklung von elektronischen Systemen reduzieren wollte. Nach Vorversuchen wurde 1983 der Auftrag an Intermetrics, IBM und Texas Instruments erteilt, eine entsprechende Sprache mit ersten Programmen zur Unterstützung zu entwickeln. Im August 1985 wurde die erste Version vorgestellt und im Februar 1986 an das IEEE zur Normierung übergeben. Im Dezember 1987 wurde mit "VHDL" (IEEE-Norm 1076-1987) der erste IEEE-Standard für Hardwarebeschreibungssprachen festgelegt. Dieser Standard definiert die Syntax und Semantik der Sprache, nicht jedoch die Anwendung!

Die Unterstützung von VHDL durch Softwarehersteller wuchs und mittlerweile hat die Sprache einen solch hohen Verbreitungsgrad erreicht, daß sich kaum jemand der damit einhergehenden Wandlung beim Entwurf elektronischer Systeme entziehen kann.

Nach IEEE-Richtlinien muß eine Norm alle 5 Jahre überarbeitet werden. Der für 1992 vorgesehene Prozeß zur Neudefinition der Norm hat sich allerdings derart verzögert, daß sie die Bezeichnung IEEE 1076-1993 erhalten hat. Noch länger wird es dauern, bis Softwarehersteller die neuen Konstrukte in ihre Programme integriert haben.

2.2 Design-Methodik mit VHDL

Mit VHDL wurde nicht nur ein neues Datenformat oder eine neue Sprache eingeführt, sondern zusammen mit der Durchgängigkeit der Beschreibung eines Systems von der Spezifikation zur Gatternetzliste mit Hilfe von VHDL konnten viele neue Werkzeuge entwickelt werden, die eine komplett neue Entwurfsmethodik begründet haben.

Einige wesentliche neuen Tools dienen zur:

  • Spezifikationserfassung,
  • graphischen Systembeschreibung mit Möglichkeiten zur frühzeitigen Simulation,
  • Generierung von VHDL-Code aus dieser graphischen Beschreibung
  • Synthese

Nach der Erfassung der Aufgabenstellung über Ablaufdiagramme und Flußpläne erfolgte bisher der Entwurf manuell bis zur Gatternetzliste, die graphisch über sog. Schematic Entry Tools in den Rechner eingegeben wurde, selten mit einfachen Logikentwurfswerkzeugen.

Der Anfangspunkt der Rechnerunterstützung wurde beim Top-Down Design im Lauf der Zeit weit in Richtung frühe Entwurfsphasen verschoben. Mit Hilfe einer Beschreibungssprache wie VHDL kann das System bereits frühzeitig beschrieben und auch simuliert werden. Fehler und notwendige Korrekturen werden somit viel früher entdeckt.

Es existieren auch Werkzeuge, die eine graphische Eingabe des Entwurfs gestatten (z.B. in Form von Statecharts, erweiterten Automatengraphen). Diese Tools bieten zumeist auch die Möglichkeit zur Simulation. Häufig kann aus einer solchen graphischen Beschreibung dann anschließend (synthetisierbarer) VHDL-Code auf Register-Transfer-Ebene erzeugt werden.

Stehen diese Möglichkeiten der automatischen Code-Generierung nicht zur Verfügung, muß die VHDL-Beschreibung entsprechend manuell modifiziert werden, denn z.Zt. erfordern verfügbare Synthesewerkzeuge eine Systembeschreibung auf Register-Transfer-Ebene.

Bei der sich anschließenden Synthese der VHDL-RT-Beschreibung wird eine noch technologieunabhängige Beschreibung auf Logikebene erzeugt. Die Entscheidung für das Umsetzen auf eine bestimmte Technologie ("Technology Mapping") und einen bestimmten Hersteller kann somit erst zu einem möglichst späten Zeitpunkt erfolgen. Anschließende Simulationen auf Logikebene können zeigen, ob die Randbedingungen (Chipfläche, zeitlichen Anforderungen, maximale Verlustleistung) auch erfüllt werden.

Danach sind die Testbitmuster für den Produktionstest zu erzeugen. Wenn beim Entwurf entsprechende Teststrukturen noch nicht berücksichtigt wurden, sind diese an dieser Stelle hinzuzufügen.

Auf Basis der technologiespezifischen Netzliste werden das Layout bzw. die Programmierdaten für die Produktion erzeugt. Danach können die notwendigen Informationen für eine sehr genaue Timing-Verifikation in die Logikebene zurückgereicht ("Backannotation"), und somit vom Layout herrührende Fehler detektiert werden.

2.3 Aufbau eines VHDL-Modells

Die Beschreibung eines VHDL-Modells besteht aus drei Teilen, nämlich einer "Entity", einer oder mehreren "Architectures" und einer oder mehreren "Configurations". VHDL-Beschreibungen können hierarchisch aufeinander aufbauen, d.h. es sind Zusammenschaltungen von existierenden Modellen in Form von Netzlisten möglich. Diese Modelle nennt man struktural.

Im Gegensatz dazu kann ein Modell auch eine Verhaltensbeschreibung unter Verwendung von zahlreichen Operatoren und programmiersprachenähnlichen Konstrukten enthalten.

Schnittstellenbeschreibung (Entity)

In der Entity wird die Schnittstelle (Ein- und Ausgänge, Parameter) beschrieben, sowie Unterprogramme und sonstige Vereinbarungen, die für alle zugeordneten Architectures gelten sollen.

Architektur (Architecture)

Eine Architecture enthält die Beschreibung des Inhalts eines Modells, wobei es dafür verschiedene Möglichkeiten gibt, z.B. eine funktionale oder eine strukturale Beschreibung. Einer Entity können mehrere Beschreibungen auf verschiedenen Ebenen oder auch verschiedene Designalternativen zugeordnet sein. Eine Schaltung kann also z.B. als Verhaltensmodell auf Register-Transfer-Ebene und als Netzliste auf Logikebene beschrieben werden.

Konfiguration (Configuration)

In der Configuration wird festgelegt, welche Architecture einer bestimmten Entity zugeordnet ist und welche Zuordnungen für die Komponenten in der Architecture gelten. Hier können auch hierarchisch den untergeordneten Entities bestimmte Architectures zugeordnet werden; außerdem ist es möglich, Parameterwerte an Komponenten zu übergeben.

Package

Ein Package enthält gemeinsame Daten und Definitionen für mehrere Design-Units wie Typdeklarationen, Konstanten oder Prozeduren, und ist Teil einer Library. Standardmäßig werden bei VHDL die Packages standard und textio bereitgestellt, die allgemeine Typen wie character, string, boolean, bit, bit_vector, integer usw., sowie die zugehörigen Grundfunktionen enthalten. In der Regel steht auch ein Package für den verwendeten Logiktyp zur Verfügung, z.B. die Definitionen der neunwertigen Logik std_logic im Package std_logic_1164 von IEEE.

 

Das folgende Beispiel zeigt die VHDL-Beschreibung eines ODER-Gatters mit zwei Eingängen ohne Modellierung der Laufzeiten:

   ENTITY or2 IS
PORT (a,b: IN bit; y: OUT bit);
END or2;


ARCHITECTURE behavioral OF or2 IS
BEGIN
y <= a OR b;
END behavioral;


CONFIGURATION or2_config OF or2 IS
FOR behavioral
END FOR;
END or2_config;

Hinweis: VHDL-Beschreibungen sind nicht case-sensitiv. Zur besseren Übersicht gilt für die Beispiele dieses Skripts jedoch folgende Konvention: GROSSBUCHSTABEN kennzeichnen Schlüsselwörter; Kleinbuchstaben eigene, d.h. frei wählbare Namen.

2.4 Compilieren und Simulieren

Design Libraries

Bevor ein mit VHDL beschriebener Entwurf simuliert werden kann, muß das Modell zunächst übersetzt (compiliert) werden. Compilierte Designs werden in sog. Design Libraries aufbewahrt. Sie können Packages, Entities, Architectures und Configurations enthalten und sind im Dateisystem meist als eigenes Verzeichnis realisiert. Eigene Modelle werden in die sog. Working Library übersetzt. Zusätzlich können in jede VHDL-Beschreibung Elemente aus anderen Bibliotheken, den Resource Libraries, eingebunden werden.

Die in einem VHDL-Modell verwendeten Libraries werden über logische Namen gehandhabt, die mit dem realen Pfad im Dateisystem über werkzeugspezifische Aktionen verknüpft werden. In VHDL-Modellen müssen die verwendeten Bibliotheken mit der LIBRARY -Anweisung vor den Design-Einheiten bekanntgegeben werden.

Abhängigkeiten beim Compilieren

Beim Compilieren bestehen verschiedene Abhängigkeiten unter den Design-Einheiten:

Zum einen müssen die Hierarchieebenen in aufsteigender Reihenfolge compiliert werden, d.h. Primitiv-Gattermodelle vor Modellen, die diese Gatter instantiieren. Zum anderen gilt bei den Design-Einheiten die Abhängigkeit von Bild 5. Demnach können Architectures erst compiliert werden, nachdem die Entity und das zugehörige Package erfolgreich übersetzt wurden. Das letzte Glied in der Kette ist die Configuration. Realisieren kann man dieses Konzept, indem die Design-Einheiten in einzelne Files geschrieben werden und in der entsprechenden Reihenfolge compiliert werden, oder indem man sie in der Reihenfolge in ein File schreibt, das beim Compilieren seriell abgearbeitet wird.

 

Entities, Architectures und Configurations basieren alle auf den Definitionen in den verwendeten Packages. Diese müssen daher als erste compiliert werden. Um nicht bei jeder kleinen Änderung z.B. in einer Funktionsdefinition, alle darauf basierenden Modelle neu übersetzen zu müssen, kann das Package in zwei Einheiten aufgespalten werden ("deferring"): in Package (enthält die Deklaration von Funktionen, Konstanten, usw.) und Package Body (Definition von Konstanten, eigentliche Funktionsbeschreibungen, usw.). Änderungen im Package Body bedingen somit nicht das Neu-Compilieren aller darauf aufbauenden Design-Einheiten.

Zusammenhänge bei der Simulation

Der Compiler wird unter Angabe des Filenamens aufgerufen, das die zu übersetzenden Design-Einheiten enthält. Die ausführbaren Dateien werden vom Compiler in der sog. Working-Library abgelegt und können dann vom Simulator verwendet werden.

2.3 Simulationsalgorithmus

VHDL-Simulatoren arbeiten nach dem gleichen Funktionsprinzip wie herkömmliche Digital-simulatoren: einem ereignisgesteuerten Algorithmus. Danach werden nur Zeitpunkte untersucht, zu denen auch Signaländerungen auftreten. Der Simulator trägt sämtliche zugewiesenen Signal-änderungen ("events") in eine sog. Ereignisliste ("event-queue") ein, d ie dann mit fortschreitender Simulationszeit abgearbeitet wird.

Treten zu einem absoluten Zeitpunkt mehrere Ereignisse auf, so werden diese nicht zur exakt gleichen Zeit durchgeführt, sondern um eine infinitesimal kleine Zeit (in VHDL mit "delta" bezeichnet) versetzt. Dieses "delta" hat nur Einfluß auf den Simulationsalgorithmus und kann von außen nicht bemerkt werden - die Ereignisse finden quasi gleichzeitig statt.