Deutsche Notizen

In VHDL gibt es mehrere Möglichkeiten, um einen hierarchischen Entwurf zu implementieren. Die Sprache stellt hierfür vorallem die Philosophie von Entity/Architektur Paaren und deren Einbindung über Komponenten zur Verfügung. Dies führt zu einer strikten Trennung von Schnittstelle und Innenleben. Mit der Hilfe von Packages, Bibliotheken und einem verinheitlichten Codierstil ist es möglich, auch sehr große Entwürfe, die auf einige Textdateien aufgeteilt sind, zu handhaben. In der Simulation kann mittels der Konfiguration zwischen den unterschiedlichen Implementierungsalternativen hin- und herschalten.

Alle Teile eines VHDL Entwurfs müssen analysiert/compiliert werden, bevor sie simuliert oder synthetisiert werden können. Insgesamt exisiteren in VHDL fünf sogenannte Units: Entity/Architecture, Package/Package Body und Configuration. Eine Textdatei muß zumindest ein Unit enthalten, um compiliert werden zu können. Die Trennung des Package Body vom Package ist nicht unbedingt notwendig.

Nach dem Compilieren befinden sich die übersetzten Units in einer sogenannten Library (Bibliothek). Der Mechanismus der Library innerhalb von VHDL ist Platformunabhängig. Andererseits muß jede VHDL-Software den logischen Library-Namen auf einen physikalischen Pfad abbilden. Wenn beim Compilieren keine spezielle Library angegeben wird, dann werden die Units in die Default Library WORK übersetzt. Diese ist oftmals auf das Startverzeichnis der benutzten Software abgebildet. Dies kann aber meißt vom Benutzer umgestellt werden, z.B. durch eine Setup Datei.

Im obigen Beispiel ist der logische Bibliotheksname PROJECT1 in den Setup Dateien des Simulationstools und des Synthesetools auf das physikalische Verzeichnis “home/user_bill/VHDL_Stuff/project1_lib” abgebildet. Wenn ein Unit in diese Bibliothek abgelegt werden soll, muß sie beim Compielieren angegeben werden (z.B. “compile -library project1 p_frame_types.vhd”). Um die Objekte aus dem Package P_FRAME_TYPES benutzen zu können, muß die Bibliothek PROJECT1 mit der Library Anweisung sichtbar gemacht werden. Mit der nachfolgenden Use Anweisung können dann einzelne Units und einzelne Objekte angesprochen werden.

Library Anweisungen werden vor einem Unit geschrieben und sind dann auch nur für das nachfolgende Unit, gegebenenfalls für die entsprechenden secondary Units gültig. Wird eine Bibliothek also vor einer Entity referenziert, so muß man diese für die Architekuren dieser Entity nicht mehr machen, unabhängig ob die Architekturen in der gleichen Textdatei der Entity stehen, oder nicht, wie z.B. die Architektur BEH der Entity X. Auf der anderen Seite muß die Bibliothek EXAMPLE explizit vor der Entity X referenziert werden, falls in ihr oder in ihren Architekuren etwas aus dieser Bibliothek benutzt werden können soll.

Die Bibliotheken WORK und STD sind von aus aus sichtbar, d.h. diese müssen nicht über eine Library Anweisung referenziert werden. Die Bibliothek STD enthält das Package STD, welche ebenfalls automatisch sichtbar ist, sowie das Package TEXTIO, da aber gegebenenfalls explizit referenziert werden muß.

Bibliotheken können sehr gut zum Trennen von VHDL Objekten unterschiedlicher Projekte benutzt werden. Es können dabei aber Probleme auftreten. Wenn für den Compiler mehrere nicht unterscheidbar Objekte existieren, wird die Compilierung abgebrichen und eine Fehlermeldung auftreten. Dies wird z.B. deutlich, wenn man in zwei verschiedenen Packages jeweils eine Prozedur mit dem gleichen Namen und den gleichen Parametern deklariert. Sind beide Prozeduren für den Compiler sichtbar und soll eine davon benutzt werden, so wird eine illegale Redeklaration gemeldet werden.

Eine Library Anweisung alleine erlaubt einem nicht den Zugriff auf die Units und Objekte innerhalb dieser Bibliothek. Hierfür muß zusätzlich eine Use Anweisung verwendet werden. Die meißten Regeln für die Library Anweisung gelten auch für die Use Anweisung und so erscheinen diese auch meißtens am gleichen Ort.

Die Use Anweisung macht unterschiedliche Elemente aus einer Bibliothek für den Compiler sichtbar. Es ist sogar möglich einzelne Objekte aus einem Package einzeln sichtbar zu machen. Normalerweise benutzt man aber das Schlüßelwort 'all', um alle Objekte eine Packages sichtbar zu machen. Man kann das Schlüßelwort 'all' ebenfalls benutzen, um den gesamten Inhalt einer Bibliothek sichtbar zu machen. Use Anweisungen können auch in den Deklarationsbereichen von Entities, Architekturen, etc. benutzt werden.

Während die Library Anweisung immer notwendig ist, können Objekte auch über sogenannte “selected names” statt über eine Use Anweisung angesprochen werden.

Packages sind ein Mechanismus, um verschiedene Objekte für mehrere Desing Units sichtbar zu machen. Üblicherweise werden Standardlösungen in Packages festgehalten, wie z.B. Daten Typen und entsprechende Unterprogramme wie Typen Konvertierungsfunktionen, Prozeduren und Komponenten für Datenverarbeitungsaufgaben, etc.. Ein PAckage Body wird auf jeden Fall benötigt, falls Unterprogramme definiert werden sollen, da in einem Package nur eine Deklaration eines Unterprogrammes stehen darf. Andererseits ist ein Package Body nur dann notwendig, wenn Unterprogramme oder deferred constants definiert werden sollen. Man beachte, daß nur die Objekte durch eine Use Anweisung sichtbar gemacht werden können, die im Package stehen; die Objekte eines Package Bodys können nicht sichtbar gemacht werden.

Die Bibliotheken WORK und STD sowie das Package STANDARD sind per Default sichtbar. Dementsprechend sind die entsprechenden VHDL Anweisungen nicht notwendig.

Existiert eine Package Body, so sollte dies in eine eigene Textdatei geschrieben werden. Ansonsten wäre es nicht möglich, bei Änderungen im Body diesen dann auch nur alleine zu compilieren. Es kann nur der Inhalt des Packages mit einer Use Anweisung sichtbar gemacht werden; entsprechend muß bei Änderungen im Body auch nur dieser neu compiliert werden.

Andererseits ist ein Package Body nur dann notwendig, wenn Unterprogramme oder deferred constants definiert werden sollen.

Im obigen Beispiel wird der Typ T3 und die Prozedur P2 nur im Package Body deklariert. Dies führt zu einem Fehler während der Compilierung, da diese beiden Objekte nicht in der entsprechenden Architektur sichtbar sind.

Mit einer sogenannten deferred constant (“verschobene Konstante”) kann man den Wert einer Konstante (und damit unter Umständen den Großteil der Funtion eines Entwurfes; siehe “See Parameterization via Constants”) ändern. Hierzu muß aber nur das Package Body neu compiliert werden!

Mit dem Schlüßelwort 'all' als Suffix in der Use Anweisung können alle Objekte, die in einem Package deklariert wurden, sichtbar gemacht werden. Wenn nur einzelne Objekte sichtbar gemacht werden sollen, so müssen dies einzeln in jeweils eine Use Anweisung mit ihrem Nameals Suffix der Use Anweisung angesprochen werden: <code vhdl> Library ps; USE ps.p.C; <code>