Tutorial: FPGAs mit Verilog programmieren

[Micha]

Das Thema hat mich schon lange fasziniert - Klassische Hardware nicht nur emulieren, sondern als Hardware wiederbeleben. Zum ersten Mal hab ich was von dem Konzept mitbekommen, als der C-One in den Startlöchern stand. Hab grade in den letzten Tagen irgendwo gelesen dass das inzwischen 10 Jahre her ist - Schreck lass nach! Hab damals lang mir mir gekämpft ob ich so einen C-One kaufe - und es dann bleiben lassen. Dass das Ding ein "Rohrkrepierer" war wissen wir heute. Später ist man sowieso immer schlauer. Die Entwicklerin des C-One - Jery Ellsworth - ist ganz sicher ein Ausnahmetalent - sozusagen so ein Genie in Elektronik wie es W.A. Mozart in Musik war. Aber was nützt alle Genialität wenn man zur falschen Zeit am falschen Ort ist. Seufz...

Sei es drum. Zehn Jahre nach dem C-One versuch ich meine ersten Schrittchen mit einer HDL-Sprache und einem FPGA-Experimentier-Board. Falls es jemanden interessiert werd ich hier demnächst regelmäßig über meine *Fortschrittchen* berichten.

[drohne235]

Gern, das ist ein sehr spannendes Thema. Ich hab auch schon oft mit dieser Technik geliebäugelt, aber leider auch eine Allergie gegen Komplexität entwickelt: FPGA's sind weder einfach zu löten noch einfach zu programmieren. Aber das ist jetzt absolut keine Wertung, sondern reflektiert nur meine Erinnerungen an den Entwurf des Hives: ein FPGA stand da neben einer CISC-CPU (68K) neben den Props ziemlich weit oben auf der Liste.

Hab mich in dem Zusammenhang auch viel mit dem C-One und ähnlichen Projekten beschäftigt, lese auch im robotron-forum mit.

[Micha]

So, wenn ich das hier schon mal versprochen habe wirds nun aber langsam Zeit, das Versprechen auch einzulösen. Vorher habe ich noch eine Bitte: Antworten und Diskussionen bitte nicht hier in diesem Thread posten, sondern in FPGA-Diskussion. Das könnte zwar die Sachbezüge ggf. etwas sperrig machen, eröffnet aber andererseits die Chance, hier ein unterbrechungsfreies und somit besser lesbares Tutorial zu entwickeln.

Die Zeit fliegt uns allen davon, insbesondere die immer viel zu knappe Freizeit. Wenn das Wetter schön wird werde ich wohl öfter im Garten arbeiten „müssen“. Regnet es dagegen, so habe ich zumindest eine Chance Dinge auszuprobieren und hier zu posten. Also drückt die Daumen dass das ein verregneter Sommer wird - dann gibts hier öfters was neues zu lesen

Zurück zum Thema FPGA - womit fange ich da am besten an? Ich beginne mal mit der Qual der Wahl. Und das gleich im Plural. Für einen Neueinsteiger gibt es da mindestens zwei Fragen zu beantworten:
1. Welche FPGA Familie bzw. Hersteller ist das richtige für mich?
2. Welche Beschreibungs-Sprache sollte ich erlernen?

Zur ersten Frage hatte ich die Gelegenheit, einen Insider zu befragen - dessen Antwort: „das ist ungefähr so wie die Entscheidung zwischen Audi und BMW, wenn man ein Auto einer Premium-Marke haben möchte“. Hmm, schon klar wie das gemeint ist. Wenn der Hahn kräht auf dem Mist... etwas später fielen mir die Klagen meiner BMW-fahrenden Kollegen ein, die mit ihrem Hinterradantrieb bei Glatteis im Winter mehr schlittern als fahren...

Die bekanntesten Hersteller sind im Fall FPGA Xilinx und Altera. Ich hatte mich mehr zufällig für letzteren entschieden. Positive Erkenntnis seitdem: die preiswerten Altera Testboards haben SRAM an Bord, was durchaus ein „pro“ Argument sein könnte.

Überhaupt, „Testboards“, dazu sollte ich gleich mal paar Dinge sagen: FPGAs sind leider kaum was zum Hardware-Basteln, Die Dinger haben typischerweise hunderte von I/O Beinchen, da steht man als Bastler mit zweilagigen Platinen und Lötfähigkeiten im DIP Bereich ziemlich im Regen
Dafür bekommt man für 70 Euro aufwärts Testboards in Postkartengröße - bzw. für Hive‘ianer wahrscheinlich anschaulicher: in Größe der Hive-Platine. Und auf so ner Platine sind praktisch alle Zutaten für einen Computer drauf - natürlich der FPGA-Zauberchip, ausserdem RAM, Flash, diverse Taster, Schalter, LEDs, Displays, SD-Card Adapter, PS/2, RS232, ein Piezo-Piepser, VGA. Bestimmt hab ich jetzt irgendwas vergessen. Bei Rudi Carrell gabs früher immer noch ein „Fragezeichen“
Ich hab mir ein Noname Board aus China mit einem Altera Chip auf Ebay gekauft, für 69 Euro. Kurz darauf die Erkenntnis: dazu braucht man auch einen passenden Programmer. Der hat dann nochmal ca. 15 Euro gekostet. Zur groben Orientierung: das auf robotrontechnik.de derzeit vieldiskutierte Z1013 Projekt verbraucht in der aktuellen Ausbaustufe von den ca. 8000 vorhandenen Logikelementen (LE) meines FPGA ca. 2500 Stück.
Für etwa 150 Euro bekommt man das offizielle DE1 Board von Altera. Da ist bei ansonsten ähnlicher Ausstattung ein FPGA mit 20000 LE drauf. Nach meinem heutigen Kenntnisstand würde ich diesem Board wohl den Vorzug geben, da es eine Art „Quasistandard“ für Hobbyprojekte ist. Weiterer Pluspunkt: der Programmer ist bereits auf dem Board integriert, den muss man also nicht extra kaufen. Eines muss man ehrlicherweise auch sagen: um die Portabilität von FPGA-Projekten ist es nicht allzu gut bestellt. Bei komplexeren Projekten wird viel auf gekapselte Komponenten des jeweiligen Herstellers gesetzt. Und selbst beim gleichen Hersteller haben unterschiedliche FPGA Modelle oft verschiedene Pin-Belegungen.

So, jetzt poste ich diesen Beitrag erst mal. Bin zwar noch nicht fertig mit der Einleitung, aber bevor das hier zur monolithischen Bleiwüste entartet...

[Micha]

Frage 2: welche Beschreibungssprache ist die richtige für mich? Im Fachjargon heissen die Dinger übrigens HDL = Hardware Description Language.

*Eigentlich* muss man garnicht mit sowas anfangen. In der Entwicklungsumgebung die ich derzeit verwende (Quartus II Web Edition des Herstellers Altera) gibt es eine Bibliothek mit einer gefühlten Menge von Hunderten 74xx Logikschaltkreis-Typen. Damit könnte sich der Freund der klassischen digitalen Kuchenbleche so richtig auf dem FPGA austoben - ganz ohne eine Hochsprache lernen zu müssen ...
Allerdings teilen einem praktisch alle Tutorials und Lehrbücher zum Thema FPGA mit, dass diese Art von Design nicht mehr zeitgemäß weil uneffektiv ist. Mit einer HDL kann man komplexe Entwürfe wesentlich effektiver beschreiben. Also zurück zu den HDLs:

Es gibt einige dieser Beschreibungssprachen, die zwei „Platzhirsche“ sind VHDL und Verilog. VHDL ist eine strikte und dementsprechend sperrige Beschreibungssprache, die an Universitäten bevorzugt gelehrt wird. Verilog gilt dagegen als die „hemdsärmelige“ Sprache mit Entwicklungshintergrund aus der Industrie (speziell USA - wo es sowieso etwas hemdsärmeliger zugeht, was aber nicht schlecht sein muss). Öfters wird der Vergleich VHDL vs. Verilog mit der Metapher Pascal vs. C beschrieben. Pascal ist „strenger“, aber man hat als Pascal-Programmierer eben auch mehr Schreibkram am Halse. Die Anhänger beider Lager behaupten immer mal, dass die jeweils andere Sprache demnächst aussterben wird.

„Drohne 235“ hatte in Garitz eine ganz pragmatische Interpretation zur Wahl der Sprache: erst mal umschauen nach Projekten die einen interessieren - in welcher Sprache sind die vorzugsweise geschrieben? Dann entscheiden was man lernt. Gute Idee, aber in dem Fall für mich schon zu spät. Ich hatte mich bereits für Verilog entschieden und ein Lehrbuch dazu erworben. *Angeblich* ist die Lernkurve bei Verilog steiler im Vergleich zu VHDL. Muss allerdings gestehen mir fehlt die eigene Erfahrung um das einschätzen zu können.
Die jungen, kreativen Entwickler denen man so über den Weg läuft haben wahrscheinlich an einer Uni VHDL gelernt - im Fall des Z1013 sind wohl "ad fontes", "abnoname" und "bert" alles VHDL-guys. Da steh ich jetzt mit meiner Entscheidung für Verilog zwar etwas abseits, andererseits bietet mir das die Chance, die Dinge von der Pike auf zu lernen

Genug der Vorrede. Jetzt wirds langsam mal Zeit für praktische Beispiele wie das Ganze funktioniert. Demnächst in diesem Kino - äääh Thread: der wohl aufwendigste Draht im Universum. Bleiben Sie uns treu...

[Micha]

Eines der denkbar einfachsten Elektronik-Experimente:
man nehme eine Spannungsquelle, einen Taster, eine Leuchdiode mit Vorwiderstand(!). Wenn man die Sachen korrekt zusammenschaltet, geht einem bei Betätigung des Tasters ein Lichtlein auf. Sozusagen das "Hello World" der Elektronikbastelei.

Auf dem typischen FPGA Testboard sind sämtliche Zutaten für dieses simple Experiment vorhanden. Lediglich mit der Verdrahtung hapert es zunächst. Auf der einen Seite geht die Leiterbahn vom Taster in den FPGA Chip, auf der anderen Seite geht es von einem anderen Pin zur LED. Nur dazwischen ist erst mal nichts. Also warum nicht einfach eine Strippe quer durch den FPGA Chip programmieren? So eine Strippe nennt sich auf Englisch "wire" und ist nebenbei auch ein Keyword in Verilog, dazu gleich mehr.

OT: "wired" heisst auf Englisch "verdrahtet", "weird" bedeutet dagegen "verwirrt". "a weird backplane" ist somit eine wirre Rückverdrahtung

Genug der Vorrede, hier kommt endlich das erste Codebeispiel:

Code: Alles auswählen

// Beispiel 1: einfache Taster - LED Schaltung
module main (
 input  wire Key,
 output wire Led
);

 assign Led = Key;

endmodule

Ein Verilog Projekt muss mindestens ein module enthalten, das die Definition eines Hardwareblocks darstellt. Die Namenswahl main ist hier willkürlich, im Gegensatz zu C ist dieser Name nicht Pflicht für die Hauptinstanz. Wenn das Projekt nur ein Modul enthält ist dieses die Hauptinstanz, der Name ist dabei egal. Komplexere Projekte enthalten typischerweise mehrere Module. Als Hauptmodul gilt dann dasjenige, welches in der Modulhierarchie an oberster Stelle steht. Dazu später mehr.
Die assign Zuweisung verbindet einen logischen Ausdruck dauerhaft auf einen "Draht" der auf der linken Seite der Zuweisung steht. Damit wird hier vom Taster zur LED die "Verdrahtung" hergestellt.

Dummerweise schaltet der Taster auf meinem Board auf Masse, die LED geht ebenfalls auf Masse. Damit ergibt sich mit dem obigen Code das "verkehrte" Verhalten, dass die LED leuchtet, solange der Taster nicht gedrückt wird und erlischt, solange man den Taster drückt. Das lässt sich mit einem einfachen Zaubertrick umkehren, indem man die assign Anweisung so schreibt:

Code: Alles auswählen

  assign Led = ~Key;

Ein Draht mit invertierender Wirkung, ist doch cool, oder? Der Operator ~ steht in Verilog (wie auch in C) für bitweises Invertieren. Falls es nur ein Bit bzw. ein Signal zu invertieren gibt, bewirken der bitweise Invertierer ~ sowie der logische Invertierer ! genau das gleiche. In diesem Sonderfall verkommt es zu einer weltanschaulichen Frage, welchem der beiden Operatoren man den Vorzug gibt...

[unick59]

Hallo Micha,
soweit klar, aber...:
Nun hat der FPGA ja viele Pins, denen man doch bestimmt erst mal sagen muss, ob sie Mänchen oder Weibchen oder Zwitter sind. Also ob Input oder Output etc. Und woher weiss der FPGA an welchen Pin der Taster bzw. die LEd ist?

[Micha]

Das ist eine berechtigte Frage. In der Portdeklaration eines Moduls muss per Schlüsselwort (input, output oder inout) festgelegt werden, welche Richtung Signalen zugeordnet wird, siehe Beispiel. Das ist also Bestandteil der Beschreibungssprache.

Die Zuordnung zu konkreten Pins ist dagegen nicht Bestandteil der Sprache sondern wird in der Entwicklungsumgebung per Editor erledigt. In meinem Fall ist in der "Quartus II" Software von Altera ein "Pin Planner" enthalten, siehe Foto. Dort muss man die Zuordnung eintragen. Die dafür benötigten Informationen gibts aus dem Schaltplan des Boardherstellers, siehe zweiten Anhang. Das Umarbeiten der Pin-Zuordnung ist ne lästige Sache bei der Übertragung eines Projekts auf einen anderen FPGA oder ein anderes Board.

In Garitz hab ich gelernt, dass es auf Dauer effektiv ist, sich für sein Board einmal eine komplette Pinzuordnung zu erstellen. Die kann man dann beispielsweise als .csv Datei exportieren und in jedes künftige Projekt importieren.

Ebenfalls nicht Bestandteil der Sprache Verilog sondern Projekteinstellung in der Entwicklungsumgebung ist die Festlegung zu den ungenutzten Pins. Bei meinem allerersten Versuch war die Voreinstellung "as output driving ground". Das hat das unterdimensionierte China-Billignetzteil ziemlich genau eine Minute überlebt. Seitdem stelle ich die ungenutzten Pins immer "as input with weak pull up resistor" ein.

Bitte an den Admin oder Mod: könnt ihr Frage und Antwort in den Diskussions-Thread verschieben?

[Micha]

So, nachdem ich als erstes ein ziemlich primitives Beispiel gezeigt habe dachte ich mir ich bringe als nächstes ein Beispiel, das nicht richtig funktioniert.

Im ersten Beispiel gab es eine Reaktion genau solange der Taster gedrückt wurde. Könnte man dieses Beispiel so umfriemeln, dass durch Betätigen des Tasters die LED abwechselnd ein- und ausschaltet, also Nachttischlampen-Prinzip? Klar geht das - sonst hätte ich die Frage nicht gestellt
Allerdings kommen wir mit wire(s) nicht mehr weiter, die können nur Signale durchreichen. Was wir jetzt benötigen ist ein Speicher, der sich den Zustand der "Nachttischlampe", also EIN bzw. AUS merken kann. Das leistet in Verilog der Datentyp reg was für Register steht. Und so sieht der Code aus:

Code: Alles auswählen

// Beispiel 2: Nachttischlampen-Prinzip
// logisch korrekt, funktioniert aber nicht zufriedenstellend

module main (
 input wire Key,
 output reg Led
);

 always @ (negedge Key) Led <= ~Led;

endmodule

Der Code ist immer noch sehr überschaubar, auf den ersten Blick fast genauso wie Beispiel 1. Der Ausgang ist hier als reg definiert, was ihm Speicherfähigkeit verleiht. Im Rumpf des Moduls ist die assign Zeile verschwunden. Diese Art dauerhafter Zuweisung ist nur für Variablen vom Typ wire zulässig. Da wir jetzt ein Register haben, funktioniert das etwas anders - Register müssen in ereignisgetriggerten always Blöcken zugewiesen werden. Im konkreten Fall ist eine negative Flanke des Taster-Signals der Auslöser. Wenn dieses Ereignis eintritt wird der Inhalt des Led Registers invertiert. Der schaltet also beim Drücken des Tasters jedes Mal zwischen 1 und 0 um, da die gesamte Logik im FPGA binär ist.

Eigentlich sieht das alles astrein logisch und korrekt aus. Beim Ausprobieren wird man feststellen, dass es nur sporadisch so funktioniert wie es soll. Die alten Hasen werden jetzt müde abwinken: jaja, der Taster ist nicht entprellt, gähn...
Was es damit auf sich hat, und wie man dieses Problem in den Griff bekommt ... erfahren Sie gleich nach der Werbung

[Micha]

Prellende Tasten bzw. deren Entprellung - das Thema hat sooooooo nen Bart. Jeder Elektroniker weiss was gemeint ist - das Gezappel an den Signalflanken, wenn eine Taste gedrückt oder losgelassen wird. Übelster Urschleim, Problem seit ewig bekannt, Lösungen ebenso. Trotzdem soll es immer mal wieder dem einen oder anderen Bastler passieren, dass er zu optimistisch an das Thema herangeht und bei der Inbetriebnahme einer Schaltung feststellen muss dass die Dinge nicht so machen wie sie sollen. Kommt gelegentlich auch mal bei Konsumgütern vor - ich hatte mal eine Digitalkamera, deren Ein/Aus-Taster ein Alptraum war...
Lösungen gibt es als Hardware (wird selten so gemacht) und als Software - ein Mikrocontroller erledigt sowas ganz locker nebenbei, so wird's dann meist auch gemacht, aus Kostengründen. Bei der hier vorgestellten Lösung kann man sich streiten - sieht wie Software aus, ist aber dann im FPGA eigentlich Hardware. Darüber ob FPGA Zeugs nun Hardware oder Software ist, streiten sich sowieso die Geister, ich mag mich an diesem Streit mangels klarer Definitionen nicht beteiligen.

Das Modul zum Entprellen habe ich von der Website http://www.fpga4fun.com gemopst. Ich sag immer "besser gut geklaut als schlecht selber ausgedacht". Hier ist erst mal der neue Code, Erklärungen folgen:

Code: Alles auswählen

// Beispiel 3: Ein/Aus-Taster, 
// diesmal entprellt 

module main (
 input  wire CLK_in,
 input  wire Key_in,
 output reg  LED_out
);

 wire Key1;
 
 PushButton_Debouncer Entpreller1 (.clk(CLK_in), .PB(Key_in), .PB_state(Key1));
 always @ (posedge Key1) LED_out <= ~LED_out;

endmodule 

// ***** Ende Hauptmodul *****

// folgender Code wurde aus einem Beispiel auf www.fpga4fun.com entnommen:

module PushButton_Debouncer(
    input clk,
    input PB,  // "PB" is the glitchy, asynchronous to clk, active low push-button signal

    // from which we make three outputs, all synchronous to the clock
    output reg PB_state,  // 1 as long as the push-button is active (down)
    output PB_down,  // 1 for one clock cycle when the push-button goes down (i.e. just pushed)
    output PB_up   // 1 for one clock cycle when the push-button goes up (i.e. just released)
);

// First use two flip-flops to synchronize the PB signal the "clk" clock domain
reg PB_sync_0;  always @(posedge clk) PB_sync_0 <= ~PB;  // invert PB to make PB_sync_0 active high
reg PB_sync_1;  always @(posedge clk) PB_sync_1 <= PB_sync_0;

// Next declare a 16-bits counter
reg [15:0] PB_cnt;

// When the push-button is pushed or released, we increment the counter
// The counter has to be maxed out before we decide that the push-button state has changed

wire PB_idle = (PB_state==PB_sync_1);
wire PB_cnt_max = &PB_cnt;	// true when all bits of PB_cnt are 1's

always @(posedge clk)
if(PB_idle)
    PB_cnt <= 0;  // nothing's going on
else
begin
    PB_cnt <= PB_cnt + 16'd1;  // something's going on, increment the counter
    if(PB_cnt_max) PB_state <= ~PB_state;  // if the counter is maxed out, PB changed!
end

assign PB_down = ~PB_idle & PB_cnt_max & ~PB_state;
assign PB_up   = ~PB_idle & PB_cnt_max &  PB_state;
endmodule

Falls der Inhalt des Moduls PushButton_Debouncer derzeit noch rätselhaft erscheint, am besten zunächst ignoriern. Erklärungen und Beispiele zu den dort verwendeten Techniken folgen später. Hier geht es zunächst mal um das Einbinden fertiger Module.

Im Hauptmodul wird eine Instanz namens Entpreller1 des Moduls PushButton_Debouncer angelegt. Daran erkennt der Compiler übrigens, wer der Chef ist: dasjenige Modul, von dem keine Instanzen erzeugt werden wird als Hauptmodul, als "oberste Ebene" des Projekts angesehen. Der hier verwendete Modulname main hat (im Gegensatz zu C) keine deklarative Bedeutung. Ich hab den rein willkürlich bzw. aus Gewohnheit gewählt.

Die Portübergabe zwischen Hauptmodul und der Instanz des Debouncers erfolgt im Beispiel durch benannte Ports. Wenn man es so macht ist die Reihenfolge dann egal, man kann sogar Ports weglassen falls diese nicht benötigt werden. Im Beipiel werden die beiden Ports PB_down und PB_up nicht verwertet.

Alternativ zur Portübergabe per Name ist in Verilog auch die Portübergabe per Reihenfolge möglich, so wie man das von "klassischen" Programmiersprachen kennt. Davon wird allerdings abgeraten, da Module bei "echten" Projekten schnell unüberschaubar viele Ports haben können.

Das Debouncer-Modul kann man als eine Art Filter sehen, das aus dem "schmutzigen" Signal Key das "saubere" Signal Key1 macht zur weiteren Verwendung. Gelernte Programmierer der alten Schule werden sich vielleicht fragen - wieviel Performance nimmt das weg? Die Antwort ist erfreulich: keine! Da es hier um Hardware geht, wühlt jenes Modul selbstständig vor sich hin, ohne unserem super-Lichtumschalter Performance zu stehlen. Die Freunde des Hive bzw. des Propeller haben da sicher eher ein Verständnis

Vielleicht ist jemandem aufgefallen, dass in diesem Beispiel zum ersten Mal eine "Clock" auftaucht. Die ersten zwei Beispiele haben gezeigt, dass es im Prinzip auch ohne geht. Allerdings ist bei komplexeren FPGA Designs fast immer eine (manchmal sogar mehrere) Clocks mit im Spiel. Auf altdeutsch Taktgeber.

Eventuell fällt auf, dass im Hauptmodul in der always Anweisung jetzt auf die positive Flanke "posedge" des Tasters reagiert wird. Das rühert daher, dass die direkte Hardware-Taste am FPGA (in Beispiel 2 verwendet) low-aktiv ist. Der Debouncer dreht allerdings die Polarität um, so dass das gefilterte Taster-Signal high-aktiv ist. Während man es bei konventioneller Logik oft mit low-aktiven Signalen zu tun hat gibt es im Innern von FPGA keinen triftigen Grund, so zu designen. Modelle mit high aktiven Signalen sind besser zu lesen und deshalb üblich.

[Micha]

Bevor es ans nächste Projekt geht zwischendurch mal ein paar kurze Bemerkungen zur Sprache Verilog. Ursprünglich Mitte der 1980er Jahre als proprietäres Entwicklungswerkzeug erdacht, dauerte es ca. 10 Jahre, bis daraus eine standardisierte Sprache wurde. 1995 wurde ein offizieller IEEE Standard verabschiedet, der Verilog-1995 beschreibt. In den folgenden Jahren wurden einige Unzulänglichkeiten offensichtlich, so dass 2001 nochmal ein IEEE Standard nachgelegt wurde, entsprechender Name der Sprachversion: Verilog-2001. Seither ging die Entwicklung zwar weiter, aber die Ergänzungen durch neuere Standards waren minimal. Man kann Verilog-2001 auch heute noch mit gutem Gewissen als die "Hauptversion" bezeichnen. Allerdings findet man im Web oft auch Codebeispiele, die in Verilog-1995 Syntax geschrieben sind. Man erkennt sie auf den ersten Blick an der sperrigen Art, die Ports zu beschreiben:

Code: Alles auswählen

// Codeschnipsel in Verilog-1995 Syntax
module murks ( A, B, C);
 input A;
 input B;
 output C;
 
 // irgendwelcher Murks

endmodule

Die Deklaration der Ports und die Definition der Datenrichtung war in Verilog-1995 getrennt. In Verilog-2001 kann man das kompakter schreiben:

Code: Alles auswählen

// Codeschnipsel in Verilog-2001 Syntax
module murks ( input A, input B, output C);

 // irgendwelcher Murks

endmodule

Wenn einem Port kein Typ zugeordnet wird (reg oder wire) ist es implizit immer ein wire. Es ist allerdings nicht verboten, das Schlüsselwort wire auszuschreiben. Moderne Verilog Compiler kommen sowohl mit der 1995er als auch mit der 2001er Syntax zurecht.