Mikrocontroller.net - Benutzerbeiträge [de]

Verilog

2012-11-23T12:04:27Z

Guenter: /* Datentypen: wire, reg */ Initialer Wert für reg

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z. B. prozedurale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Probleme in viele kleine Probleme. Bei objektorientierten Sprachen, wie z. B. C++, nimmt man Objekte und unterteilt ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch die gesamte Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design Taktgenau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthetisierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthetisierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z. B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthetisierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthetisierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthetisierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthetisierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Wie bei einer Programmiersprache üblich, müssen Datentypen vor ihrer Benutzung deklariert werden. Das geschieht unter Verilog wie folgt:

<verilog>
wire a;
reg b;
</verilog>

Einem reg wird in diesem Fall der Wert x zugewiesen und einem wire der Wert z. Bei der Deklaration kann einem reg auch bereits ein Anfangswert zugewiesen werden.

<verilog>
reg b = 0;
</verilog>

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0; // ??? Widerspruch zu "Ein reg muss innerhalb eines always oder initial Blocks seine Werte zugewiesen bekommen"
// Das ist richtig, aber der Einfachheit halber wurde das weggelassen.
// Es wäre auch möglich, eine "assign"-Anweisung zu verwenden

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll nun in diesem Beispiel die Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann es wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Das ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthetisierbarer Logik findet es weniger Verwendung.

Das ''always'' Konstrukt kann sowohl in Testbenches als auch in synthetisierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten verzögert und dann mit der Ausführung des ihm folgenden Konstruktes weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Zuweisung clk = ~clk; im Simulator vom momentanen Zeitpunkt um 10 Zeiteinheiten verzögert ausgeführt wird. Bei der Zuweisung selber wird dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthetisierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernt. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedes Mal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''' oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung erneut ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthetisierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen, dass diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always''-Blöcke, die parallel ausgeführt werden. Der erste ''always''-Block basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10'''-Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always''-Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eines der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always''-Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht, wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signale benutzt, d.h. Signale die ein Bit breit sind. Ein Bus wird von dem ''wire''-Statement abgeleitet. Er wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setze nur Bit 0

data[15:13] = 3'b110; // Setze Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setze Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setze Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite festgelegt und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' beschrieben. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweiften Klammern beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speichermodellierung durch Felder ==

Aus der Programmiersprache C ist das Konzept der Felder bekannt, um Elemente gleichen Datentyps aufzuzählen. In Verilog wird das gleiche Konstrukt z. B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8-Bit-breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Diese Syntax ist nur eine Verschmelzung der Syntaxen von Vektordefinitionen (die Bitbreite steht vor dem Bezeichner) mit der der Definition von Feldern (die Anzahl der Elemente steht nach dem Bezeichner).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die erste Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht, von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen, ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist es auch möglich, mehrdimensionale Speicher zu definieren, wie z. B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

An dieser Stelle möchte ich auf einen Kommentar von Jan Decaluwe, dem Entwickler von [http://www.myhdl.org MyHDL] hinweisen, der die Regelung als nicht notwendig erachtet und für die Mischung der beiden Zuweisungsarten eintritt:

http://article.gmane.org/gmane.comp.python.myhdl/827

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z. B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operationen:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz, dass Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z. B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 14
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 16-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanden, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 14

c = a + $signed(b);
</verilog>

== Vergleichsoperationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn ergeben größer- und kleiner-Operationen immer FALSCH wenn ein x- oder z-Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durchzuführen, gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen verknüpft werden. Wie von den gängigen Programmiersprachen bekannt, unterstützt Verilog die logischen Operationen:

* '''&&''' --> AND
* '''||''' --> OR
* '''!''' --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, dass letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus:
Bei einer kompilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden. Der Simulator arbeitet den übersetzten Quellcode in Zeitschritten ab. Dadurch kann die parallele Funktion von Hardware simuliert werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthetisierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z. B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z. B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z. B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z. B. [http://gtkwave.sourceforge.net/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z. B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z. B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthetisierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden Flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]
*[http://doolittle.icarus.com/~larry/vhd2vl/ VHDL to Verilog Konverter] unter Linux, Programme FLEX und Gnu-Bison müssen installiert sein
[[Category:FPGA und Co]]

Verilog

2009-09-24T09:49:26Z

Guenter: Rechschreibfehler behoben; große synthesierbar -> synthetisierbar Umwandlung

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteilt ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design Taktgenau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthetisierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthetisierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthetisierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthetisierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthetisierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthetisierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthetisierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthetisierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten verzögert und dann mit der Ausführung des ihm folgenden Konstruktes weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Zuweisung clk = ~clk; im Simulator vom momentanen Zeitpunkt um 10 Zeiteinheiten verzögert ausgeführt wird. Bei der Zuweisung selber wird dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthetisierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernt. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''' oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung erneut ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthetisierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signale benutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite festgelegt und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' beschrieben. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweiften Klammern beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

An dieser Stelle möchte ich auf einen Kommentar von Jan Decaluwe, dem Entwickler von [http://www.myhdl.org MyHDL] hinweisen, der die Regelung als nicht notwendig erachtet und für die Mischung der beiden Zuweisungsarten eintritt:

http://article.gmane.org/gmane.comp.python.myhdl/827

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanden, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen verknüpft werden. Wie von den gängigen Programmiersprachen bekannt, unterstützt Verilog die logischen Operationen:

* '''&&''' --> AND
* '''||''' --> OR
* '''!''' --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, dass letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer kompilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden. Der Simulator arbeitet den übersetzten Quellcode in Zeitschritten ab. Dadurch kann die parallele Funktion von Hardware simuliert werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthetisierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthetisierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]
*[http://doolittle.icarus.com/~larry/vhd2vl/ VHDL to Verilog Konverter] unter Linux, Programme FLEX und Gnu-Bison müssen installiert sein
[[Category:FPGA und Co]]

Verilog

2009-03-03T19:34:05Z

Guenter: /* =, <=; blockierende und nicht-blockierende Zuweisung */ Hinweis über die möglische Mischung mit Link zu Jan Decaluwes Nachricht

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteilt ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten verzögert und dann mit der Ausführung des ihm folgenden Konstruktes weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Zuweisung clk = ~clk; im Simulator vom momentanen Zeitpunkt um 10 Zeiteinheiten verzögert ausgeführt wird. Bei der Zuweisung selber wird dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''' oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung erneut ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signale benutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite festgelegt und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' beschrieben. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweiften Klammern beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

An dieser Stelle möchte ich auf einen Kommentar von Jan Decaluwe, dem Entwickler von [http://www.myhdl.org MyHDL] hinweisen, der die Regelung als nicht notwendig erachtet und für die Mischung der beiden Zuweisungsarten eintritt:

http://article.gmane.org/gmane.comp.python.myhdl/827

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen verknüpft werden. Wie von den gängigen Programmiersprachen bekannt, unterstützt Verilog die logischen Operationen:

* '''&&''' --> AND
* '''||''' --> OR
* '''!''' --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, dass letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer kompilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden. Der Simulator arbeitet den übersetzten Quellcode in Zeitschritten ab. Dadurch kann die parallele Funktion von Hardware simuliert werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2009-03-03T19:15:23Z

Guenter: /* Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung */ Schreibfehler

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteilt ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten verzögert und dann mit der Ausführung des ihm folgenden Konstruktes weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Zuweisung clk = ~clk; im Simulator vom momentanen Zeitpunkt um 10 Zeiteinheiten verzögert ausgeführt wird. Bei der Zuweisung selber wird dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''' oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung erneut ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signale benutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite festgelegt und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' beschrieben. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweiften Klammern beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen verknüpft werden. Wie von den gängigen Programmiersprachen bekannt, unterstützt Verilog die logischen Operationen:

* '''&&''' --> AND
* '''||''' --> OR
* '''!''' --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, dass letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer kompilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden. Der Simulator arbeitet den übersetzten Quellcode in Zeitschritten ab. Dadurch kann die parallele Funktion von Hardware simuliert werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2009-03-03T19:09:58Z

Guenter: /* always, initial */ Tippfehler

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteilt ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten verzögert und dann mit der Ausführung des ihm folgenden Konstruktes weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Zuweisung clk = ~clk; im Simulator vom momentanen Zeitpunkt um 10 Zeiteinheiten verzögert ausgeführt wird. Bei der Zuweisung selber wird dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''' oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung erneut ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen verknüpft werden. Wie von den gängigen Programmiersprachen bekannt, unterstützt Verilog die logischen Operationen:

* '''&&''' --> AND
* '''||''' --> OR
* '''!''' --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, dass letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer kompilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden. Der Simulator arbeitet den übersetzten Quellcode in Zeitschritten ab. Dadurch kann die parallele Funktion von Hardware simuliert werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2009-02-03T19:09:56Z

Guenter: /* Entwicklung der Hardwarebeschreibungssprache */ Schreibfehler behoben

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteilt ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten verzögert und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Zuweisung clk = ~clk; im Simulator vom momentanen Zeitpunkt um 10 Zeiteinheiten verzögert ausgeführt wird. Bei der Zuweisung selber wird dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen verknüpft werden. Wie von den gängigen Programmiersprachen bekannt, unterstützt Verilog die logischen Operationen:

* '''&&''' --> AND
* '''||''' --> OR
* '''!''' --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, dass letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer kompilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden. Der Simulator arbeitet den übersetzten Quellcode in Zeitschritten ab. Dadurch kann die parallele Funktion von Hardware simuliert werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2009-01-13T19:46:21Z

Guenter: /* always, initial */ Zutreffendere Formulierung des Verzögerungszeichens

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten verzögert und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Zuweisung clk = ~clk; im Simulator vom momentanen Zeitpunkt um 10 Zeiteinheiten verzögert ausgeführt wird. Bei der Zuweisung selber wird dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen verknüpft werden. Wie von den gängigen Programmiersprachen bekannt, unterstützt Verilog die logischen Operationen:

* '''&&''' --> AND
* '''||''' --> OR
* '''!''' --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, dass letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer kompilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden. Der Simulator arbeitet den übersetzten Quellcode in Zeitschritten ab. Dadurch kann die parallele Funktion von Hardware simuliert werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-10-16T13:52:47Z

Guenter: /* Verilog für Simulation */ Einheitliche Schreibweise von compilieren

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen verknüpft werden. Wie von den gängigen Programmiersprachen bekannt, unterstützt Verilog die logischen Operationen:

* '''&&''' --> AND
* '''||''' --> OR
* '''!''' --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, dass letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer kompilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden. Der Simulator arbeitet den übersetzten Quellcode in Zeitschritten ab. Dadurch kann die parallele Funktion von Hardware simuliert werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-10-06T15:16:22Z

Guenter: /* Logische Operationen */ Schreibfehler behoben

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen verknüpft werden. Wie von den gängigen Programmiersprachen bekannt, unterstützt Verilog die logischen Operationen:

* '''&&''' --> AND
* '''||''' --> OR
* '''!''' --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-10-06T15:12:14Z

Guenter: /* Arithmetische Operationen, signed, $signed */ Kleine Erweiterung der Erklärung

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operationen gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen. Der $signed() System Task wandelt einen unsigned Datentypen in einen signed um.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-10-06T15:07:02Z

Guenter: /* Logische Bit-Operationen */ Zur besseren Lesbarkeit die Operatoren Fett geschrieben

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*'''|''' --> OR
*'''&''' --> AND
*'''~''' --> NOT
*'''^''' --> XOR

Sie werden erweitert durch:
*'''~&''' --> NAND
*'''~|''' --> NOR
*'''^~''' oder '''~^''' --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

JTAG

2008-09-16T12:45:40Z

Guenter: /* FPGA JTAG */ FCPU-X platform cable

'''J'''oint '''T'''est '''A'''ction '''G'''roup, entwickelte den Standard IEEE 1149.1. Das JTAG-Protokoll ermöglicht das Programmieren, Debuggen und Testen von ICs, [[Prozessor]]en und [[FPGA]]s direkt in der Schaltung. Näheres insbesondere zu den möglichen Steckerbelegungen siehe in der [http://hri.sourceforge.net/tools/jtag_faq_org.html JTAG FAQ].

= Hardware =

== AVR JTAG ==

* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAGICE] (neuerdings gelegentlich auch ''JTAGICE mkI'' genannt) von Atmel.
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAGICE mkII] von Atmel.
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] von Atmel.
** [http://www.atmel.com/dyn/resources/prod_documents/doc8112.pdf AVR077: Opto Isolated Emulation for the DebugWIRE] (auch für AVR JTAGICE mkII nützlich)
* [http://gandalf.arubi.uni-kl.de/avr_projects/evertool/index.html Evertool und Evertool light] von Martin Thomas. Evertool unterstützt JTAG analog zu AVR JTAGICE und [[ISP]] nach [[STK500]] Protokoll. Evertool light nur JTAG.
* [http://aquaticus.info/jtag JTAG for AVR processors] bei Aquaticus ROV. (Englisch)
* [http://www.olimex.com/dev/avr-jtag.html AVR-JTAG] und [http://www.olimex.com/dev/avr-usb-jtag.html AVR-USB-JTAG] von [http://www.olimex.com/dev/index.html Olimex] (kommerziell). Alternativer Lieferant ist der [http://elmicro.com/de/avrjtag.html Elektronikladen].
* [http://www.gadgetpool.de/bestellen/catalog/product_info.php/cPath/22_27/products_id/35 AVR-JTAG] und [http://www.gadgetpool.de/bestellen/catalog/product_info.php/cPath/22_27/products_id/52 AVR-USB-JTAG] von [http://www.gadgetPool.de gadgetPool] (kommerziell)
* [http://www.floppyspongeonline.com/automation/isojtagisp/isojtagisp.php IsoJtagISP] und [http://www.floppyspongeonline.com/automation/isojtag/isojtag.php IsoJTAG] von Floppy Sponge Automation ([[USB]], optisch isoliert)
* [http://www.ere.co.th/(gs5afz55q5idyyn0a1ibkl45)/default.aspx?RedirectPage=Products&RedirectPage1=ProductsDetail&ProductID=56 JTAGAVRU1] (AVR JTAGICE kompatibel, USB, 1.8-5.5V)
* [http://www.avrfreaks.net/index.php?module=Freaks%20Tools&func=viewItem&item_id=630 JTAGcable II] (AVR JTAGICE kompatibel, USB, 1.8-6 V)
* [http://www.miklobit.com/JTAG_TWICE.530+B6Jkw9Mw__.0.html MB-JTAG-TWICE] (AVR JTAGICE kompatibel, RS232, 2.7-5.5V, +ISP STK500v2) - Free update to version compatible with AVR JTAG MKII (coming soon)

== ARM JTAG ==

=== USB Anschluss auf Basis des FTDI FT2232 ===
* [http://www.fh-augsburg.de/~hhoegl/proj/usbjtag/usbjtag.html USB to JTAG Interface] von Hubert Högl, Schaltplan
* [http://www.embedded-projects.net/index.php?page_id=175 USB JTAG Interface für usbprog und OpenOCD] von Benedikt Sauter (Zurzeit gibt es Bausätze für 22 EUR. Der Adapter ist ein Universaladapter der mit verschiedenen Firmwares zu verschiedenen Geräte werden kann. Pläne, Quelltexte usw... Open Source!!!)
* [http://www.amontec.com/index.shtml Amontec] JTAGkey, JTAGkey-Tiny
* [http://www.luminarymicro.com/products/ekk-lm3s811_evaluation_kit.html EKK-LM3S811] von LMI. Auf dem Testboard ist ein "on-board" JTAG-Adapter, der zu Ansteuerung des LM3S811 auf dem Board genutzt wird, aber auch an externe Controller angeschlossen werden kann. (Alle LMI Testboards verfügen über den JTAG Ein- und Ausgang.)
* [http://www.olimex.com/dev/arm-usb-ocd.html ARM-USB-OCD] von Olimex
* [http://www.signalyzer.com/ Signalyzer Tool]

=== Parallelport-Anschluss (Wiggler und Wiggler-"kompatibel") ===
* [http://www.macraigor.com/hwproducts.htm Macraigor] Original Wiggler
* [http://www.olimex.com/dev/arm-jtag.html Olimex ARM-JTAG] Wiggler-Nachbau
* [http://www.k9spud.com/jtag/ k9spud Wiggler-Schaltplan]
* [http://bbs.circuitcellar.com/phpBB2/viewtopic.php?p=10059& bigakis Wiggler-Schaltplan] (74HC244 Levelshifter, BC547 Transistor zum Invertieren)
* [http://wiki.openwrt.org/OpenWrtDocs/Customizing/Hardware/JTAG_Cable Wiggler Schaltplan] von OpenWRT (ebenfalls mit 74HC244).
* [http://www.st.com/stonline/products/literature/um/12322.pdf ST FlashLink JTAG Programming Cable] STM Application-Note

Man findet einige Schaltpläne für Wiggler-Nachbauten im Netz. Nicht alle sind identisch. Der original Schaltplan von Macraigor ist meines (M. Thomas) Wissens nicht verfügbar.

"Vollständige" Belegung des Wiggler-Clones von Olimex (Quelle: sparkfun-Forum)
* DB25.2 -> INVERSE -> JTAG.15 (NTRST) (mthomas: hier ist wohl nSRST gemeint)
* DB25.3 -> JTAG.7 (TMS)
* DB25.4 -> JTAG.9 (TCK)
* DB25.5 -> JTAG.5 (TDI)
* DB25.6 -> JTAG.3 (TRST)
* DB25.9 -> VCC for the Level shifter i.e. JTAG enable/disable
* DB25.11 <- JTAG.13 (TDO)
* DB25.13 <- Target VCC sense (only when JTAG is enabled i.e. DB26.9 = 1)

DB25.18, DB25.19, DB25.20, DB25.21, DB25.22, DB25.23, DB25.24, DB25.25 werden mit GND verbunden.

Soll das Wiggler-Interface auch mit der Software ocdremote von Macraigor genutzt werden, ist eine Brücke zwischen zwischen DB25.8 und DB25.15 einzubauen. ocdremote ab (ca.) Version 2.06 erkennt daran das original Wiggler und auch einen mit der Brücke ausgestattenen Nachbau. Nutzt man zur Ansteuerung andere Software (z.B. OpenOCD oder H-JTAG) wird diese Verbindung nicht benötigt.

Man beachte die Beschaltung von SRST und TRST:

Üblicherweise wird Pin DB25.2 des Druckeranschlusses über eine Inverterschaltung (NPN Transistor) mit dem Reset-Pin des ARM-Controllers verbunden ('''nSRST''').

Pin DB25.6 des Druckeranschlusses wird über Levelshifter direkt mit dem '''TRST'''-Pin des Controllers verbunden. In manchen Schaltplänen findet man auch für TRST einen Inverter, aber dies scheint eher unüblich.

Bei den sonstigen Pinbelegungen herrscht weitestgehend Einigkeit. Man muss lediglich Levelshifter ([[Pegelwandler]]) zwischenschalten, um zwischen den 5V des Druckeranschlusses und der Spannung des Controllers (üblicherweise 3,3V) zu "übersetzen".

Allein ein 74HC244 als Levelshifter, wie in vielen Schaltungen verwendet, ist nicht ideal. Der Baustein wird dabei mit 3,3V aus der Zielschaltung betrieben und die Anpassung an die nominell 5V vom Druckerport an die 3,3V des HC244 erfolgt entweder durch Spannungsteiler oder durch Strombegrenzungswiderstände und die internen Überspannungsschutzdioden. Das Ausgangssignal TDO zurück zum Druckeranschluss ist maximal 3,3V. Beides nicht optimal aber es funktioniert zumindest meistens. Aufwändigere Schaltungen, wie z.B. der Olimex Wiggler-Nachbau ("ARM-JTAG"), nutzen eine Kombination aus einem 74AC244 und einem 74LCX244.

=== sonstige ===

* Abatron BDI2000
* [http://www.amontec.com/index.shtml Amontec] JTAG Accelerator, Chameleon POD
* AZ-Electronics
* JtagConnection
* [http://www.lauterbach.de/mindex.html Lauterbach] Trace
* Macraigor Systems LLS
* Peedi
* Rowley Associates CrossConnect

=== Anschlussbelegung ===

Auf Evaluation-Boards verschiedener Hersteller (z.B. Atmel, IAR, Keil, Olimex) ist die JTAG-Schnittstelle über einen 20-poligen Wannenstecker (2*10, Raster 2,54mm) herausgeführt.

{| border="1"
|-
| 1 Vcc
| 2 NC
|-
| 3 nTRST
| 4 GND
|-
| 5 TDI
| 6 GND
|-
| 7 TMS
| 8 GND
|-
| 9 TCK
| 10 GND
|-
| 11 GND
| 12 GND
|-
| 13 TDO
| 14 GND
|-
| 15 NRESET/nSRST
| 16 GND
|-
| 17 NC
| 18 GND
|-
| 19 NC
| 20 GND
|-
|}

Daneben existiert noch eine weniger gebräuchliche aber dokumentierte Variante mit 14 Polen (2*7). Bei fertigen Geräten, für die keine Schaltpläne vorliegen, muss man sich die herstellerspezifische Anschlussbelegung anhand des Datenblatts des verwendeten Controllers und mittels Messgerät selbst ermitteln.

== MSP430 JTAG ==

MSP430-JTAG für Parallelport:
* [http://elmicro.com/files/olimex/msp430-jtag-d.pdf Olimex MSP430 JTAG (PDF)] bzw. ([http://www.olimex.com/dev/images/msp430-jtag-d-sch.gif (GIF)]). Siehe auch Diskussion im [http://www.mikrocontroller.net/topic/57208#442620 Forum].
* [http://www.mikrocontroller.net/topic/90754#776070 Forumsbeitrag] mit Anhang eines chinesischen? Schaltplans (PDF)

== FPGA JTAG ==

* [http://www.freewebs.com/lykos1986/cpldprogrammer.htm Xilinx JTAG programmer] ([[CPLD]], [[FPGA]])
* [http://www.embedded-projects.net/index.php?page_id=157 Xilinx JTAG XSVF Player mit USBprog] ([[CPLD]], [[FPGA]])
* [http://www.altera.com/literature/ug/ug_bbii.pdf ALTERA ByteBlaster]
* [http://www.pyroelectro.com/tutorials/byteblaster/index.html Build A ByteBlaster] bei www.pyroelectro.com
* [http://www.ixo.de/info/usb_jtag/ USB-JTAG-Adapter], kompatibel zu ALTERA USB-Blaster
* ColdFire BDM Pod
* [http://warmcat.com/milksop/cheaptag.html Cheaptag] - Xilinx Parallel Jtag programming cable
* FCPU-X Platform Cable USB JTAG cable
** Bezugsquelle (DE): [http://www.vht-impex-shop.de/product_info.php?info=p786_HW-USB-platform-cable--FCPU-X-platform-cable-similar-to-HW-USB-Kabel-for-Xilinx-evaluation-boards-etc-.html&XTCsid=e613a7119493deac52e83e9038ce131a http://www.vht-impex-shop.de]
** Bezugsquelle (US): [http://www.celeritous.com/estore/index.php?main_page=product_info&cPath=1&products_id=129 http://www.celeritous.com]

= Software =

== AVR JTAG ==

* [[AVR-Studio]] (Windows)
* [[GDB]] in Verbindung mit [http://avarice.sourceforge.net/ AVaRICE] und AVR JTAGICE kompatibler Hardware. (Linux)

== ARM JTAG ==

* [[GDB]] bzw. Insight und auf die ARM JTAG Hardware abgestimmte GDB-Server (OCDRemote, [http://openocd.berlios.de/ OpenOCD], BDI2000, Peedi)
* [http://twentyone.bokee.com/ H-JTAG] und RDI-kompatible Debugger (SDT2.51, ADS1.2, RealView and IAR)
* Herstellerspezifische Software z.B. von Lauterbach

== FPGA JTAG ==

* Altera: Quartus Programmer (quartus_pgm)
* Lattice: ToDo...
* Xilinx: Impact, xc3sprog, ...

== Allgemeine Tools ==

* http://www.scanseer.com Boundary-scan pin probe tool
* http://www.ricreations.com/index.html TOP!
* http://www.rsn-tech.demon.co.uk/pjtag/pjtag.html Is bissel buggy, aber kleine Sachen gehen damit.
* http://urjtag.org Kommandozeilentool für Boundary Scan, FPGA und CPLD und Speicher lesen und schreiben u.v.a.m. (Nachfolger von openwince JTAG Tools)

[[Kategorie:AVR]]
[[Kategorie:ARM]]
[[Kategorie:FPGA und Co]]

Verilog

2008-09-09T11:03:33Z

Guenter: /* Icarus Verilog */ Tippfehler behoben

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um eine Kommandozeilen-basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der kompilierte Quellcode wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile auszuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt, das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instantiiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd'''-Dumpfile und einem '''foo.sav'''-File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd'''-Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefiles sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav-File zu kreieren, in dem abgespeichert wird, welche Signale in der Anzeige gerade angezeigt werden. Startet man gtkwave mit diesem .sav-File bzw. lädt es später nach, wird die Anzeige wieder so dargestellt wie zu dem Zeitpunkt wenn das .sav-File erstellt wurde. Wird gtkwave nur mit einem .vcd-File gestartet, ist die Anzeige immer leer und die Signale müssen erst in die Anzeige gebracht werden. Wenn eine .sav-Datei vorhanden ist, dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-09-09T10:53:24Z

Guenter: /* Parallele Prozesse mit join/fork */ Neuer Abschnitt über task und function

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Funktionsaufrufe mit function und task ==

Analog zu Funktionen und Prozeduren in der Software-Programmierung stellt Verilog ''function'' und ''task'' zur Verfügung um komplexere Systeme in kleiner Einheiten aufzuteilen. Zu beachten ist das Verilog schon den ''module''-Konstrukt für die Aufteilung hat. Aufrufe von ''function'' und ''task'' können im Rahmen von ''initial''-, bzw. ''always''-Blöcken in ''module''-Blöcken eingesetzt werden.

Es gibt zwei wesentliche Unterschiede bei der Verwendung von ''function'' und ''task'' im Zusammenhang mit der Simulation:

''function''
* der Aufruf liefert einen Rückgabewert
* es können keine Zeit- oder Ereignissteuerungen (#, @ und wait) eingesetzt werden

''task''
* der Aufruf liefert keinen Rückgabewert
* es können Zeit- oder Ereignissteuerungen eingesetzt werden

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-09-09T10:31:36Z

Guenter: /* Hierarchie */ Tippfehler behoben

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instantiierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instantiieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instantiierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instantiierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instantiierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instantiiert werden kann die Parameterliste verändert und damit das instantiierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instantiiert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-09-05T12:46:38Z

Guenter: /* Zeit in der Simulation */ Formulierungsfehler behoben

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumpfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulation von großen Designs ist es sinnvoll die Anzahl der Signale die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden alle Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signale in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator arbeitet mit Simulationsschritte, die erst mal dimensionslos sind. Um dem Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer angegeben und können die Werte 1, 10, oder 100 haben.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung von ''`timescale'' verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren, erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Die Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt. D.h., nach einer Verzögerung von 10 sind auch 10 Simulationsschritte ausgeführt worden.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir den Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ns bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an, mit welcher Genauigkeit die Verzögerungsoperation erfolgt. Bisher haben wir ganzzahlige Werte verwendet. Für die Verzögerungsoperation können aber auch reale Zahlen verwendet werden. Die Simulationszeit wird errechnet, indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann, basierend auf der spezifizierten Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

FPGA

2008-08-20T12:40:57Z

Guenter: /* Boards für Xilinx-FPGAs */ Preis vom FPGAz USBP geändert

FPGA ist die Abkürzung für "'''F'''ield '''P'''rogrammable '''G'''ate '''A'''rray".

== Aufbau ==

=== Grundelemente ===
Ein FPGA besteht, ähnlich wie ein [[CPLD]], aus vielen Logikelementen, hauptsächlich Flip-Flops (FF) und LUTs (LUT = Lookup-Table), die über elektronische "Schalter" entsprechend der vom Entwickler gewünschten Funktion miteinander verknüpft werden können.

Eine '''LUT''' kann eine beliebige kombinatorische Funktion (NAND, XOR, AND, Multiplexer etc.) aus den Eingangssignalen realisieren. Die Anzahl der Eingangssignale pro LUT ist vom FPGA abhängig und liegt meist zwischen 4 und 6. Für Funktionen, die mehr Eingänge erfordern, als eine einzige LUT besitzt (hohes Fan-In), werden mehrere LUTs direkt miteinander verschaltet. Die '''Flip-Flops''' dienen dazu, Signalwerte zwischenzuspeichern, um sie im nächsten Takt weiterverarbeiten zu können. Das Verhältnis zwischen der Anzahl der LUTs und der Anzahl der Flip-Flops ist meist 1:1. Aktuelle FPGAs bestehen aus bis zu einigen zehntausend Logikelementen.

Die logischen Schalter und Speicher sind in den meisten FPGAs durch SRAM-Speicherzellen realisiert, welche beim Bootprozess passend geladen werden. Das Laden dieser Konfigurationsdaten bzw. Verknüpfungsregeln geschieht dabei in der Regel aus einem speziellen Flash-ROM-Baustein heraus. Es kann aber auch ein Mikrocontroller benutzt werden. Die meisten (SRAM-basierten) FPGAs bieten daher für diesen Konfigurationsvorgang mehrere Modi (seriell, parallel, Master/Slave) an. Da die SRAM-Zellen ihren Inhalt beim Abschalten der Versorgungsspannung verlieren, muss ein SRAM-basierter FPGA bei jedem Einschalten neukonfiguriert werden. Daher benötigt ein solcher FPGA einige Millisekunden bis zur Betriebsbereitschaft.

Eine FPGA-Familie beinhaltet Typen mit unterschiedlicher Anzahl und Komplexität von Logikzellen. So enthält ein Spartan3-1000 ca. 2,5 mal mehr Logik (FF, LUTs) als ein Spartan3-400.

FPGAs mit nichtflüchtigem Speicher basieren auf EEPROM-, Flash- (einige Familien von Lattice) oder AntiFuse- (Actel) Technologie. Die sogenannten AntiFuse FPGAs sind einmalig programmierbar.

=== I/O Anschlüsse ===
FPGAs als universal einsetzbare Digital-ICs unterstützen eine Vielzahl von Signalstandards. Üblich sind verschiedene TTL-Pegel (5V, 3,3V, 2,5V), differentielle Signalstandards (LVDS, GTL) und im Hochpreisbereich serielle Standards bis zu 1 Gbps. Oftmals sind weitere Eigenschaften wie Treiberstärke und Flankensteilheit für jeden benutzerdefinierbaren Anschluss (User-IO) einstellbar. Meist sind die Pins in Bänke mit gleichem I/O Standard zusammengefasst. Innerhalb einer solchen Bank arbeiten alle Pins im gleichen I/O Standard und mit der selben I/O Spannung (H-Pegel).

Ebenso können FPGA-interne Pull-Up und Pull-Down-Widerstände zugeschaltet werden, Terminierung wird ebenfalls unterstützt.

Das I/O Verhalten wird mit den IO-Constraints in einem setting-File (Xilinx *.ucf, Altera *.acf) festgelegt.

Einige Pins übernehmen zeitweilig oder allgemein besondere, nicht vom Anwender abschaltbare Funktionen. Darunter zählen die Pins zum Einlesen der Konfigurationsdaten. Oft sind einige wenige Pins (2 - 8) zum Einspeisen des Taktes für das Design reserviert.

Die Hersteller bieten FPGAs mit gleicher Anzahl von Logikelementen in unterschiedlichen Gehäusen an. So kann der FPGA mit der passenden Anzahl von Pins eingesetzt werden. Das obere Ende markieren Chips mit über 1000 I/Os, die kleinsten bieten ca. 80(?) User-I/O. Oft werden nur BGA und QFP Gehäuse (bis ca. 240(?) Pins) angeboten.

=== Komplexere Blöcke (Multiplizierer, RAM, PLL/DLL) ===
Neben den einfachen Flip-Flops beinhalten FPGAs darüber hinaus komplexe Routing- und Speicherkonfigurationsoptionen innerhalb und außerhalb der logischen Elemente (LEs), die es gestatten, komplexe Schalt- und Rechenstrukturen aufzubauen. Für rechenintensive Designs, z.B. in der Signalverarbeitung, enthalten viele FPGAs Multiplizierer direkt auf dem Chip, die in einem einzigen Taktzyklus Multiplikationen durchführen können.

Ferner haben FPGAs oft einen von den LEs getrennt verfügbaren RAM-Bereich integriert, der sich in vielfältiger Weise ansprechen lässt. So können damit Single- oder Dualport-RAMs mit variabler Bitbreite erzeugt werden. Üblich sind mehrere (4 - 30) kleinere Dualport RAM-Blöcke von 4 - 16 kbit. Einige Familien besitzen einen größeren internen RAM, andere spezielle FIFO-Blöcke.

Zur Generierung spezieller Takte sind PLL-Komponenten (phase locked loop) auf dem FPGA integriert. Einige Hersteller setzen mit dem selben Ziel DLL-Blöcke (delay locked loop) ein. Mittels dieser Blöcke können aus einem Taktsignal weitere erzeugt werden. Typisch sind Taktverdopplung oder -vervielfachung. Ebenso kann der Takt geteilt werden oder ein Signal gleicher Frequenz, aber um eine halbe, viertel usw. Periode verschoben erzeugt werden. Typische Anwendungen sind die Ansteuerung von DDR-RAMs oder die Kompensation von Laufzeitunterschieden zwischen Takt und mit diesem getakteten Steuersignalen. Meist sind 2 - 8 Taktnetzwerke und PLL/DLLs gleicher Anzahl integriert. Siehe auch [[Taktung FPGA/CPLD]].

=== CPU im FPGA ===

Programmierbare Prozessoren sind auch häufig bei FPGA Designs unverzichtbar. Diese sind zwar im Allgemeinen langsamer und weniger effizient als eine vollständige Implementation aus Logik-Primitiven -- aber auch deutlich
einfacher zu beherrschen. Insbesondere bei sequentiellen Aufgaben (Benutzerinterface, komplexe Steueraufgaben etc.) wird man gerne auf eine
klassische CPU zurückgreifen.

Manche FPGAs integrieren einem oder mehrere Prozessorkerne (z.B. [[AVR]] bei Atmels FPSLIC, PowerPC bei Xilinx' Virtex-4 oder ARM-Cortex-M1 bei IGLOO-FPGA von [http://www.actel.com actel]) als ''HardCores'' auf einem IC.

Auf der anderen Seite gibt es auch ''SoftCores'', Prozessorkerne die als Quelltext oder als vor-synthetisierte Netzliste vorliegen. In Abhänigkeit von den zur Verfügung stehenden Resourcen können diese ''SoftCores'' beliebig instantiiert werden. Es gibt eine Vielzahl verschiedener ''SoftCores'' --
Teilweise kompatibel zu etablierten Prozessorarchitekturen (MIPS, SPARC, AVR), zum Teil optimiert auf die FPGAs einzelner Hersteller. Auch auf vergleichsweise
kleine aktuelle FPGAs kann man problemlos eine 32bit-RISC-CPU integrieren.
Unter [[FPGA Soft Core]] findet man eine Liste einiger weit verbreiteter ''SoftCores''

Als Programmspeicher werden die FPGA-internen RAM-Blöcke oder externe Speicher-ICs (SDRAM, SRAM) genutzt. Für einige Prozessorkerne stehen Hochsprachen wie C, C++ etc. zur Verfügung, andere werden in Assembler programmiert.

== Eigenschaften ==
=== Geschwindigkeit ===
Die maximale „Geschwindigkeit“ eines FPGAs ist von der verwendeten Halbleitertechnologie (Prozess, Strukturgrößen), der internen Schaltungstopologie (Komplexität der LEs), Vorhandensein von harten Strukturen und vor allem vom Design abhängig. Dabei sind der sogenannte Datendurchsatz und die rein maximale Systemtaktfrequenz zu unterscheiden. Die erreichbare Taktfrequenz lässt sich ohne detaillierte Kenntnis des Designs nicht abschätzen, möglich sind je nach »Speed Grade« des ICs typischerweise Taktfrequenzen von 300-500 MHz für die Schaltgeschwindigkeit der reinen Logikelemente. Je nach der Anzahl und Komplexität der pro Takt durchzuführenden Operationen ergeben sich reale reale Systemtaktfrequenzen von meist 10-200 MHz. Maßgeblich ist, in wieweit das Design auf Fläche bzw. Geschwindigkeit hin optimiert und vom Tool synthetisiert wurde: Durch das Einbringen von zusätzlichen Registerstufen lassen sich z.B. zeitkritische Pfade entschärfen, sodass die Frequenz des Chips angehoben werden kann und der effektive Datendurchsatz trotz teilweise mehr CLKs zwischen Ein- und Ausgängen (Latenz) erhöht wird. Dieser lässt sich darüber hinaus durch die Nutzung paralleler Architekturen verbessern.

Die Systemfrequenz kann-, muss aber nicht der Frequenz entsprechen, mit der Daten zyklisch eingetaktet und verarbeitet werden; zudem sind Schaltungsteile mit unterschiedlichen Taktfrequenzen zu unterscheiden: Mit einem Systemtakt1 von 20 MHz lassen sich z.B. 18-Bit AD-Wandler auslesen, die so z.B. alle 1 µs neue Daten liefern, die verarbeitet werden müssen. Bei der Nutzung von 5 solchen Wandlern, die sequentiell verarbeitet werden, lägen 5 MHz Datenfrequenz vor. Für andere Schaltungsteile, die z.B. asynchron an die Peripherie andocken, sowie reine »state machines« können Schaltungsteile auf der 2-4 fachen Frequenz betrieben werden.

Generell sind Fläche und Geschwindigkeit konkurrierende Größen, zwischen denen ein Optimum gefunden werden muss. Für die preiswerten FPGA-Serien wie Spartan (Xilinx) und Cyclone (Altera) sind aufgrund technologischer Randbedingungen etwa 10-30% weniger Taktgeschwindigkeit bei gleichem Design zu erwarten, bzw. muss mit mehr Verbrauch an Logikelementen und Taktzyklen gerechnet werden (weniger Routingreserven, geringere Zahl von LUT-Eingängen, weniger hard-ressourcen).

Identische Chips werden oft in 2 oder mehr Geschwindigkeitsklassen angeboten, die sich meist durch Bauteilselektion bei der Produktion ergeben. Grob kann man ca. 5%-10% höhere Taktung zwischen zwei Speedgrades erwarten.

== Hersteller ==
Die größten Hersteller von FPGAs sind Altera und Xilinx. Weitere Hersteller sind Lattice, Actel und Atmel.

* [http://www.altera.com Altera]
* [http://www.xilinx.com Xilinx]
* [http://www.lattice.com Lattice]
* [http://www.actel.com Actel]

== Anwendung ==

Der Aufbau komplizierter, applikationsnaher Strukturen wird meist durch automatische Routing- und Synthesewerkzeuge erledigt, welche mit einer logischen, funktionellen Beschreibung der Architektur in einer Hardwarebeschreibungssprache wie z.B. VHDL "gefüttert" werden. Die Hardwarebeschreibung in VHDL gelingt ihrerseits z.B. mit VHDL-generierenden Werkzeugen, mittels derer zuvor Logikstrukturen, hardwarenahe Strukturen, Ablaufdiagramme und Zustandsautomaten formuliert wurden.

Durch die Standardisierung der Architektur einerseits und die Entkoppplung von applikationsorientierter Beschreibung sowie Chip- und Hersteller-spezifischer Synthese andererseits, wird die Hardware quasi als Software gebaut. Dies wiederum schafft alle Optionen der Wiederverwendung und Austausch von "Hardwareteilen". So stehen inzwischen komplett nutzbare Schaltungen wie serielle Bausteine, RAM-Controller und vieles mehr als Open Source zur Verfügung.

== Entwicklungsboards und Starterkits ==
=== Boards für Xilinx-FPGAs ===

{| border="1" class="sortable" id="fpgaevalboards"
|-
! Bezeichn.
! Preis (€)
! FPGA
! RAM (MByte)
! Flash (MByte)
! USB
! Ethernet
! RS-232
! µC
! Eingabe
! sonst.
|-
| [http://www.knjn.com/board_Xylo.html Xylo-L]
| 130
| XC3S500E
| -
| -
| 2.0
| 10base-T
| -
| LPC213x
| -
|
|-
| [http://www.xilinx.com/s3estarter Spartan3e Starter Kit]
| 180
| XC3S500E
| 64 MB DDR-SDRAM
| 16
| (JTAG)
| 10/100
| 2x
| -
| 4 Taster, 1 Drehgeber, 4 Schalter
| Coolrunner CPLD, LCD, 3-Bit VGA, PS/2
|-
| [http://www.digilentinc.com/Products/Detail.cfm?Nav1=Products&Nav2=Programmable&Prod=S3BOARD Digilent Spartan-3]
| 100
| XC3S200/400/1000
| 1
| -
| -
| -
| 1x
| -
| 4 Taster, 8 Schalter
| VGA, PS/2, 7seg
|-
| [[Digilent Nexys]]
| 100
| XC3S200/400/1000
| 16
| 4
| 2.0
| -
| -
| -
| 4 Taster, 8 Schalter
| 7seg, Programmierung & Stromversorgung über USB
|-
| [http://www.uxibo.de Uxibo]
| 88
| XC2S200E
| -
| -
| 1.1
| -
| -
| -
| 4 Taster, 8 Schalter
| VGA I/O, Videomux, dual PS/2, 7seg, Buzzer, IOs auf Pinleisten, dual-channel FTDI2232C, 48 MHz + prog. Oszillator, Programmierung & Stromversorgung über USB
|-
| [http://www.fpgaz.com/wiki/doku.php?id=fpgaz:usbp:hw FPGAz USBP]
| $135
| XC3S400
| -
| -
| 2.0
| -
| -
| Cypress FX2
| 2 Taster
| 8 LEDs, I2C-EEPROM
|-
| [http://www.cesys.com/fpga/spartan/efm01_de.html EFM 01] Embedded FPGA Modul
| 145,-
| XC3S500E
| -
| 4
| 2.0
| -
| -
| FX-2
| -
| 28 x 44mm, 50 I/O auf 2.54mm Stiftleiste, WIN und LINUX Treiber
|}

==== Raggedstone 1 - Spartan-3 Development PCI-Karte ====
* Spartan-3 FPGA FG456-Package
* 32 bit, 33 MHz, 3.3/5V PCI interface
* 4Mbit Flash Memory
* 16KBit serielles EEprom
* 4 x 7 Segment Anzeigen LED, abnehmbar
* LM75 Temperatursensor
* viele DIL-Header für eigene Erweiterungen, verschiedene werden auch durch Hersteller angeboten
* 2 Drucktaster
* Mit dem PCI-Interface kann bei entsprechender Programmierung des FPGA auf den PCI-Bus eines Hostrechners zugegriffen werden, Beispieldesign unter http://projects.varxec.net/raggedstone1
* Webseite: http://www.enterpoint.co.uk/moelbryn/raggedstone1.html
* Preis mit XC3S400 ca. €145,- (inkl MWST)
* Preis mit XC3S1500 ca. €255,- (inkl. MWST)

==== LiveDesign Evaluation Board von Altium ====
* Kompatibel mit den LiveDesign-fähigen Entwicklungstools von Altium
* Xilinx-Version direkt mit ISE Webpack nutzbar
* Xilinx XC3S1000-4FG456C, wahlweise aber auch mit Altera EP1C12F324C8 (s.u.)
* Mit Flachbandkabel für PC-Verbindung (Druckerport) sowie weiteren Kabeln und Verbindern
* Peripherie: LEDs, Dip-Schalter, 6-stellige Siebensegmentanzeige, Taster, Stereo-DAC, zwei 256K x 16 RAMs
* ''kein'' on-board Flash RAM für FPGA-Konfiguration, diese muss nach dem Einschalten neu geladen werden
* Ports: PS2-Maus & -Tastatur, RS232, VGA (512 Farben), 2x18 IO-Pins für allgemeine Zwecke
* Listenpreis $99,- Endpreis: ~150 Euro (inkl. MwSt. und Versand)

==== BurchED ====
http://www.burched.com/index.html
australischer Anbieter von Xilinx-Evaluationsboards
zur Zeit Webseite im Umbau

==== Trenz-Electronic ====
http://www.trenz-electronic.de/products.html
* Kleines FPGA Board mit ucLinux und Virtex-II PowerPC, optional: ucLinux und Microblaze Softprozessor im Spartan-3 FPGA
* Spartan-3 FPGA Mikromodul mit 200K bis 1000K Systemgattern
* Pal/Gal kompatible FPGA und CPLD Module

==== Simple-Solutions ====
http://www.simple-solutions.de/de/products/index.php
Mehrere Spartan3-FPGAs - Boards

==== CESYS ====
http://www.cesys.com

Cesys ist Entwickler und Hersteller von FPGA-boards mit Sitz in Deutschland.

* Verschiedene FPGA boards mit USB, PCI und PCIe Schnittstellen im Lieferprogramm
* Je nach Ausführung mit Spartan-2/3/3E, Virtex2/2PRO/4
* verschiedene Speicherkonfigurationen (SO-DIMM, SRAM, SDRAM, DDR2)

=== Boards für Altera-FPGAs ===
==== LiveDesign Evaluation Board von Altium ====
* Kompatibel mit den LiveDesign-fähigen Entwicklungstools von Altium
* * Wahlweise mit Altera EP1C12F324C8 oder Xilinx XC3S1000-4FG456C
* Mit Flachbandkabel für PC-Verbindung (Druckerport) sowie weiteren Kabeln und Verbindern
* Peripherie: LEDs, Dip-Schalter, 6-stellige Siebensegmentanzeige, Taster, Stereo-DAC, zwei 256K x 16 RAMs
* ''kein'' on-board Flash RAM für FPGA-Konfiguration, diese muss nach dem Einschalten neu geladen werden
* Ports: PS2-Maus & -Tastatur, RS232, VGA (512 Farben), 2x18 IO-Pins für allgemeine Zwecke
* Endpreis: ~150 Euro (inkl. MwSt. und Versand)

==== Terasic TREX C1 Multimedia Development Kit ====
* Altera EP1C6Q240C8 & EP1S Serial Configuration Device
* Built-in USB Blaster programming circuitry (JTAG and AS mode)
* 1 MiB Flash Memory & 8 MiB SDRAM (1M x 4 x 16)
* CF Card Socket, 16-bit CD-quality Audio DAC
* TV Encoder, VGA, RS-232, PS/2, and more
* Many reference designs and C++ applications
* [http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=39&No=14 www.terasic.com.tw]
* fertiger Core eines CPC6128 (8-Bit Homecomputer von 1984) für dieses Board, inlusive Sourcecode (eigener Z80 in AHDL, mit 24MHz eingesetzt): [http://www.symbos.de/trex.htm http://www.symbos.de/trex.htm]
* Listenpreis $149,-

==== Altera Cyclone II 2C20 ====
* Altera Cyclone II EP2C20F484C7N FPGA mit 20000 LEs
* USB-BlasterTM download cable (integriert)
* EPCS4 serial configuration Flash
* 8-Mbyte SDRAM, 512-Kb SRAM, 4-Mbyte flash
* externer SMA - Clock-Eingang
* 24-bit Audio coder/decoder (CODEC)
* 10 Schalter, 4 Druckknöpfe inkl Reset
* 4St. 7-Segmentanzeigen, 10 rote LEDs + 8 grüne LEDs
* VGA, RS-232, and PS/2 Stecker
* Zwei 40-pin expansion ports + SD/MMC socket
* USB-Kabel, externes Steckernetztteil, CD-Rom
* Reference designs
* Qartus II Web Edition + NIOS II Web Edition
* http://www.altera.com/products/devkits/altera/kit-cyc2-2C20N.html
* Listenpreis $150,-

==== Hpe Mini AC II - Altera Cyclone board von Gleichmann Research ====
* Altera Cyclone II EP2C35 FPGA (speed grade 6)
* Mit reprogrammierbarem Flash zur automatischen FPGA-Konfiguration
* 25 pin SUB-D connector (parallel) für direktes FPGA-Programmieren
* RS232 (9 pin SUB-D)
* VGA (15 pin SUB-D) mit 64 möglichen Farben
* Ethernet 10/100 Mbit/s, full/half duplex
* 1 USB 2.0 compatible full-speed target connector
* 3 USB 2.0 compatible full-speed host connectors
* Santa Cruz connector mit 40 nutzbaren I/Os
* Audio interface (line-in and line-out) mit CODEC
* SODIMM144 Sockel für (SDRAM) 256MB
* SDRAM-Speichersockel mit nur 32-Bit angebunden, die Hälfte des Speichers bleibt nicht nutzbar
* 25 MHz oscillator
* Prototyping area, Lötfläche
* 8 LEDs, grün, blau, 3x4 key matrix, 4-bit DIP switch
* LCD connector, 2-character 7-segment display
* Single step Knopf und Reset Knopf
* Parallelportkabel für PC
* Beispieldesign, Testprogramme, Datenblätter
* LEON3-CPU Design inkl. Source Code, Quartus IDE, SnapGear Linux
* Je nach Ausführung des Flashs €399,- bis €499,-

==== Altera DE2 - Development and Education Board ====
* Altera Cyclone II 2C35 FPGA mit 35000 LEs
* Altera Serial Configuration devices (EPCS16) für Cyclone II 2C35
* USB Blaster board zur Programmierung und User API
* 8 MB SDRAM, 4 MB Flash Memory, 512KB SRAM
* SD Card Sockel, RS-232, Ethernet, 10-bit VGA, 24-bit Audio CODEC
* TV Decoder (NTSC/PAL), IrDA, USB (Host + Slave)
* Viele Besipiel mit Source Code wie TV, SD Music Player)
* [http://wwwab.fh-wedel.de/bause/handouts/vhdl/VhdlEinfuehrung.pdf Kleines aber nettes Tutorial zum Altera DE2 Dev. Board]
* Listenpreis US $495,-

==== Cyclone III embedded Development Kit====
* Altera Cyclone III EP3C25 FPGA
* MiniSD-Card Sockel
* Audio Interface ADC CODEC
* 10/100 Mbit Fast Ethernet Schnittstelle
* FPGA-Konfiguration über USB
* NIOS II EVAL Lizenz
* IP LIB Altera
* Listenpreis US $495,- ueber ALtera Webseite

==== Cyclone II EP2C35 Entwicklungsboard ====
* Altera Cyclone II EP2C35-F672C8 FPGA mit 33.216 LEs
* Insgesamt 172 I/Os exklusiv verfügbar
* Bis zu 256 MByte SDRAM (SODIMM Speichermodul, 64-Bit Busanbindung)
* 16 MByte Flash (16-Bit Busanbindung)
* MiniSD-Card Sockel
* 10/100 Mbit Fast Ethernet Schnittstellenkontroller
* USB 2.0 high speed (480 Mbit) Schnittstellenkontroller
* FPGA-Konfiguration über USB
* Abmessungen: 96mm x 68mm
* Kompatibel mit der frei verfügbaren Altera Entwicklungssoftware
* http://www.fpga-dev.de/index.php?site=ep2c35_beschreibung
* wird in regelmässigen Abständen für 169,- Euro über ebay vertrieben (einfach nach "altera cyclone" suchen)

==== NanoBoard-NB1 von Altium ====
* kompatibel mit den LiveDesign-fähigen Entwicklungstools von Altium
* Unterstützt eine breite Palette von Ziel-FPGAs durch Aufsteckplatinen
* Altera Cyclone (EP1C12-Q240C7) Aufsteckplatine enthalten
* Xilinx Spartan IIE (XC2S300E-PQ208) im Lieferumfang enthalten
* Enthält Stromversorgung mit verschiedenen Steckern für unterschiedliche Konfigurationen
* Mit Flachbandkabel für PC-Verbindung sowie weiteren Kabeln und Verbindern
* NanoBoard-NB1 Reference-Handbuch zur Hardware
* Peripherie: LCD, LEDs, Dip-Schalter, Tastenblock, Summer, ADC/DAC, 256K x 8 RAM, 8 MiB Serial Flash RAM, on-board Serial Flash RAM für FPGA-Konfig.
* Ports: PS2-Maus & -Tastatur, RS232, CAN, VGA, I2C, IO Stecker für allg. Zwecke
* Upgradefähige NanoBoard Controller Firmware
* Stabiler NanoBard-Sockel
* Listenpreis €995,-
=== Debugging-Hilfen ===
==== Core zum Debugging von Bussen von abaxor engineering ====
Durch die zunehmende Komplexität von FPGA-Designs gewinnt das Debugging von Busse zwischen Filtern und anderen Signalverarbeitungselementen, in Echtzeit immer mehr an Bedeutung. Die etablierten Werkzeuge der FPGA-Hersteller (ChipScope, SignalTap) bieten nicht genügend Speichertiefe, da sie auf im FPGA verfügbare Ressourcen bauen. Weiterhin begrenzt die JTAG-Schnittstelle die Bandbreite. Oft besteht aber die Notwendigkeit, Daten mit hoher Bandbreite zum PC zu übertragen. Der Zugang zum PC sollte keine zusätzlichen Treiber oder gar besondere Hardware benötigen, sondern über die vorhandenen Standard-Schnittstellen (USB, IDE, ATA, Ethernet) erfolgen. Da es sich um eine Debug-Funktion handelt, muss der Logikaufwand im FPGA gering sein. An dieser Stelle bietet sich die gut bewährte IDE (genauer ATA/ATAPI) Schnittstelle an. Mit Hilfe einer USB-IDE Bridge (USB-ATA) eröffnet sich die Möglichkeit zum Hot-Pluging, es ist noch nicht einmal erforderlich den Rechner zu öffnen.

Der Core hat folgende Eigenschaften:
* Streaming der Daten zum PC mit mehr als 20 MByte/s
* keine Treiber im PC da Nutzung von Standardschnittstellen (USB oder IDE)
* Visualisierung mit beliebigen Programmen
* geringer Logikaufwand

[http://www.abaxor.de/produkte.html abaxor.de-Webseite]

==== open source Logikanalysator von sump.org====
Ein einfacher, übersichtlicher Logikanalysator findet sich auf sump.org. Er liegt im Quelltext vor wird mit ins Design einsynthetisiert. Als Speicher dient wahlweise SRAM oder intern RAM. Es können 32 Kanäle mit 100 MHz (oder weniger) gesampelt werden. Die Bediensoftware läuft platformunabhängig unter Java und benötigt eine serielle Schnittstelle (auch über USB-seriell Wandler) zum Core.

[http://de.sump.org/projects/analyzer/ sump.org-Webseite]

== Siehe auch ==
* [[Hardwarebeschreibungssprachen]]
* [[Reset für FPGA/CPLD]]
* [[Taktung FPGA/CPLD]]
* Projekt [[Audio-DSP mit Spartan 3-FPGA]]

== Weblinks ==
* [http://www.fpga4fun.com/index.html FPGA4Fun] - FPGA-Projekte, größtenteils mit Altera und Verilog
* [http://video.google.com/videoplay?docid=-4969729965240981475 Ein Vortrag, auf Englisch: General Purpose, Low Power Supercomputing Using Reconfiguration Logic]
* http://www.opencores.org - FPGA-Projekte, Opensource, jeder kann seine Eigen einstellen und an andere mitarbeiten. U.a. verschiede CPUs für FPGAs.
* http://members.optushome.com.au/jekent/FPGA.htm

[[Category:FPGA und Co]]

Verilog

2008-06-26T07:43:11Z

Guenter: /* Zeit in der Simulation */

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator hat die grundlegenden Simulationsschritte die erst mal Dimensionslos sind. Um den Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer-Wert angegeben und können die Werte 1, 10, oder 100 sein.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|'''Zeiteinheit'''
|'''Abkürzung'''
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Der Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir die Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ps bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an wie genau die Verzögerungsoperation genutzt werden. Bisher haben wir ganzzahlige Werte verwendet, für die Verzögerungsoperation können aber reale Zahlen verwendet werden. Die Simulationszeit wird errechnet indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann basierend auf der spezifizierte Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-26T07:42:46Z

Guenter: /* Zeit in der Simulation */ Zeiten in Tabelle

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator hat die grundlegenden Simulationsschritte die erst mal Dimensionslos sind. Um den Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer-Wert angegeben und können die Werte 1, 10, oder 100 sein.

Als Zeiteinheiten werden die folgenden Werte unterstütz:
{| border="1"
|-
|Zeiteinheit
|Abkürzung
|-
|Sekunden
|s
|-
|Millisekunden
|ms
|-
|Microsekunden
|us
|-
|Nanosekunden
|ns
|-
|Picosekunden
|ps
|-
|Femtosekunden
|fs
|}

Ein Beispiel soll die Nutzung verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Der Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir die Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ps bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an wie genau die Verzögerungsoperation genutzt werden. Bisher haben wir ganzzahlige Werte verwendet, für die Verzögerungsoperation können aber reale Zahlen verwendet werden. Die Simulationszeit wird errechnet indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann basierend auf der spezifizierte Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-26T07:40:34Z

Guenter: /* Zeit in der Simulation */ Doppeltes Icarus Kommando

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator hat die grundlegenden Simulationsschritte die erst mal Dimensionslos sind. Um den Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer-Wert angegeben und können die Werte 1, 10, oder 100 sein.

Als Zeiteinheiten werden die folgenden Werte unterstütz:

Zeiteinheit Abkürzung
Sekunden s
Millisekunden ms
Microsekunden us
Nanosekunden ns
Picosekunden ps
Femtosekunden fs

Ein Beispiel soll die Nutzung verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Der Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir die Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ns und entsprechend wartet die Simulation jetzt 100ps bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an wie genau die Verzögerungsoperation genutzt werden. Bisher haben wir ganzzahlige Werte verwendet, für die Verzögerungsoperation können aber reale Zahlen verwendet werden. Die Simulationszeit wird errechnet indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann basierend auf der spezifizierte Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-26T07:38:42Z

Guenter: /* Zeit in der Simulation */ ps->ns

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator hat die grundlegenden Simulationsschritte die erst mal Dimensionslos sind. Um den Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer-Wert angegeben und können die Werte 1, 10, oder 100 sein.

Als Zeiteinheiten werden die folgenden Werte unterstütz:

Zeiteinheit Abkürzung
Sekunden s
Millisekunden ms
Microsekunden us
Nanosekunden ns
Picosekunden ps
Femtosekunden fs

Ein Beispiel soll die Nutzung verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Der Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ns/1ns''' indem wir die Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvguenter@StCloud:~/tmp>iverilog -o time.vvp time.v
guenter@StCloud:~/tmp>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheitenp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ps und entsprechend wartet die Simulation jetzt 100ps bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an wie genau die Verzögerungsoperation genutzt werden. Bisher haben wir ganzzahlige Werte verwendet, für die Verzögerungsoperation können aber reale Zahlen verwendet werden. Die Simulationszeit wird errechnet indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann basierend auf der spezifizierte Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-26T07:37:27Z

Guenter: /* Zeit in der Simulation */ Neuer Abschnit mit join/fork

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator hat die grundlegenden Simulationsschritte die erst mal Dimensionslos sind. Um den Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer-Wert angegeben und können die Werte 1, 10, oder 100 sein.

Als Zeiteinheiten werden die folgenden Werte unterstütz:

Zeiteinheit Abkürzung
Sekunden s
Millisekunden ms
Microsekunden us
Nanosekunden ns
Picosekunden ps
Femtosekunden fs

Ein Beispiel soll die Nutzung verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Der Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ps/1ps''' indem wir die Code wie folgt ändern:

<verilog>
`timescale 10ns/1ns

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvguenter@StCloud:~/tmp>iverilog -o time.vvp time.v
guenter@StCloud:~/tmp>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheitenp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ps und entsprechend wartet die Simulation jetzt 100ps bevor die zweite ''$display''-Anweisung ausgeführt wird.

Die Präzision gibt nun an wie genau die Verzögerungsoperation genutzt werden. Bisher haben wir ganzzahlige Werte verwendet, für die Verzögerungsoperation können aber reale Zahlen verwendet werden. Die Simulationszeit wird errechnet indem der Wert des Verzögerungsoperators mit der Zeiteinheit multipliziert wird und dann basierend auf der spezifizierte Präzision gerundet wird.
{| border="1"
|-
| '''Zeiteinheit / Präzision '''
| '''Verzögerungswert'''
| '''Verzögerungszeit'''
|-
|10ns/1ns
|#3
|30ns
|-
|10ns/1ns
|#3.345
|33ns
|-
|10ns/100ps
|#3.345
|33.5ns
|}

== Parallele Prozesse mit join/fork ==

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-26T06:34:28Z

Guenter: /* Verilog für Simulation */ Neuer Abschnitt über Zeit in der Simulation

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

== Zeit in der Simulation ==

Wenn wir im Zusammenhang mit der Simulation von Zeit gesprochen haben, dann bisher nur von Zeiteinheiten. Der Simulator hat die grundlegenden Simulationsschritte die erst mal Dimensionslos sind. Um den Verzögerungsoperator eine Dimension zu geben stellt Verilog die ''`timescale'' Anweisung zur Verfügung.

<verilog>
''`timescale'' 10ns / 1ns
</verilog>

Die erste Zahl bestimmt die Einheit für den Verzögerungsoperator. Die zweite Zahl die Auflösung mit der die Simulation durchgeführt wird. Beide Zahlen werden als Integer-Wert angegeben und können die Werte 1, 10, oder 100 sein.

Als Zeiteinheiten werden die folgenden Werte unterstütz:

Zeiteinheit Abkürzung
Sekunden s
Millisekunden ms
Microsekunden us
Nanosekunden ns
Picosekunden ps
Femtosekunden fs

Ein Beispiel soll die Nutzung verdeutlichen.

<verilog>
module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

Wenn wir den obigen Quellcode in eine Datei time.v packen und dann mit Icarus Verilog simulieren erhalten wir folgenden Ausdruck:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvp
0 Start um 0
10 Nach 10 Zeiteinheiten
</c>

Der Verzögerungsoperation von 10 Zeiteinheiten wird direkt umgesetzt.

Wenn wir jetzt die Zeitskala verändern, z.B. nach '''`timescale 10ps/1ps''' indem wir die Code wie folgt ändern:

<verilog>
`timescale 10ps/1ps

module test;

initial begin

$display("%t Start um 0", $time);

#10 $display("%t Nach 10 Zeiteinheiten", $time);

$finish();

end

endmodule
</verilog>

So erhalten wir mit der Simulation folgende Ausgabe:

<c>
>iverilog -o time.vvp time.v
>vvp time.vvguenter@StCloud:~/tmp>iverilog -o time.vvp time.v
guenter@StCloud:~/tmp>vvp time.vvp
0 Start um 0
100 Nach 10 Zeiteinheitenp
0 Start um 0
100 Nach 10 Zeiteinheiten
</c>

Eine Zeiteinheit entspricht jetzt 10ps und entsprechend wartet die Simulation jetzt 100ps bevor die zweite ''$display''-Anweisung ausgeführt wird.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-18T19:06:32Z

Guenter: /* Verilog für Simulation */ Schreibfehler

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wie das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-18T11:20:13Z

Guenter: /* Verilog für Simulation/Verifikation */

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation =

Soweit haben wir die Sprache in Anlehnung an eine Programmiersprache beschrieben. Dabei sind schon einige Sonderheiten wie die Vierwertigkeit von ''wire'' und ''reg'' oder die Ereignissteuerung durch ''@'' im Zusammenhang mit der parallelen Abarbeitung von ''always'', bzw. ''initial'' Blöcken erschienen. Auch hatten wir die Verzögerungsoperation ''#'' klammheimlich eingeführt, ohne wirklich tiefer darauf einzugehen wir das ganze im Hintergrund funktioniert.

Der grundlegende Unterschied zwischen einer Programmiersprache und einer Hardwarbeschreibungssprache ist, das letztere ein Simulationsmodel zu Grunde liegt. In der Praxis sieht der Unterschied folgendermaßen aus. Bei einer compilierten Programmiersprache wird der Quellcode durch den Compiler in ein ausführbares Programm umgesetzt, das dann auf dem Computer ausgeführt werden kann. Bei der Hardwarebeschreibungssprache wird der Quellcode in eine für einen Simulator ausführbares Format umgewandelt. Nach dem Kompilieren kann dies dann mit dem Simulator ausgeführt werden.

In diesem Abschnitt werden jetzt Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-18T07:13:53Z

Guenter: /* Ereignissteuerung mit @ */ Kleine Umformulierung

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, bei dessen Betätigung eine LED eingeschaltet wird.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von ein oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-18T06:52:49Z

Guenter: /* Geschichte */ Link zur P1800 Arbeitsgruppe

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der [http://www.eda.org/sv-ieee1800/ IEEE P1800 Arbeitsgruppe] übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-05T14:33:04Z

Guenter: /* wire, reg; Datentypen */ Umformulierung, Erweiterung von Erklärungen

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprache (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der IEEE P1800 Arbeitsgruppe übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== Datentypen: '''wire, reg''' ==

Die grundlegenden Datentypen mit denen in Verilog modelliert wird, sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Wie ein Draht, kann aber ein ''wire'' keinen Signalzustand speichern. Für die Modellierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden und er findet damit als Signaltreiber Verwendung.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Die ''assign''-Anweisung kann als eine Art Verdrahtungsregel angesehen werden, mit der die Verbindung des ''wire'' beschrieben wird. Im obigen Beispiel werden die vier Drähte jeweils mit konstante Werte verdrahtet. Diese Konstanten sind die Signaltreiber für die Drähte.

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Blocks seine Werte zugewiesen bekommen. Mehr dazu in dem Abschnitt über ''initial'' und ''always'' Blöcke.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

== Schleifen mit for, while, und repeat ==

Für die wiederholte Ausführung von Codesegmenten, bei denen eine Zählervariable nötig ist, stellte Verilog die ''for''-Schleife zur Verfügung. Die einfache Anwendung erfolgt folgendermaßen

<verilog>

integer i;
reg [3:0] mem[0:63];

...

for(i=0; i<64; i=i+1)
mem[i] = 4'd0;

...
</verilog>

In dem Beispiel wird allen Speicherplätzen von '''mem''' der Wert 0 zugewiesen. Neu ist hier der Datentype ''integer'' der für die Zähler variable genutzt wird und laut Definition 32 Bit groß ist.

Für die wiederholte Ausführung von Codesegmenten bei denen keine Zählervariable nötig ist kann der ''repeat'' Konstrukt genutzt werden.

<verilog>

reg reset = 0;

...

repeat(2) begin

#10 reset = 1;
#10 reset = 0;

end

</verilog>

Hier wird zehn Zeiteinheiten gewartet und dann '''reset''' auf 1 gesetzt. Anschließend wieder 10 Zeiteinheiten gewartet und '''reset''' auf 0 gesetzt. Das ganze zwei mal wiederholt, so das ein doppelter '''reset''' Impuls entsteht.

Eine bedingte Schleife kann mit ''while'' ausgeführt werden.

<verilog>

integer i;

while(i < 10) begin
...
i = i + 1;
end

</verilog>

Der Schleifenkörper wird solange ausgeführt so lange die Bedingung WAHR ist.

== Parametrisierung durch Konstanten mit ''parameter'' ==

Bisher haben wir konstante Werte immer direkt in den Code eingeführt. Um Konstante Werte einheitlich über ein größeres Design zu verändern ist es sinnvoll für den Parameter einen einheitlichen Namen zu wählen und den Wert nur an einer Stelle im Design zu zu weisen.

<verilog>
parameter DW = 8;

...
reg [DW-1:0] data_bus;

</verilog>

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

Die Instanzierung kann jetzt noch durch die Überladung von ''parameter'' erweitert werden. Nehmen wir das vorherige Beispiel und schauen uns das ''module'' '''mux''' etwas näher an.

<verilog>

module mux #(parameter DW=8)
( input [DW-1:0] a,
input [DW-1:0] b,
input sel,
output [DW-1:0] y);

assign y = sel ? a : b;

endmodule
</verilog>

In der ''module'' Definition wird jetzt noch eine Parameterliste vor die Portdefinition eingefügt, die mit dem Lattenzaun ''#'' gekennzeichnet ist. Dadurch ist es möglich die Parameter in der Portliste zu nutzen.

Soll das Modul nun instanziert werden kann die Parameterliste verändert und damit das instanzierte Modul angepasst werden.

<verilog>
...

parameter NeueDW=16;

wire [DW-1:0] w1;
wire [DW-1:0] w2;

mux m1 #(.DW(NeueDW))( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 #(.DW(NeueDW))( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 #(.DW(NeueDW))( .a(w1), .b(w2), .sel(s3), .y(y) );

...
</verilog>

Die Parameterüberladung erfolgt wie bei der expliziten Portverknüpfung in der Form '''.ZielParameter(NeuerParameter)'''. Im obigen Beispiel werden nun also drei Multiplexer mit der neuen Datenbreite von 16 Bit instanziert.

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-04T07:18:30Z

Guenter: /* Mehrwegeentscheidung mit case, casex, casez */ Abschnitt erweitert mit default case

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der IEEE P1800 Arbeitsgruppe übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg; Datentypen ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase

</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

Manchmal ist die Entscheidungsliste größer und es müssen nicht immer alle Fälle behandelt werden. Dafür kann dann der ''default'' Konstrukt verwendet werden.

<verilog>

wire [1:0] sel;
reg dout;
wire d0, d1, d2, d3;

always@(*)
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
default: dout = d3;
endcase

</verilog>

Für alle nicht gelisteten Ereignisse wird jetzt die Zuweisung für den ''default'' Fall durchgeführt.

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-03T18:49:21Z

Guenter: /* Entwicklung der Hardwarebeschreibungssprache */ Umformulierungen

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der IEEE P1800 Arbeitsgruppe übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. So gibt es z.B. funktionale Programmiersprachen, wie C, bei denen teilt man mit Hilfe von Funktionsaufrufen große Problem in viele kleine Probleme. Bei objektorientierten Sprachen, wie z.B. C++, nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Modellierungsarten

* Modellierung des Verhaltens (engl. Behavioral modeling)
* Modellierung auf Register-Transfer-Ebene (engl. Register-Transfer-Level (RTL) modeling)

Bei der Modellierung des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der RTL-Modellierung wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Der Verilog Standard IEEE 1394 hat dazu einen Zusatz, in dem ein einheitlicher synthesierbarer Syntax spezifiziert wird. Für eine spezielle Synthesesoftware bietet natürlich auch das entsprechende Benutzerhandbuch Aufschluss. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg; Datentypen ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case, casex, casez ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
wire dout;
wire d0, d1, d2, d3;

...
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase
...
</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-03T17:10:02Z

Guenter: /* Geschichte */ Erweitert mit System Verilog

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

Mit erscheinen des letzten Standards hat die [http://www.verilog.com/IEEEVerilog.html IEEE P1364 Arbeitsgruppe] ihre Arbeit eingestellt und die Pflege des Standards der IEEE P1800 Arbeitsgruppe übergeben, die sich mit der Standardisierung von System Verilog befasst.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg; Datentypen ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case, casex, casez ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
wire dout;
wire d0, d1, d2, d3;

...
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase
...
</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-02T11:45:48Z

Guenter: /* Geschichte */ LaTeX Fußnote ersetzt

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 ("The Verilog Hardware
Description Language", Thomas & Moorby) als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg; Datentypen ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case, casex, casez ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
wire dout;
wire d0, d1, d2, d3;

...
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase
...
</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Diskussion:Verilog

2008-06-02T11:39:53Z

Guenter: Alte Diskussion gelöscht. Neue Diskussion über Style, Rechtschreibung und Übersetzung angefangen.

Das Dokument wächst langsam und es wird Zeit sich über einige Punkte Gedanken zu machen:

* '''Fachbegriffe''' - Die Sprache habe ich auf Englisch gelernt, daher musste ich für Fachbegriffe erst die Deutsche Übersetzung finden, ohne wirklich zu wissen ob es der Treffende Begriff ist. Wenn für irgendwelche Begriffe ein Diskussionsbedarf bezüglich der Übersetzung besteht, sollter er hier stattfinden.

* '''Schlüsselwörter''' der Sprache habe ich im Text recht konsequent immer Kursiv geschrieben. Namen die in Beispielen verwendet wurde habe ich nicht so konsequent in Fett geschrieben. Jetzt habe ich mir Gedanken darüber gemacht ob es nicht vielleicht sinnvoller ist es umgekehrt zu machen. Also die Namen Kursiv und die Schlüsselwörter Fett.

* '''Rechtschreibung''' - Bei der Rechtschreibung habe ich teilweise die Englische Form der Getrenntschreibung angewendet, was im Deutschen so nicht richtig ist. Auch die Verbindung von Schlüsselwörtern mit Text ist wahrscheinlich nicht richtig, wie z.B. ''wire'' Konstrukt.

--[[Benutzer:Guenter|Guenter]] 13:39, 2. Jun. 2008 (CEST)

----

Die alte Diskussion über Verilog habe ich gelöscht um hier Platz für Diskussion um den Artikel zu machen.

Die alte Diskussion kann immer noch über den Link zur alten Version erreicht werden:

http://www.mikrocontroller.net/wikisoftware/index.php?title=Diskussion:Verilog&oldid=28297

--[[Benutzer:Guenter|Guenter]] 13:39, 2. Jun. 2008 (CEST)

Verilog

2008-06-02T09:59:09Z

Guenter: /* Entscheidungsoperation mit if-else und ? : */ Neuer Abschnitt case, casex, casez

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 \footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg; Datentypen ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d0, d1, sel;

...
assign dout = sel ? d0 : d1;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d0''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d1''' zugewiesen.

== Mehrwegeentscheidung mit case, casex, casez ==

Die Erweiterung der Entscheidungsoperation ist die Mehrwegeentscheidung, die mit ''case'' durchgeführt wird.

Um das vorherige Beispiel mit dem Multiplexer zu erweitern:

<verilog>

wire [1:0] sel;
wire dout;
wire d0, d1, d2, d3;

...
case (sel)
2'b00: dout = d0;
2'b01: dout = d1;
2'b10: dout = d2;
2'b11: dout = d3;
endcase
...
</verilog>

Hier werden jetzt vier Eingangssignale in Abhängigkeit von ''sel'' auf den Ausgang gemultiplext.

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-02T09:48:34Z

Guenter: /* Logische Operationen */ Neuer Abschnitt über if-else, ?:

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg; Datentypen ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

== Entscheidungsoperation mit if-else und ? : ==

Bisher haben wir nur die sequentielle Abarbeitung von Operationen besprochen. Oft ist es nötig, basierend auf Signalzustände verschiedene Blöcke abzuarbeiten. Der von Programmiersprachen bekannte ''if'' und ''else'' Konstrukt ist hierzu hilfreich und wird von Verilog unterstütz.

Im folgenden Beispiel wird in Abhängigkeit von einem '''reset''' Signal entweder der eine oder der andere Anweisungsblock ausgeführt.

<verilog>
...

if(reset)
dout <= 0;
else
dout <= din;

...
</verilog>

Wenn in dem obigen Beispiel '''reset''' 1 ist, dann wird '''dout''' der Wert 0 zugewiesen. Ist '''reset''' 0 wird '''dout''' der Wert von '''din''' zugewiesen.

Ein weiterer Sprachkonstrukt der Form ''if-else'' ist der Entscheidungsoperator ''?:'', der auch von der Programmiersprache C bekannt ist. Er wird benutzt in der Form '''Test ? Wert_WAHR : Wert_FALSCH'''. '''Test''' kann hier eine logische Operation sein und wenn diese WAHR ist, dann wird '''Wert_WAHR''' zurück gegeben, andernfalls wird '''Wert_FALSCH''' zurück gegeben.

Die Nutzung soll hier am Beispiel eines Multiplexers erläutert werden:

<verilog>

wire dout;
wire d1, d2, sel;

...
assign dout = sel ? d1 : d2;

</verilog>

Mit ''wire'' nehmen wir einen ''assign'' Konstrukt und die Zuweisung an '''dout''' hängt jetzt von dem '''sel''' Signal ab. Ist es 1, wird '''dout''' der Wert von '''d1''' zugewiesen. Ist '''sel''' 0, wird '''dout''' der Wert von '''d0''' zugewiesen.

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-02T09:21:46Z

Guenter: /* always, initial */ Angepasst an Information aus dem neuen Abschnitt über die Ereignissteuerung. Erweitert mit der Beschreibung von zwei parallelen always Blöcke

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg; Datentypen ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und die Ausführung endet dann nach dem Abarbeiten der letzten Operation.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem '''clk''' Signal das invertierte '''clk''' Signal zugewiesen wird. Der ''always'' Block toggelt also das '''clk''' Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von '''clk''' auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist '''clk''' undefiniert, also ''x'', und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Im vorherigen Abschnitt haben wir die Ereignissteuerung kennen gelernte. Jetzt werden wir diese mit einem ''always'' kombinieren und damit steuern, wann der ''always'' Block durchlaufen werden soll.

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von '''a''', '''b''' und '''c''' wird '''y''' zugewiesen. Durch die Ereignissteuerung wird der ''always'' Block jedesmal durchlaufen, wenn sich der Signalzustand von '''a''', '''b''', oder '''c''' geändert hat. D.h. wenn sich einer der Signalzustände ändert, wird die Zuweisung ausgeführt und '''y''' auf den neusten Stand gebracht. Danach wartet die Ausführung wieder bis sie durch die Ereignissteuerung ausgelöst wird. So viel sei vorweg genommen, diesen Konstrukt nennt man kombinatorische Logik und in dem Abschnitt über synthesierbare Logik wird noch mal näher darauf eingegangen.

Seit Verilog 2001 kann die Ereignisliste auch vereinfacht werden und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''.

Wenn wir bisher von Signaländerungen im Zusammenhang mit der Ereignissteuerung gesprochen haben, dann sind wir immer davon ausgegangen das diese Änderung irgendwie von außen initiiert wurde. Gehen wir jetzt mal etwas mehr auf die parallele Beschreibung von Hardware ein und erweitern das vorherige Beispiel, um die Signaländerung mit in dem ''module'' auszuführen.

<verilog>
module;

reg y;
reg a = 1;
reg b = 1;
reg c = 0;

always
#10 c = ~c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Hier haben wir jetzt zwei ''always'' Blöcke die in Parallel ausgeführt werden. Der erste ''always'' Block ist basiert auf dem Taktgenerator von zuvor. Eine kleine Abänderung ist, dass jetzt hier das Signal '''c''' an Stelle von clk alle 10 Zeiteinheiten in seinem Zustand geändert wird. Der Block hat keine Ereignissteuerung, er wird also ständig durchlaufen. Nur der '''#10''' Konstrukt hält ihn jeweils für 10 Zeiteinheiten an.

Der zweite ''always'' Block wird wie vorher von der Ereignissteuerung immer dann ausgelöst, wenn sich eins der Signale in seiner Ereignisliste ändert. Hier haben wir '''a''' und '''b''' einen festen Wert zugewiesen. Das Signal '''c''' hingegen ändert sich ständig und löst die Ereignissteuerung und damit den Durchlauf des ''always'' Blockes aus. Die Zuweisung von '''y''' wird also immer dann auf den neusten Stand gebracht wenn sich '''c''' ändert.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-06-02T08:23:47Z

Guenter: /* @; Ereigniskontrolle */ --> Ereignissteuerung und weitere Umformulierung mit Erweiterung über posedge, negedge

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg; Datentypen ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== Ereignissteuerung mit @ ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereignissteuerung, die durch das '''@'''-Zeichen beschrieben wird, lernen wir jetzt eine weitere kennen.

Mit der Ereignissteuerung ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
module led_steuerung( input schalter );

reg led = 0;

...

@(schalter) led = 1;

...
endmodule
</verilog>

Wie bereits erwähnt wird die Ereignissteuerung mit dem Klammeraffen beschrieben. Nach dem Klammeraffen folgt die Ereignisliste. Sie ist eingebettet in Klammern, eine Liste von einem oder mehreren Signalen, die bestimmen wann die folgende Operation ausgeführt wird. Im obigen Beispiel ist der ''wire'' '''schalter''' in der Ereignisliste und bei einem Signalwechsel von diesem wird dem ''reg'' '''led''' der Wert 1 zugewiesen.

Neben Signaländerungen kann der Konstrukt auch genutzt werden um auf steigenden oder fallende Flanken zu reagieren. Hierzu werden die Schlüsselwörter ''posedge'' für steigende Flanke und ''negedge'' für fallende Flanke benutzt.

Im obigen Beispiel wird '''led''' der Wert 1 zugewiesen wenn '''schalter''' einen Signalwechsel von 0 nach 1 oder 1 auf 0 macht. Soll das z.B. eingegrenzt werden und eine Zuweisung nur beim Wechsel von 0 auf 1 stattfinden, kann das Beispiel wie folgt geändert werden:

<verilog>
module led_steuerung( input schalter );

reg led = 0;
...

@(posedge schalter) led = 1;

...
endmodule
</verilog>

Jetzt wird die Zuweisung erst bei einer steigenden Flanke von '''schalter''' ausgeführt.

Die Ereignissteuerung ist einer der grundlegenden Sprachkonstrukte in der Hardwarebeschreibung um die parallele Natur der Hardware zu beschreiben. Im nächsten Abschnitt werden wir sie im Zusammenhang mit ''always'' Blöcken kennen lernen. Diese Blöcke erlauben es, parallel ablaufende Prozesse zu beschreiben und mit Hilfe der Ereignissteuerung deren Abläufe zu kontrollieren.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das vorherige Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und im Falle einer Simulation würde diese dann weiterlaufen ohne das irgend welche weiteren Zuweisungen erfolgen.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem clk Signal das invertierte clk Signal zugewiesen wird. Der ''always'' Block toggelt also das clk Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von clk auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist clk undefiniert, also 'x' und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Das folgende Beispiel zeigt jetzt noch mal einen synthesierbaren Konstrukt mit dem ''always'' Block, bei dem die Ausführung durch eine sensitivity Liste gesteuert wird:

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von a, b und c wird y zugewiesen. Seit Verilog 2001 kann man die Liste vereinfachen und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''. Die sensitivity Liste gibt an, welche Signale auf Veränderung überwacht werden. Hat sich eins der Signal verändert, wird der ''always'' Block durchlaufen und das Ergebnis y auf den neusten Stand gebracht.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von sel entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-05-31T12:34:25Z

Guenter: /* wire, reg */ Neuer Abschnitt @ Ereigniskontrolle

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg; Datentypen ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== @; Ereigniskontrolle ==

Im vorherigen Abschnitt haben wir schon mit den Signalzuständen ''x'' und ''z'' eine Eigenart von [[Hardwarebeschreibungssprachen]] kennen gelernt. Mit der Ereigniskontrolle werden wir jetzt eine weitere kennen lernen.

Mit der Ereigniskontrolle (@) ist es möglich den Zustand von einem Signal überwachen zu lassen und dann in Abhängigkeit davon eine Zuweisung auszulösen.

Nehmen wir als Beispiel einen Schalter, der eine LED steuert.

<verilog>
wire schalter;
reg led = 0;

...
@(schalter) led = 1;
</verilog>

Die Ereigniskontrolle wird mit dem '''@''' Zeichen beschrieben. Im obigen Beispiel wird bei einem Signalwechsel von '''schalter''' dem '''led''' der Wert 1 zugewiesen.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das vorherige Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und im Falle einer Simulation würde diese dann weiterlaufen ohne das irgend welche weiteren Zuweisungen erfolgen.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem clk Signal das invertierte clk Signal zugewiesen wird. Der ''always'' Block toggelt also das clk Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von clk auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist clk undefiniert, also 'x' und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Das folgende Beispiel zeigt jetzt noch mal einen synthesierbaren Konstrukt mit dem ''always'' Block, bei dem die Ausführung durch eine sensitivity Liste gesteuert wird:

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von a, b und c wird y zugewiesen. Seit Verilog 2001 kann man die Liste vereinfachen und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''. Die sensitivity Liste gibt an, welche Signale auf Veränderung überwacht werden. Hat sich eins der Signal verändert, wird der ''always'' Block durchlaufen und das Ergebnis y auf den neusten Stand gebracht.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von seö entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-05-31T10:41:49Z

Guenter: /* Speicher Modellierung durch Felder */ Umformulierung

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das vorherige Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und im Falle einer Simulation würde diese dann weiterlaufen ohne das irgend welche weiteren Zuweisungen erfolgen.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem clk Signal das invertierte clk Signal zugewiesen wird. Der ''always'' Block toggelt also das clk Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von clk auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist clk undefiniert, also 'x' und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Das folgende Beispiel zeigt jetzt noch mal einen synthesierbaren Konstrukt mit dem ''always'' Block, bei dem die Ausführung durch eine sensitivity Liste gesteuert wird:

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von a, b und c wird y zugewiesen. Seit Verilog 2001 kann man die Liste vereinfachen und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''. Die sensitivity Liste gibt an, welche Signale auf Veränderung überwacht werden. Hat sich eins der Signal verändert, wird der ''always'' Block durchlaufen und das Ergebnis y auf den neusten Stand gebracht.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C sind z.B. Felder bekannt, um Elemente mit gleichem Datentyp zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird in die ersten Speicherstelle der hexadezimale Wert '''7f''' geschrieben.

Wird versucht von einem Speicherelement außerhalb des spezifizierten Indexbereiches zu lesen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von seö entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-05-31T10:37:49Z

Guenter: /* Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung */ Neuer Abschnitt für Speicher

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das vorherige Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und im Falle einer Simulation würde diese dann weiterlaufen ohne das irgend welche weiteren Zuweisungen erfolgen.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem clk Signal das invertierte clk Signal zugewiesen wird. Der ''always'' Block toggelt also das clk Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von clk auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist clk undefiniert, also 'x' und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Das folgende Beispiel zeigt jetzt noch mal einen synthesierbaren Konstrukt mit dem ''always'' Block, bei dem die Ausführung durch eine sensitivity Liste gesteuert wird:

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von a, b und c wird y zugewiesen. Seit Verilog 2001 kann man die Liste vereinfachen und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''. Die sensitivity Liste gibt an, welche Signale auf Veränderung überwacht werden. Hat sich eins der Signal verändert, wird der ''always'' Block durchlaufen und das Ergebnis y auf den neusten Stand gebracht.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog '''Vektor''' genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' '''data''' wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von '''nibble''' erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von '''nibble''' erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird '''nibble''' zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== Speicher Modellierung durch Felder ==

Mit der Modellierung von Speicher wird der Indizierung noch eins drauf gesetzt. Aus der Programmiersprache C z.B. werden Felder benutzt um Elemente gleichen Datentyps zusammen zu fassen. Der gleiche Konstrukt ist in Verilog möglich und wird z.B. zur Modellierung von Speicher genutzt.

Mit dem folgenden Konstrukt z.B. wird ein 8 Bit breiter Speicher mit 64 Speicherzellen und der Bezeichnung '''meinMem''' definiert:

<verilog>
reg [7:0] meinMem [0:63];
</verilog>

Eigentlich nur eine Verschmelzung von Vektor Definition (Bit breite vor Namen) mit Definition von Felder (Anzahl der Elemente nach Namen).

Auf ein Element kann jetzt mit der bekannten Indizierung von Feldern zugegriffen werden:

<verilog>
meinMem[0] = 8'h7f;
</verilog>

Hier wird der ersten Speicherstelle der hexadezimale Wert '''7f''' zugewiesen.

Wird versucht auf ein Speicherelement außerhalb des spezifizierten Indexbereiches zu zugreifen ist das Ergebnis ''x''. Ein Schreibversuch auf ein Element außerhalb des spezifizierten Indexbereichs hat keine Auswirkung.

Neben eindimensionalen ist auch möglich mehrdimensionale Speicher zu definieren wie z.B. mit:

<verilog>
reg [7:0] zweiDmem [0:15][0:63];
</verilog>

Analog zum eindimensionalen Feld erfolgt der Zugriff mit:

<verilog>
zweiDmem[0][7] = 8'h2a;
</verilog>

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von seö entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-05-31T09:53:50Z

Guenter: /* Gliederung */ Neue Formulierung und Schreibfehler behoben

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die [[Hardwarebeschreibungssprachen|Hardwarebeschreibungssprache]] Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache für Simulation und Synthese zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Konstrukte

In der Sprachübersicht werden grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur die Teile der Sprache zu besprechen, die für Neueinsteiger(innen) erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vorgezogen, da es hier keine Beschränkungen in der Nutzung der Sprache und der Art der Modellierung gibt. Auch ist es der Teil, bei dem erste praktische Erfolge mit dem Simulator erzielt werden.

Darauf folgt dann der Teil in dem die synthesierbaren Konstrukte der Sprache erläutert werden.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das vorherige Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und im Falle einer Simulation würde diese dann weiterlaufen ohne das irgend welche weiteren Zuweisungen erfolgen.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem clk Signal das invertierte clk Signal zugewiesen wird. Der ''always'' Block toggelt also das clk Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von clk auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist clk undefiniert, also 'x' und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Das folgende Beispiel zeigt jetzt noch mal einen synthesierbaren Konstrukt mit dem ''always'' Block, bei dem die Ausführung durch eine sensitivity Liste gesteuert wird:

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von a, b und c wird y zugewiesen. Seit Verilog 2001 kann man die Liste vereinfachen und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''. Die sensitivity Liste gibt an, welche Signale auf Veränderung überwacht werden. Hat sich eins der Signal verändert, wird der ''always'' Block durchlaufen und das Ergebnis y auf den neusten Stand gebracht.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog Vektor genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' data wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von nibble erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von nibble erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird nibble zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von seö entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-05-30T20:00:32Z

Guenter: /* $monitor */ Beschreibung erweitert

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die Hardwarebeschreibungssprache Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache, wie z.B. für Simulation oder Synthese, zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Kunstrukte

In der Sprachübersicht werden einige grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur diese Teile der Sprache zu besprechen, die für jemanden der Verilog neu lernt erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation/Verifikation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vor der synthesierbaren Logik gesetzt, da er weniger Restriktionen bezüglich benutzbarer Sprachkonstrukte hat. Auch ist es der Teil, bei dem als erstes einige praktische Erfolge mit der Simulation gewonnen werden.

Darauf folgt dann der Teil mit den synthesierbaren Konstrukten.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das vorherige Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und im Falle einer Simulation würde diese dann weiterlaufen ohne das irgend welche weiteren Zuweisungen erfolgen.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem clk Signal das invertierte clk Signal zugewiesen wird. Der ''always'' Block toggelt also das clk Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von clk auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist clk undefiniert, also 'x' und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Das folgende Beispiel zeigt jetzt noch mal einen synthesierbaren Konstrukt mit dem ''always'' Block, bei dem die Ausführung durch eine sensitivity Liste gesteuert wird:

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von a, b und c wird y zugewiesen. Seit Verilog 2001 kann man die Liste vereinfachen und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''. Die sensitivity Liste gibt an, welche Signale auf Veränderung überwacht werden. Hat sich eins der Signal verändert, wird der ''always'' Block durchlaufen und das Ergebnis y auf den neusten Stand gebracht.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog Vektor genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' data wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von nibble erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von nibble erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird nibble zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

Wird das folgende Beispiel simuliert:

<verilog>
module monitor_tb;

reg clk = 0;
reg reset = 0;

initial
$monitor("Zeit: %t Takt: %b reset: %b", $time, clk, reset);

always
#10 clk =~clk;

initial begin
$display("Kleiner $monitor test");

#15 reset = 1;
#22 reset = 0;

#10 $display("#%0t Fertig", $time);
$finish;

end

</verilog>

Erhält man folgenden Ausdruck:

<c>
Kleiner $monitor test
Zeit: 0 Takt: 0 reset: 0
Zeit: 10 Takt: 1 reset: 0
Zeit: 15 Takt: 1 reset: 1
Zeit: 20 Takt: 0 reset: 1
Zeit: 30 Takt: 1 reset: 1
Zeit: 37 Takt: 1 reset: 0
Zeit: 40 Takt: 0 reset: 0
#47 Fertig
</c>

Zum Zeitpunkt 0 wird der ''$display'' Task ausgeführt und druckt den Text '''"Kleiner $monitor test"''' aus. Alle Signale sind zu dem Zeitpunkt auf 0 und der ''$monitor'' Task druckt zum ersten mal den Signalzustand aus.

Der nächste Aufruf erfolgt wenn clk nach 10 Zeiteinheiten seinen Zustand wechselt. Dieser Wechsel wird autonom in dem ''always'' Block alle 10 Zeiteinheiten durchgeführt. Parallel dazu wird in dem ''initial'' Block nach 15 Zeiteinheiten der reset auf 1 gesetzt. Dazwischen kommt wieder der Wechsel von clk, der um 20 auf 0 und um 30 wieder auf 1 gesetzt wird.

Im ''initial'' Block wird reset 22 Zeiteinheiten nach dem Setzen wieder zurück gesetzt. Das Setzen fand um 15 statt, plus 22 Zeiteinheiten, somit wird reset um 37 zurück gesetzt. Dann folgt noch mal ein clk Wechsel, bevor die Simulation um 47 beendet wird. Zu der Zeit findet kein Signalwechsel mehr statt, so das der ''$monitor'' Task nicht mehr aufgerufen wird. So haben wir vor dem ''$finish'' Task noch mal einen ''$display'' Task gesetzt, der die Zeit mit dem Wort '''"Fertig"''' ausdruckt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von seö entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-05-30T19:27:10Z

Guenter: /* $finish */ Neuer Abschnitt $dumpfile, $dumpvars

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die Hardwarebeschreibungssprache Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache, wie z.B. für Simulation oder Synthese, zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Kunstrukte

In der Sprachübersicht werden einige grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur diese Teile der Sprache zu besprechen, die für jemanden der Verilog neu lernt erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation/Verifikation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vor der synthesierbaren Logik gesetzt, da er weniger Restriktionen bezüglich benutzbarer Sprachkonstrukte hat. Auch ist es der Teil, bei dem als erstes einige praktische Erfolge mit der Simulation gewonnen werden.

Darauf folgt dann der Teil mit den synthesierbaren Konstrukten.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das vorherige Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und im Falle einer Simulation würde diese dann weiterlaufen ohne das irgend welche weiteren Zuweisungen erfolgen.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem clk Signal das invertierte clk Signal zugewiesen wird. Der ''always'' Block toggelt also das clk Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von clk auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist clk undefiniert, also 'x' und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Das folgende Beispiel zeigt jetzt noch mal einen synthesierbaren Konstrukt mit dem ''always'' Block, bei dem die Ausführung durch eine sensitivity Liste gesteuert wird:

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von a, b und c wird y zugewiesen. Seit Verilog 2001 kann man die Liste vereinfachen und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''. Die sensitivity Liste gibt an, welche Signale auf Veränderung überwacht werden. Hat sich eins der Signal verändert, wird der ''always'' Block durchlaufen und das Ergebnis y auf den neusten Stand gebracht.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog Vektor genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' data wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von nibble erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von nibble erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird nibble zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

=== $dumpfile, $dumpvars ===

Ein Value Change Dump (VCD) Files ist ein text basiertes File in dem Signalzustandsänderungen von der Simulation geschrieben werden. Die Datei kann dann z.B. von einem Programm eingelesen und dargestellt werden. Ein solches Programm ist z.B. [http://home.nc.rr.com/gtkwave/ gtkwave].

Der Simulator generiert in der Regel so ein VCD File nicht von selbst, sondern muss dazu instruiert werden. Eine Form die von Simulatoren unterstützt wird ist durch die beiden Verilog System Tasks ''$dumpfile'' und ''$dumvars''.

<verilog>
module top_tb;

initial begin
$dumpfile("top_tb.vcd");
$dumpvars(0, top_tb);
end
...
endmodule
</verilog>

Mit ''$dumfile("top_tb.vcd")'' wird der Dateiname des VCD Files spezifiziert. Gerade bei der Simulatin von großen Designs ist es sinnvoll die Anzahl der Signal die in das Dumpfile geschrieben werden zu beschränken. Der ''$dumpvars'' System Task erlaubt dazu die Hierarchieebene mit zu spezifizieren. Mit dem Befehl ''$dumpvars(0, top_tb)'' werden all Signale von der spezifizierten Ebene an nach unten in das Dumpfile geschrieben. Sollen z.B. nur die Signal in top_tb in das Dumpfile geschrieben werden, dann kann dies mit der Ebene 1, also ''$dumpvars(1, top_tb)'' beschränkt werden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von seö entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]

Verilog

2008-05-30T18:59:15Z

Guenter: /* Icarus Verilog */ Weitere Erläuterung des Makefile

= Einleitung =

Verilog ist eine Hardwarebeschreibungssprace (Hardware Description Language: HDL) die es ermöglicht ein digitales System in einem recht weiten Spektrum an Abstraktion zu spezifizieren.

== Geschichte ==
Verilog wurde im Winter 1983/84 /footnote{"The Verilog Hardware
Description Language", Thomas & Moorby} als ein proprietäres
Produkt zur Verifikation und Simulation von digitaler Logik entwickelt.

Verilog wurde erstmals vom [http://ieee.org IEEE] 1995 standardisiert in IEEE 1364-1995.
Eine Erweiterung wurde dann 2001 durchgeführt mit IEEE 1364-2001 und
später IEEE 1364-2005.

== Entwicklung der Hardwarebeschreibungssprache ==

Das Besondere an einer Hardwarebeschreibungssprache sind die zwei unterschiedlichen Ansätze mit der die Sprache eingesetzt wird. Bei einer Programmiersprache gibt es den Sprachsyntax und in Abhängigkeit der Sprache gibt es eine Philosophie wie diese Sprache und alle verfügbaren Konstrukte eingesetzt werden. Also z.B. gibt es funktionale Programmiersprache, wie z.B. C, bei der mit Hilfe von Funktionsaufrufen ein großes Problem in viele kleine Probleme unterteilt wird. Bei Objekt orientierten Sprachen wie z.B. C++ nimmt man Objekte und unterteil ein Problem in die verschieden Objekte und wie diese miteinander kommunizieren.

[Hardwarebeschreibungssprachen]] wurden ursprünglich zur Spezifikation und Verifikation mit einem Simulator entwickelt. In diesem Bereich kann man auch den gesamten Syntax der Sprache einsetzen. Unterschieden werden die beiden Arten

* Simulation des Verhaltens (Behavioral Simulation)
* Simulation der Struktur (Structural Simulation)

Beim Simulieren des Verhaltens werden oft noch keine zeitlichen Aspekte verwendet. Es geht darum in einer abstrakten Form die Funktion des zu entwickelten digitalen Schaltkreises zu simulieren.

Mit der strukturellen Simulation wird dann das Design takt genau simuliert.

Später dann kamen einige Electronic Design Automation (EDA) - Firmen auf die Idee, eine Hardwarebeschreibungssprache nicht nur für die Simulation, sondern auch für die Synthese der eigentlichen Hardware zu benutzen. Für diesen Ansatz waren aber die [[Hardwarebeschreibungssprachen]] viel zu mächtig und so wurden nur einfache Sprachkonstrukte genommen, die das Synthesetool unterstützt.

Aus dieser Entwicklung heraus haben sich die beiden Sichtweisen einer Hardwarebeschreibungssprache für Simulation und Synthese entwickelt. Ein Benutzer muss also immer im Hinterkopf haben, welchen Teil der Sprache er für seine Entwicklung nutzen kann. Für die Simulation sind in der Regel keine Grenzen gesetzt. Für die Entwicklung synthesierbarer Logik dagegen sind nur einige Sprachkonstrukte erlaubt. Aufschluss darüber welche das sind findet man am Besten in dem Benutzerhandbuch des jeweiligen Synthesetools. Für Xilinx ist das z.B. das [http://www.google.de/search?q=xilinx+xst+user+guide XST User's Guide].

== Gliederung ==

Dieser Artikel gibt eine Einführung in die Hardwarebeschreibungssprache Verilog, mit der Zielsetzung, ein Verständnis für die unterschiedliche Nutzung der Sprache, wie z.B. für Simulation oder Synthese, zu geben.

Der Artikel gliedert sich in die drei Teile:

* Sprachübersicht
* Simulation/Verifikation
* Synthesierbare Kunstrukte

In der Sprachübersicht werden einige grundlegende Sprachelemente vermittelt. Dieser Teil ist bewusst klein gehalten und versucht nur diese Teile der Sprache zu besprechen, die für jemanden der Verilog neu lernt erst mal wichtig sind.

Daran schließt sich ein Teil mit dem Schwerpunkt der Simulation/Verifikation synthesierbarer Logik. Zwar wissen wir an der Stelle noch nicht viel von synthesierbarer Logik, dieser Teil wurde aber bewusst vor der synthesierbaren Logik gesetzt, da er weniger Restriktionen bezüglich benutzbarer Sprachkonstrukte hat. Auch ist es der Teil, bei dem als erstes einige praktische Erfolge mit der Simulation gewonnen werden.

Darauf folgt dann der Teil mit den synthesierbaren Konstrukten.

= Sprachübersicht =

== module ==

Die grundlegende Gruppierung wird in Verilog durch ''module'' durchgeführt.

<verilog>
// Einzeiliger Kommentar, wie C++

module MeinModulName ( input a, output b, inout data);

/* Mehrzeiliger Kommentar
Wie von C bekannt
*/

endmodule
</verilog>

Signale werden durch Ports dem Modul übergeben. Für Signale in das Modul
gibt es den ''input'' Port. Ausgänge werden durch ''output''
spezifiziert und ein bidirektionaler Bus durch ''inout''.

Wie oben gezeigt sind ein- oder mehrzeilige Kommentar wie bei C/C++ möglich.

== wire, reg ==

Die grundlegenden Signale in Verilog sind ''wire'' und ''reg''. Analog zum elektrischen Draht können mit dem ''wire'' Verbindungen durchgeführt werden. Für die Modulierung digitaler Logik ist es aber auch nötig Signaltreiber zu haben. Hier kommt der Datentyp ''reg'' ins Spiel. Mit ihm können Signalzustände gespeichert werden.

Verilog unterstützt die Signalzustände:

* 0 --> logisch null
* 1 --> logisch eins
* z --> hochohmig
* x --> undefiniert

Mit dem ''assign'' Konstrukt können die Signalzustände wie folgt einem ''wire'' zugewiesen werden:

<verilog>
module;

wire a, b, c, d;

assign a = 0;
assign b = 1;
assign c = x;
assign d = z;

endmodule
</verilog>

Mit dem ''assign'' Konstrukt können nur einem ''wire'' Signale zugewiesen werden. Ein ''reg'' muss innerhalb eines ''always'' oder ''initial'' Block seine Werte zugewiesen bekommen.

== always, initial ==

Die ''always'' und ''initial'' Blöcke werden verwendet um die parallele Natur von Hardware zu beschreiben. Jeder dieser Blöcke wird parallel ausgeführt, wobei ein ''initial'' Block nur einmal durchlaufen wird und ein ''always'' Block, wie eine Endlosschleife, ständig wiederholt wird.

Nehmen wir mal einen ''initial'' Block als Beispiel und kommen auf das vorherige Problem zurück, dass einem ''reg'' nur in einem ''always'' oder ''initial'' Block Werte zugewiesen werden können:

<verilog>
module;

reg a, b, c, d;

initial begin

a = 0;
b = 1;
c = z;
d = x;

end

endmodule
</verilog>

Was in dem Beispiel neu dazu gekommen ist, ist die Gruppierung durch ''begin'' und ''end''. Vergleichbar mit den geschweiften Klammern in der Programmierung mit C/C++, können Segmente mit ''begin'' und ''end'' zusammengefasst werden.

Im obigen Beispiel wird der ''initial'' Block einmal durchlaufen und im Falle einer Simulation würde diese dann weiterlaufen ohne das irgend welche weiteren Zuweisungen erfolgen.

Der ''initial'' Konstrukt wird vorwiegend in der Simulation für Testbenches verwendet. In der Beschreibung synthesierbarer Logik findet er weniger Verwendung.

Der ''always'' Konstrukt kann sowohl in Testbenches als auch in synthesierbarer Logik verwendet werden. Hier erst mal ein Beispiel aus einer Testbench zum Generieren eines Taktsignals:

<verilog>
module;

reg clk = 0;

always
#10 clk = ~clk;

endmodule
</verilog>

Als neuer Sprachkonstrukt kommt hier das Verzögerungszeichen ''#'', das die Ausführung in diesen Fall für 10 Zeiteinheiten anhält und dann mit der Ausführung des ihm folgenden Konstrukts weiter fortfährt. Was also in dem ''always'' Block geschieht ist, dass die Simulation für 10 Zeiteinheiten angehalten wird und dann dem clk Signal das invertierte clk Signal zugewiesen wird. Der ''always'' Block toggelt also das clk Signal alle 10 Zeiteinheiten.

Die anfängliche Initialisierung von clk auf 0 ist sehr wichtig, da das Toggeln nur von 0 auf 1, bzw. 1 auf 0 funktioniert. Wird sie weggelassen ist clk undefiniert, also 'x' und das Toggeln würde nicht funktionieren.

Vielleicht ist es ganz sinnvoll an dieser Stelle noch mal zu erwähnen, dass das Verzögerungszeichen nicht synthesierbar ist.

Das folgende Beispiel zeigt jetzt noch mal einen synthesierbaren Konstrukt mit dem ''always'' Block, bei dem die Ausführung durch eine sensitivity Liste gesteuert wird:

<verilog>
module;

reg y, a, b, c;

always @(a, b, c)
y = a & b & c;

endmodule
</verilog>

Die logische UND Verknüpfung von a, b und c wird y zugewiesen. Seit Verilog 2001 kann man die Liste vereinfachen und einfach durch (*) ersetzen. Der Konstrukt heißt dann also '''always @(*)'''. Die sensitivity Liste gibt an, welche Signale auf Veränderung überwacht werden. Hat sich eins der Signal verändert, wird der ''always'' Block durchlaufen und das Ergebnis y auf den neusten Stand gebracht.

== Hierarchie ==

Um ein komplexeres Design zu kreieren ist die Instanzierung von Modulen sehr hilfreich. Nehmen wir das Modul ''module mux(input a, input b, input sel, ouput y)'', ohne genauer auf dessen Innenleben einzugehen, und instanzieren es mehrmals in dem ''module top(...)'':

<verilog>
module top (input a,
input b,
input c,
input d,
input s1,
input s2,
input s3,
output y);

wire w1, w2;

mux m1 ( .a(a), .b(b), .sel(s1), .y(w1) );
mux m2 ( .a(c), .b(d), .sel(s2), .y(w2) );
mux m3 ( .a(w1), .b(w2), .sel(s3), .y(y) );

endmodule
</verilog>

Die Verknüpfung findet statt durch die explizite Nennung der Ports. Der Port von dem instanzierten Modul wird in der Form '''.PortName()''' geschrieben. Das Signal mit dem er verknüpft wird schreibt man in die Klammern des Ports. Mit der Verknüpfung '''.y(w1)''' wird also der Ausgangsport '''y''' von der Instanz '''m1''' des Modules '''mux''' mit dem ''wire'' '''w1''' im Modul '''top''' verknüpft.

Eine andere Variante der Verknüpfung wird durch die Position der Ports in der Definition des Modules erreicht. In unserem Fall ist Port a der erste Port, also wird der ''wire'' der an erste Stelle bei der Instanzierung geschrieben wird, mit Port a des Moduls verbunden. Das vorherige Beispiel wird in diesem Fall dann so aussehen:

<verilog>
...
mux m1 ( a, b, s1, w1 );
mux m2 ( c, d, s2, w2 );
mux m3 ( w1, w2, s3, y );
...
</verilog>

Der Vorteil ist, dass hier nicht noch explizit der Port des Modules genannte werden muss. Das wird jedoch schnell unübersichtlich mit Modulen, die eine lange Portliste haben.

== Skalar, Vektor, Bit-Splitting, Verkettung, Wiederholung ==

Bisher haben wir nur einfache Signal genutzt, d.h. Signale die ein Bit breit sind. Ein Bus aus ''wire'' z.B. wird in der Form ''wire [msb:lsb] <wire_name>'' spezifiziert und wird in Verilog Vektor genannt. Entsprechend kann auch ein ''reg'' Vektor spezifiziert werden.

<verilog>
wire [15:0] data;

...
data[0] = 1; // Setzt nur Bit 0

data[15:13] = 3'b110; // Setzt Bits 15, 14 = 1, Bit 13 = 0, Wert ist binär
data[13:11] = 3'd2; // Setzt Bits 13-11, Wert ist dezimal
data[10:1] = 9'h0a; // Setzt Bits 10-1, Wert ist hexadezimal
</verilog>

Das Beispiel zeigt wie ein 16 Bit breiter Vektor spezifiziert wird und anschließend einzelne Bits davon gesetzt werden.

Bei der Zuweisung wird hier erstmals bei Werten die Bitbreite spezifiziert und verschiedene Zahlenrepräsentationen verwendet. Die Bitbreite wird in der Form '''<Zahl><Hochkomma>''' spezifiziert. Für die verschiedenen Zahlenformate gibt es die Buchstaben ''b, d, h'', die für binär, dezimal, bzw. hexadezimal stehen.

Aufmerksamen Lesern ist vielleicht aufgefallen, dass die Art der Zuweisung eigentlich in einen ''initial'' oder ''always'' Block hätte gepackt werden müssen um so zu funktionieren. Eine andere Möglichkeit währe ein ''assign'' Konstrukt daraus zu machen. Aus Übersichtlichkeit wurde hierbei darauf verzichtet.

In diesen Zusammenhang passt es auch die Verkettung von Signalen zu erklären. Sie wird mit geschweiften Klammern erreicht:

<verilog>
wire [7:0] data;
wire [3:0] nibble;

...
data = {4'b0000, nibble};
</verilog>

Dem ''wire'' data wird ein 8 Bit breites Wort zugewiesen, bei dem die oberen 4 Bit auf Null gesetzt sind und die unteren 4 Bit den Signalzustand von nibble erhalten.

Die Wiederholung wird auch mit geschweifter Klammer beschrieben und hat die Form '''{r{num}}'''. Hierbei wird num, r mal wiederholt.

Um bei dem letzten Beispiel zu bleiben, eine Abänderung bei der die oberen 4 Bit nicht auf Null gesetzt werden, sondern auch den Signalzustand von nibble erhalten kann folgendermaßen erreicht werden:

<verilog>
...
data = {2{nibble}};
</verilog>

Hier wird nibble zwei mal wiederholt und damit auf 8 Bit Länge gebracht.

== =, <=; blockierende und nicht-blockierende Zuweisung ==

In Verilog gibt es die zwei Zuweisungsarten:

* =
* <=

Erstere wird als blockierende Zuweisung (blocking assignment) bezeichnet. Letztere als nicht-blockierend (nonblocking assignment).

Im Standard werden die folgenden zwei Richtlinien für deren Verwendung gegeben:

* (=) Benutze blockierende Zuweisungen in ''always'' Blöcken die kombinatorische Logik modellieren.
* (<=) Benutze nicht-blockierende Zuweisungen in ''always'' Blöcken die sequentielle Logik modellieren.

Nähere Details über den Hintergrund können in dem Artikel [http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!", Cliff Cummings, SNUG 2000] nachgelesen werden.

== Logische Bit-Operationen ==

Die grundlegenden logischen Bit-Operation sind:

*| --> OR
*& --> AND
*~ --> NOT
*^ --> XOR

Sie werden erweitert durch:
*~& --> NAND
*~| --> NOR
*^~ oder ~^ --> XNOR

Verilog unterstützt einen sogenannten Reduktions-Operator, bei dem mit
einem Operator mehrere Signale zusammen geführt werden. Damit kann z.B.
eine logische AND-Verknüpfung von 8 Signalen wie folgt durchgeführt
werden:

<verilog>
module MeinUnd8 ( input [7:0] a,
output y);

assign y = &a;

endmodule
</verilog>

== Arithmetische Operationen, signed, $signed ==

Bevor wir kurz über die grundlegenden arithmetischen Operationen sprechen kehren wir noch mal zu den Datentypen ''wire'' und ''reg'' zurück. Diese werden in Verilog als vorzeichenlos, also '''unsigned''' angesehen.

Entsprechend folgen arithmetische Operationen mit ''wire'' und ''reg'' dem Modulo 2^n, wobei n die Bitbreite des Vektors ist.

Verilog unterstützt die bekannten arithmetischen Operation:

* +
* -
* *
* /

Mit der entsprechend bekannten Präzedenz das Multiplikation und Division vor Addition und Subtraktion geht. Für Klarheit können, wie so oft bei Programmiersprachen, Operationen mit Klammern gruppiert werden.

Leider unterstützt Verilog nicht eine Vereinfachung, die z.B. von der Programmiersprache C bekannt ist, bei der die Zuweisung und der Operator zusammengeschrieben werden und damit ein Operand eingespart werden kann.

Die Schreibweise:
<verilog>
a = a + 12;
</verilog>
Kann also nicht abgekürzt werden. Auch ist kein Inkrement oder Dekrement Operator bekannt. In ''for'' Schleifen ist es also immer nötig zu schreiben:
<verilog>
i=i+1;
</verilog>

Um jetzt auch mit 2's Komplement zahlen rechnen zu können wird der Konstrukt ''signed'' benutzt.

<verilog>
reg signed [3:0] a;
reg [3:0] b;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13
</verilog>

Erinnern wir uns das es sich um Modulo 2^n Arithmetik handelt. Im dem Fall wo a als signed spezifiziert wird, ist der Zahlenbereich von a [-8 .. 7]. Für den Fall von b ist er [0..15] und damit entsteht für 2-4 ein Unterlauf und die Berechnung ist 15-2.

In diesem Zusammenhang ist es wichtig zu betrachten was passiert wenn bei arithmetischen Operation gemischte Operanten, also einer ist unsigned der andere signed, genommen werden. '''Eine Operation zwischen einem signed und einem unsigned Datentyp resultiert in einen unsigned Datentyp.''' Da dieses Verhalten nicht immer gewünscht ist, gibt es die $signed() System Funktion. Auf System Funktionen und System Tasks wird später noch näher eingegangen.

Um jetzt eine arithmetische Operation mit a und b aus dem vorherigen Beispiel durchzuführen und das Ergebnis auch als signed zu haben, muss der unsigned Operand erst mit $signed() in einen signed gewandelt werden.

<verilog>
reg signed [3:0] a;
reg [3:0] b;
reg signed [4:0] c;

a = 2 - 4; // a = -2
b = 2 - 4; // b = 13

c = a + $signed(b);
</verilog>

== Vergleichs Operationen; ==, ===, !=, !==, <, > ==

Analog zu anderen Programmiersprachen stellt Verilog die Vergleichsoperatoren ==, !=, <, > zur Verfügung. Erinnern wir uns aber daran das ein Signal neben 0 und 1 auch noch die Zustände x oder z annehmen kann.

'''Eine Vergleichsoperation bei der ein Bit den Zustand x oder z hat, ist im Ergebnis x und das wird als FALSCH angesehen.'''

Zum Beispiel:

<verilog>
4'b1100 == 4'b1100; // = 1 --> WAHR
4'b1100 == 4'b11xx; // = x --> FALSCH
4'b11xx == 4'b11xx; // = x --> FALSCH
4'b110z == 4'b110z; // = x --> FALSCH
</verilog>

Im gleichen Sinn werden größer oder kleiner Operationen immer FALSCH wenn ein x oder z Zustand vorhanden ist:

<verilog>
4'b1100 > 4'b11xx; // = x --> FALSCH
4'b110z > 4'b1100; // = x --> FALSCH
</verilog>

Um einen exakten Vergleich durch zu führen gibt es den sogenannten case equality operator (===). Hier werden auch die Zustände x und z mit in den Vergleich einbezogen:

<verilog>
4'b1100 === 4'b1100; // = 1 --> WAHR
4'b1100 === 4'b11xx; // = 0 --> FALSCH
4'b11xx === 4'b11xx; // = 1 --> WAHR
4'b110z === 4'b110z; // = 1 --> WAHR
4'b110x === 4'b110z; // = 0 --> FALSCH
</verilog>

== Logische Operationen ==

Die im letzten Abschnitt beschriebenen Vergleichsoperationen können mit logischen Operationen Verknüpft werden. Wie von den gängigen Programmiersprachen unterstützt Verilog die logischen Operationen:

* && --> AND
* || --> OR
* ! --> NOT

= Verilog für Simulation/Verifikation =

Hier werden Sprachkonstrukte beschrieben die nicht synthesierbar sind und nur für die Verifikation im Zusammenhang mit einem Simulator sinnvoll sind.

== System Tasks und Functions ==

System Tasks und Functions sind ein Weg einen Verilog Simulator mit Funktionen zu erweitern. In diesem Abschnitt werden einige gängige System Tasks beschrieben die im Verilog Standard spezifiziert sind und somit in allen bekannten Simulatoren implementiert sind.

System Tasks und Functions beginnen immer mit einem Dollarzeichen ($) und werden in der Regel von Synthesis-Tools ignoriert.

=== $display ===

Der $display Task wird verwendet um Informationen zum stdout zu schreiben. Die Form der Benutzung ist sehr an die printf() Funktion von C angelehnt. Ein wesentlicher Unterschied ist, dass mit der $display Funktion automatisch ein Zeilenvorschub angehängt wird und so kein extra "\n" am Ende des Strings gesetzt werden muss.

<verilog>
integer i;
...
i = 10;
$display("Hallo Welt Nr. %d", i);
</verilog>

Wenn der Task ausgeführt wird, ersetzt der Simulator %d mit dem Wert von i. Die Darstellung kann unterschiedlich formatiert werden und es gibt folgende Formatierungsbefehle:

*%d - dezimal
*%h - hexadezimal
*%b - binär
*%o - oktal
*%s - string
*%c - ASCII Zeichen
*%v - Signalstärke
*%m - Hierarchischer Name

Einen zusätzlichen Zeilenvorschub erhält man durch \n, Tab z.B. durch \t.

Ein weitere Unterschied zu printf ist, dass mit $display die Zahlen rechtsbündig ausgerichtet werden. In manchen Fälle mag das nicht erwünscht sein und so besteht die Möglichkeit den Formatierungsbefehl %d z.B. in der Form %0d zu schreiben. Jetzt wird die Zahl linksbündig ausgerichtet.

Am Beispiel eines integer Datentyp sei das verdeutlicht:
<verilog>
integer i;
...
$display("Hallo Welt Nr. %d", i);
$display("Hallo Welt Nr. %0d", i);
</verilog>

Im ersten Fall werden so viele Leerzeichen nach dem Wort 'Nr.' eingefügt, damit die Zahl rechtsbündig dargestellt wird. Mit der %0d Version wird die Zahl linksbündig dargestellt.

<verilog>
Hallo Welt Nr. 10
Hallo Welt Nr. 10
</verilog>

Die linksbündige Darstellung wird von den Formatierungsbefehlen %d, %o, und %h unterstützt.

=== $monitor ===

Ähnlich dem $display Task schreibt der $monitor Task den Text zum stdout. Einziger Unterschied ist, dass der Task automatisch überprüft ob eines der Signal sich geändert hat und jedes mal bei einer Änderung einen neuen Ausdruck durchführt.

=== $finish ===

Beendet die Simulation. Jede Testbench sollte einen $finish System Task haben um die Simulation zu beenden.

= Synthesierbare Konstrukte =

== Kombinatorische Logik ==

Das folgende Beispiel zeigt einen 2:1 Multiplexer:

<verilog>
module Mein2zu1Mux ( input [3:0] d0, d1,
input sel,
output y);

assign y = sel ? d1 : d0;

endmodule
</verilog>

Ein neuer Operator der hier vorgestellt wird ist der Entscheidungsoperator (?:), im Englischen als conditional operator bezeichnet. Für bedingte Zuweisungen kann er an Stelle von der ''if'' oder ''case'' Anweisung verwendet werden.

Dem Signal y wird in Abhängigkeit von seö entweder d1 oder d0 zugewiesen. Ist sel wahr wird d1 zugewiesen, ist es falsch wird d0 zugewiesen.

Natürlich kann der Operator auch verschachtelt werden, irgendwann macht das aber keine Sinn mehr und wird unübersichtlich. Der Entscheidungsoperator kann dann durch ein ''case'' Anweisung ersetzt werden.

<verilog>
module mux ( input sel,
input d0,
input d1,
input d2,
input d3,
output y);

always @(*)
case (sel)
2'b00: y = d0;
2'b01: y = d1;
2'b10: y = d2;
2'b11: y = d3;
endcase
</verilog>

Getreu der Empfehlung für die Zuweisung kombinatorischer Logik wurde hier die blockierende Zuweisung verwendet.

In Bezug auf die Synthese ist zu beachten, dass alle Kombinationen von sel in der case-Anweisung enthalten sein müssen, sonst ist es möglich das durch die Synthese ein Latch entsteht. Näheres kann dazu im Synthesis User's Guide des jeweiligen FPGA Herstellers gefunden werden.

== Sequentielle Logik ==

Analog zum VHDL ''process'' wird in Verilog die ''always'' Anweisung verwendet. Ein einfaches Register synchron zur steigenden Flanke des Taktsignals wird wie folgt beschrieben:

<verilog>
module Flop (input clk,
input [3:0] d,
output reg [3:0] q);

always @ (posedge clk)
q <= d;

endmodule
</verilog>

Analog zur steigenden flanke kann auch auf die fallende Flanke mit ''negedge'' getriggert werden.

= Open-Source Simulatoren =

Für Verilog gibt es die folgenden Simulatoren als Open-Source:

*[http://icarus.com/eda/verilog/ Icarus Verilog]
*[http://www.pragmatic-c.com/gpl-cver/ CVER]

Im folgenden wird etwas näher auf die Nutzung mit Icarus Verilog eingegangen.

== Icarus Verilog ==

Icarus Verilog ist eine Simulations- und Synthese-Software für Verilog. Bei der Software handelt es sich um Kommandozeilen basierte Applikationen. In diesem Abschnitt werden wir uns auf die Funktion als Simulator beschränken.

Die Funktion ist verteilt auf die zwei Applikationen:

* iverilog (Compiler)
* vvp (Simulator)

Basierend auf dem Beispiel von der [http://iverilog.wikia.com/wiki/Getting_Started Icarus Verilog Dokumentation] nehmen wir das "Hallo Welt" Beispiel:

<verilog>
module main;
initial
begin
$display("Hallo, Welt");
$finish;
end
endmodule
</verilog>

Zum Kompilieren wird das Kommando ''iverilog'' verwendet. Mit dem -o Parameter spezifiziert man den Namen der Ausgabedatei.

<c>
> iverilog -o main.vvp main.v
</c>

Der Kompilierte Code wird dann mit der Applikation ''vvp'' simuliert.

<c>
> vvp main.vvp
Hallo Welt
</c>

Für größere Projekte ist ein sinnvoller Einsatz den Aufruf durch ein Makefile durchzuführen. Im Mai 2008 hat Larry Doolittle auf der gEDA users mailing list ein Makefile zur Verfügung gestellt das hier folgend beschrieben werden soll.

Das '''Makefile''' besteht aus einem allgemeinen Teil der sich nicht ändert und einem projektspezifischen Teil in dem die Abhängigkeiten für das spezielle Projekt festgelegt werden.

<c>
#
# Hier werden die Abhängigkeiten festgelegt
#
foo_tb: foo.v bar.v

#####################################################################
# Allgemeiner Teil der sich nicht ändert
#
%_tb: %_tb.v
iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
#
# Generic regression test
%_check: %_tb testcode.awk
vvp $<
#
%.vcd: %_tb
vvp $<
#
# Useful for those testbenches that have a corresponding .sav file
%_view: %.vcd %.sav
gtkwave $^
#
#
#
clean:
rm -f *_tb *.vcd
</c>

Im obigen Beispiel ist eine Datei '''foo.v''' vorhanden die ein Modul von '''bar.v''' instanziiert. Die Testbench ist in der Datei '''foo_tb.v'''.

Das Projekt wird compiliert und simuliert mit dem Kommando:

<c>
> make foo_check
</c>

Vorausgesetzt das [http://home.nc.rr.com/gtkwave/ gtkwave] installiert ist, kann im Zusammenhang mit einem generierten '''foo.vcd''' Dumpfile und einem '''foo.sav''' File dieses mit folgendem Kommando aufgerufen werden:

<c>
> make foo_view
</c>

Das '''foo.vcd''' Dumpfile erhält man durch folgenden Konstrukt in der Testbench:

<verilog>
initial begin
$dumpfile("foo.vcd");
$dumpvars (0, foo_tb);
end
</verilog>

Zu diesem Aufruf des Makefile sei noch folgende Anmerkung gemacht. Der normale Aufruf von '''foo.vcd''' mit gtkwave erfolgt folgendermaßen:

<c>
> gtkwave foo.vcd
</c>

Das Kommando hätte keinen Vorteil gegenüber '''make foo_view'''. Mit gtkwave ist es nun möglich ein sogenanntes .sav File zu kreieren, in dem abgespeichert wird welche Signale in der Anzeige sind. Wenn diese Datei vorhanden ist dann muss gtkwave wie folgt aufgerufen werden:

<c>
> gtkwave foo.vcd foo.sav
</c>

Behält man nun diese Datei als Teil des Projektes, ist es möglich beim nächsten mal mit '''make foo_view''' die gleiche Ansicht wieder zu erhalten.

Das ursprüngliche Makefile von Larry Doolittle hatte noch einen Test mit [http://de.wikipedia.org/wiki/Awk awk], der das Testergebnis an das Makefile zurück gibt. Den Test habe ich herausgenommen, da der Aufwand meines Erachtens größer als der Nutzen war.

= Referenz =

== Bücher ==

* "The Verilog Hardware Description Language", Thomas & Moorby, Kluwer Academic Publisher

== Links ==

*[http://www.asic-world.com/verilog/index.html ASIC World Verilog Tutorial]
*[http://www.sunburst-design.com Cliff Cummings Verilog & System Verilog Seite]
**[http://www.sunburst-design.com/papers/ Veröffentlichungen von Cliff Cummings]

*[http://www.sutherland-hdl.com/ Sutherland HDL]
** [http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf Verilog 2001 Referenz als PDF]
** [http://www.sutherland-hdl.com/papers-by-sutherland.php Veröffentlichungen von Stuart Sutherland]

[[Category:FPGA und Co]]