Mikrocontroller.net - Benutzerbeiträge [de]

Eisenwarenversender

2010-01-04T20:48:17Z

Blackhat-blade:

== Einleitung ==
Dies wird eine Auflistung im Stil von [[Elektronikversender]].

Diese Liste erhebt keinerlei Anspruch auf Vollständigkeit. Wenn ihr einen Versender kennt, der hier noch nicht aufgeführt ist, dann fügt ihn einfach ein (alphabetische Sortierung). Den Rest können auch andere besorgen, die den Versender ebenfalls kennen.

== Liste der Versender ==

=== Alu-Verkauf.de ===
Homepage: http://www.alu-verkauf.de/
* Alu und Kupfer
* Versand bis 5 kg 6€

=== B&T Metall- u. Kunststoffhandel ===
Homepage: http://www.metall-kunststoffhandel.de/shop/index.php
* Versand bis 2 kg 5€ zzgl. MwSt.

=== Feld Maschinenbau ===

Homepage: http://www.mein-stahlshop.de/

*Bleche im Zuschnitt (Kupfer, Alu, Eisen, Edelstahl)
*Profile
*Versand ab 5,60€
*Relativ schnell

=== inox-schrauben.de ===
Homepage: http://www.inox-schrauben.de
* Edelstahl-Schrauben und Werkzeug
* Versand 6€
* keine Mindestbestellmenge

=== Metallstore ===
Homepage: http://metallstore.de/
* Halbzeuge & Lineartechnik
* Mindestbestellmenge 60€ sonst 18€ Mindermengenzuschlag
* Versand 8€??

=== metal made 4 you ===
Homepage: http://www.mm4u.de/
* Maßanfertigung von Blechteilen

=== Modellbauershop ===
Homepage: http://www.modellbauershop.de/
* sehr kleine Schrauben, Muttern, Scheiben, Nieten, Zahnräder, etc
* Versand ab 2,20€

=== SCREWS & MORE ===
Homepage: http://www.screwsandmore.de/
* Hauptsächlich Schrauben, davon aber alle Variationen
* Versand 4,50 €

== Siehe auch ==
* [[Elektronikversender]]
* [[Platinenhersteller]]
* [[Lokale Elektroniklieferanten]]

== Links ==
* http://www.xs4all.nl/~ganswijk/chipdir/ Suche nach integrierten Schaltkreisen
* http://www.alldatasheet.com Datenblätter

[[Kategorie:Bauteile|!]]

Lötkolben

2009-12-14T15:07:30Z

Blackhat-blade: Änderung 41390 von 79.193.220.140 (Diskussion) wurde rückgängig gemacht.

[[Category:Löten]]
Der Lötkolben ist das zur manuellen Erstellung von Lötverbindungen vorwiegend benutzte Werkzeug.

Da im professionellen Bereich sowie unter erfahrenen Elektronikern das entsprechende Know-How sicher vorhanden ist, wendet sich diese Seite in erster Linie an Hobbyisten und andere Einsteiger, etwa solche, die als ehemalige "reine" Software-Entwickler nun im hardwarenahen Bereich ihre ersten Schritte mit Mikrocontroller-Aufbauten machen möchten.

== Arten von Lötkolben ==

Um elektronische Schaltungen erfolgreich aufzubauen, sollte man zunächst wissen, welche Arten von Lötkolben es gibt, und wozu sie geeignet sind.

=== Lötnadeln (ca. 5 bis 10 Watt) ===

Diese "Miniatur-Lötkolben" sind nur für feinste Arbeiten, bei denen man oft auch eine Lupe einsetzen wird, sinnvoll. Beispiele dafür sind:
* Anlöten extrem dünner Drähte, z. B. solche aus der "Wire-Wrap"-Wickeltechnik;
* Korrektur- und Nachlötungen bei beengten Verhältnissen, z. B. an SMD-Bauteilen;
* Reparatur schmaler Leiterbahnen mit einem Haarriss (oder vorsorgliches Verzinnen beim Verdacht auf einen solchen).

Lötnadeln werden häufig mit Niederspannung versorgt (z. B. 12 Volt) und können daher mit Hilfe eines einstellbaren Netzteils auch mit etwas Unter- oder Übertemperatur betrieben werden. Generell sind sie aber eher ein Werkzeug für den "fortgeschrittenen" (Hobby-) Elektroniker und nicht so gut geeignet, um überhaupt erst einmal Übung im Löten zu bekommen.

=== Feinlötkolben (ca. 15 bis 20 Watt) ===
Diese kleinen, leichten Lötkolben kommen zum Einsatz, wenn es um die Bestückung von Platinen oder das An- und Ablöten dünner Drähte und Litzen geht. Lediglich für das Herstellen von Verbindungen, über die später stärkere Ströme (im Bereich einiger Ampere) fließen sollen, also z. B. zum Auflöten einer Litze höheren Querschnitts auf eine größere Kupferfläche sind sie etwas schwach. Für Anfänger, die wenig Geld ausgeben wollen, sind Feinlötkolben am ehesten zu empfehlen.

Auch diese Art von Lötkolben gibt es für Niederspannung. Man braucht dann zwar zum Betrieb ein entsprechendes Netzteil, kann dafür aber (bei einstellbarer Ausgangsspannung des Netzteils) die Leistung des Lötkolbens innerhalb gewisser Grenzen variieren.

=== Elektronik-Universallötkolben (ca. 30 Watt) ===
Sie sind das "Standardwerkzeug" des Elektronikers, aber für alle, die hauptsächlich Schaltungsaufbauten im Bereich Mikrocontroller erstellen, fast schon unnötig groß. Ausgestattet mit unterschiedlichen Lötspitzen (siehe unten) sind Lötkolben dieser Klasse für viele Arbeiten geeignet, wenn auch meist etwas unhandlicher als Feinlötkolben.

Auszunehmen sind lediglich die oben unter "Lötnadel" beschriebenen Arbeiten - es sei denn man hat wirklich großes Geschick und eine sehr ruhige Hand. Am anderen Ende der Skala denkbarer Arbeiten wird man sich allenfalls für das zügige An- und Ablöten sehr dicker Drähte oder Litzen auf/von massiven Metallteilen manchmal mehr Leistungsreserve wünschen, kommt in der Regel aber auch mit einem 30 Watt Lötkolben zum Erfolg.

Da solche Lötkolben typischerweise an 230 Volt betrieben werden, erübrigt sich auch ein eigenes Netzteil (bzw. man kann die Spannung seines Labor-Netzteils stets für den Versuchsaufbau passend eingestellt lassen), auf der anderen Seite entfällt damit die Möglichkeit, die Leistung des Lötkolbens in einem gewissen Umfang zu variieren.

=== Temperaturgeregelte Lötkolben (ca. 60 Watt) ===
"Mehr" ist nicht immer automatisch "besser", und so ist eine höhere Leistung bei Lötkolben problematisch, weil der Lötkolben "im Leerlauf" oder bei kleineren Lötstellen zu heiß werden kann. Aus diesem Grund sollte man in der Leistungsklasse oberhalb 30 Watt besser gleich in einen temperaturgeregelten Lötkolben investieren. Zwar sind diese deutlich teurer als Lötkolben der ersten drei Kategorien, aber zerstörte Bauteile oder verdorbene Platinen verursachen auf Dauer noch höhere Kosten und sind auf jeden Fall ärgerlich.

Ein weiterer Vorteil der Investition in einen solchen Lötkolben ist, dass sich damit auch schon mal kleinere Reparaturarbeiten außerhalb des Elektronikbereichs durchführen lassen (etwa Spielzeug etc.).

Fuer den Einstieg reicht die "Analog 60" oder Weller "Temptronic" allemal:

Analog 60
+ Betrieb direkt aus dem soliden Blechkoffer heraus
+ heisse Lötspitze mit Zange problemlos wechselbar (ein Handgriff)
- Regelung teilweise hörbar (leises Klacken)

Weller Temptronic
+
- um eine heiße Loetspitze zu wechseln muss erst das Röhrchen vom Thermoelement entfernt werden und dann die Spitze. Vorsicht alles heiss

siehe: http://www.mikrocontroller.net/forum/read-1-369049.html#new

=== Große Lötkolben (über 60 Watt) ===
Diese sind in der Regel kein Werkzeug für den Elektroniker - es sei denn man denkt an das Verlöten von Metallgehäusen zur Abschirmung oder an das Löten von Akkus oder Solarzellen - und eher für allgemeine Reparaturen im Haushalt geeignet. Aber wenn man durch die Beschäftigung mit der Elektronik schon mal "das Löten gelernt hat", will man diese Fähigkeiten vielleicht auch anderweitig einsetzen...ij

== Arten von Lötspitzen ==
Bei den meisten Lötkolben kann die eigentliche Lötspitze ausgwechselt werden. Dies ist zum einen erforderlich, weil sich die Spitze im Lauf der Zeit abnutzt (was aber je nach Nutzungshäufigkeit des Lötkolbens und Materialqualität der Spitze Jahre dauern kann). Zum anderen wird man insbesondere bei stärkeren Lötkolben abhängig von der Arbeit, die man durchführen möchte, unterschiedlich geformte Spitzen benötigen.

=== Kegelförmig ===
Leicht kegelförmige Spitzen, die vorne in einer Halbkugel (Durchmesser meist unter 1 mm) auslaufen, eignen sich besonders für "beengte Verhältnisse", also nahe beieinander liegende Pins, geringen Leiterbahnabstand usw. Das Problem solcher Spitzen bei anderen Arbeiten ist, dass die Kontaktfläche zu den zu verlötenden Teilen recht gering ist. Da beim Löten - wie unter "[[Löten (praktisch)]]" ausgeführt - stets die zu verlötenden Teile und nicht das Lötzinn erwärmt werden sollte, kann das Herstellen größerer Lötverbindungen mit solchen Spitzen länger als nötig dauern. Die Folge können durch Hitze zerstörte Bauteile sein (wenn die Spitze so gehalten wurde, dass vor allem das Bauteil, nicht aber die Leiterbahn erwärmt wurde) oder sich ablösende Leiterbahnen (im umgekehrten Fall).

=== Breit und Flach ===
Mit diesen, etwa nach der Art eines Schraubendrehers (aka. "Schraubenzieher" - aber nicht nach DIN! :-)) geformten Lötspitzen lässt sich je nach dem, wie man sie ansetzt, ein größerer oder kleinerer Kontakt zu den zu verlötenden Teilen herstellen. Unter beengten Verhältnissen ist aber, selbst wenn man sie "hochkant" hält, die Gefahr gegeben, Lötzinn an Stellen zu verschmieren, wo es nicht hingehört und z.B. zu einem Kurzschluss führt.

=== Zylindrisch/Angeschrägt ===
Es ist sicher auch eine Geschmacks- und Übungssache, aber Spitzen, die eine zylindrische Grundform haben (Durchmesser etwa 1,5..2,5 mm) und vorne im Winkel von ca. 45 Grad angeschnitten sind, bieten eine überraschend große Bandbreite von Einsatzmöglichkeiten. Insbesondere für etwas "faule" und "ungeduldige" Naturen, die nicht dauernd zwischen den verschiedenen Lötspitzen ihres Lötkolbens wechseln wollen, sind solche Spitzen günstig. Aufgrund der Asymmetrie findet man ferner - etwas Übung vorausgesetzt - mit solchen Spitzen fast immer einen Ansatzpunkt, der es erlaubt, die beiden zu verlötenden Teile gleichmäßig schnell zu erwärmen. (Achtung: Gleichmäßig bedeutet hier vor allem, dass man ggf. das Teil mit der geringeren thermischen Masse, das sich also ''schneller'' erwärmen wird, auch nur mit der ''kleineren'' Fläche der Spitze in Kontakt bringen wird!)

=== Abgewinkelt vs. Gerade ===
Auch hier mag Erfahrung, Übung und Geschick eine Rolle spielen, aber im Bereich der (Fein-) Elektronik werden meist gerade Spitzen bevorzugt. Insbesondere beim Löten auf gedruckten Schaltungen erlaubt die "bleistiftähnliche" Haltung eines Lötkolbens mit gerader Spitze eine präzisere Positionierung.

=== Spezielle Spitzen ===
Für temperaturgeregelte Lötkolben gibt es als Sonderzubehör meist spezielle Lötspitzen zum Entlöten, z.B. solche, die sämtliche Pins eines ICs auf einmal erhitzen, oder Spitzen mit einer Bohrung im Inneren und einem aufgesetzten Gummiball, durch die man Lötzinn absaugen kann.

== Noch etwas "Theorie" ==
An dieser Stelle noch einmal kurz zum Einfluss von Leistung und Temperatur auf das Lötergebnis.

=== Einfluss der Leistung ===
Ein Lötkolben höherer Leistung ist vor allem dann angebracht, wenn größere Metallteile (z.B. großflächige Masse-Leiterbahnen) erwärmt werden müssen. Dass ein Lötkolben für eine bestimmte Arbeit "deutlich zu schwach" ist, merkt man daran, dass die Lötspitze nach dem ersten Aufsetzen kurz "anklebt", weil die große kalte Fläche das an der Spitze des Lötkolbens hängende, geschmolzene Lötzinn wieder fest werden lässt.

Bei ungeregelten Lötkolben wird hier zusätzlich die "thermische Masse" der Lötspitze ins Spiel kommen, d.h. mit einer massiven Spitze, die selbst sehr viel mehr Wärme speichert als die zu verlötenden Teile, wird sich dieser Effekt kaum einstellen, mit der dünnen Spitze einer sehr feinen Lötnadel schon eher. Bei einem Niederspannungslötkolben, den man über ein einstellbares Netzteil betreibt, kann man in diesem Fall über die Spannung die Leistung etwas erhöhen. Aber Achtung: Der Zusammenhang ist nicht linear, 10% mehr Spannung sind rund 21% mehr Leistung, 20% mehr Spannung rund 45% mehr Leistung(*1,*2).

=== Einfluss der Temperatur ===
Bekanntlich vertragen Halbleiterbauteile es nicht, wenn sie zu heiß werden. Das gilt nicht nur für die Wärme, die sie im laufenden Betrieb selbst entwickeln, sondern auch für die Erhitzung ihrer Anschlussdrähte oder -pins beim Löten.

Ein Fehlschluss wäre es nun aber anzunehmen, dass man durch eine geringere Temperatur des Lötkolbens dieser Gefahr vorbeugen könnte. Bis die über einen Draht oder Pin zugeführte Wärme das Innere des Bauteils erreicht (wo die hohe Temperatur ihre schädlichen Auswirkungen entfaltet), vergehen einige Sekunden. Braucht man aufgrund verringerter Temperatur nun für den gesamten Lötvorgang doppelt oder dreimal so lang, wird dies die Gefahr für das Halbleiterbauelement sogar erhöhen - ob die Lötspitze dann eine Temperatur 350 Grad oder "nur" 280 Grad hat, ändert nicht viel. Merke: Weniger die geringe Temperatur als ein zügiger Lötvorgang sollte das Ziel sein! (Allerdings wird sich bei zu hoher Temperatur das Flussmittel im Lötzinn möglicherweise verflüchtigen, ohne ausreichend Wirkung entfaltet zu haben!)

----
* 1: Wieviel Mehrleistung man dem Lötkolben zumuten darf, bevor er kaputt geht, ist schwer zu sagen. Der Autor dieser Zeilen verwendet seit über 30 Jahren für die meisten seiner Aufbauten einen Lötkolben von 12 Watt, der "offiziell" mit 6 Volt zu betreiben ist. Tatsächlich wird der Lötkolben aber je nach Bedarf mit 5, 6 oder 7 Volt betrieben, entsprechend einer Mehr- und Minderleistung von etwa 30%.

* 2: Obacht bei solchen Rechnungen: Das Heizelement eines Lötkolbens dürfte einen erheblichen positiven Temperaturkoeffizienten haben, der den Einfluss der Betriebsspannung auf die Leistung deutlich reduziert.

Verilog

2009-12-02T11:53:03Z

Blackhat-blade:

= 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 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]]

Wer hat was

2009-10-27T20:58:01Z

Blackhat-blade:

Wer hat was und wo? :)
http://www.mikrocontroller.net/topic/155083
Erstmal sollen sich hier nur Mitmachwillige ihren Wohnort aufschreiben, um zu sehen ob die Sache lohnt. Also fang ich an:

*volatile, Oldenburg, AVRs, RC 0805 und 0603 usw usw bla
*deadbuglabs, Nürnberg, Atmega: m8, m328P, m168, m32, RC bedrahtet + SMD
*blackhat-blade, Karlsruhe: Widerstände THT (E12 ~1R - 1M), AVRs, Trafos, 1Nxxx Dioden, diverses

Entprellung

2009-10-19T18:03:52Z

Blackhat-blade: typos

Mechanische Schalter prellen beim Ein- und Ausschalten, d.h sie schalten schnell aus und ein, verursacht durch mechanisches Vibrationen des Schaltkontaktes. Vereinfacht dargestellt sieht eine von einem Schalter oder Taster geschaltete Spannung beim Schalten wie folgt aus:

[[Bild:Entprellen.png]]

Für die Auswertung dieses unsauberen Signals gibt es verschiedene Ansätze:

== Hardwareentprellung ==

===Wechselschalter===

Für die Entprellung von Wechselschaltern (engl. Double Throw Switch) kann ein klassisches RS-[[FlipFlop]] genutzt werden. Bei dieser Variante werden neben zwei NAND-Gattern nur noch zwei Pull-Up Widerstände benötigt.

[[Bild:NAND_debouncer.png|framed|left|'''Taster entprellen mit NAND-RS-FlipFlop''']]

 

In der gezeigten Schalterstellung liegt an der Position /S der Pegel 0 an. Damit ist das FlipFlop gesetzt und der Ausgang auf dem Pegel 1. Schließt der Schalter zwischen den Kontakten 2 und 3, liegt an der Postion /R der Pegel 0 an. Dies bedeutet das der Ausgang des FlipFlops auf den Pegel 0 geht. Sobald der Schalter von einem zum anderen Kontakt wechselt beginnt er in der Regel zu prellen. Während des Prellens wechselt der Schalter zwischen den beiden Zuständen "Schalter berührt Kontakt" und "Schalter ist frei in der Luft". Der Ausgang des FlipFlop bleibt in dieser Prellzeit aber stabil, da der Schalter während des Prellens nie den gegenüberliegenden Kontakt berührt und das RS-FlipFlop seinen Zustand allein halten kann. Die Prellzeit ist stark vom Schaltertyp abhängig und liegt zwischen 0,1..10ms. Die Dimensionierung der Widerstände ist relativ unkritisch. Als Richtwert können hier 100k Ohm verwendet werden.

===Einfacher Taster===

Auch wenn das RS-FlipFlop sehr effektiv ist, wird diese Variante der Entprellung nur selten angewendet. Grund dafür ist, dass in Schaltungen häufiger einfache Taster eingesetzt werden. Diese sind oft kleiner und preisgünstiger. Um einfache Taster (engl. Single Throw Switch) zu entprellen kann ein einfacher RC-Tiefpass eingesetzt werden. Hierbei wird ein Kondensator über einen Widerstand je nach Schalterstellung auf- oder entladen. Das RC-Glied bildet einen Tiefpass, sodass die Spannung über den Kondensator nicht von einen Pegel auf den anderen springen kann.

[[Bild:RC_debouncer.png|framed|left|'''Taster entprellen mit RC-Entpreller''']]

 

Wenn der Schalter geöffnet ist, lädt sich der Kondensator langsam über die beiden Widerstände R1 und R2 auf Vcc auf. Beim Erreichen der Umschaltschwelle springt der Ausgang auf den Pegel 0. Wird der Schalter geschlossen, entlädt sich der Kondensator langsam über den Widerstand R2. Demnach ändert sich der Ausgang des Inverters auf den Pegel 1. Während der Taster prellt kann sich die Spannung über dem Kondensator nicht sprunghaft ändern, da das Auf- und Entladen eher langsam über die Widerstände erfolgt. Ausserdem sind die Schaltschwellen für den Übergang LOW->HIGH und HIGH->LOW stark verschieden (Hysterese, siehe Artikel [[Schmitt-Trigger]]). Bei richtiger Dimensionierung der Bauelemente wird somit erreicht, dass der Ausgang des Inverters prellfrei wird.

Zu beachten ist, dass der Inverter '''unbedingt''' einer mit [[Schmitt-Trigger]] Eingängen sein muss. Standard Logikeingänge haben am Eingang einen Bereich (üblicherweise 0,8V-2,0V), in dem der Ausgang nicht definiert ist. Da die meisten Eingänge von digitalen Schaltungen keine Schmitt-Trigger Eingänge haben, ist dieser unbedingt erforderlich. Als Inverter kann zum Beispiel der 74HC14 eingesetzt werden. Alternativ kann auch ein CD4093 eingesetzt werden. Hierbei handelt es sich um NAND-Gatter mit Schmitt-Trigger Eingängen. Um aus einem NAND-Gatter einen Inverter zu machen, müssen einfach nur die beiden Eingänge verbunden werden oder ein Eingang fest auf HIGH gelegt werden.

Um eine geeignete Dimensionierung zu erhalten, müssen wir etwas mit den Standardformeln für einen Kondensator jonglieren. Die Spannung über den Kondensator beim Entladen berechnet sich nach:
:<math>U_C(t) = U_0 \cdot e^{\frac{-t}{R_2 C_1}}</math>

Damit der Ausgang des Inverters stabil ist, muss die Spannung über den Kondensator und damit die Spannung am Eingang des Inverters, über der Spannungs bleiben, bei welcher der Inverter umschaltet. Diese Schwellwertspannung ist genau die zeitabhängige Spannung über den Kondensator.
:<math>U_C(t)\!\ = U_{th}</math>

Durch Umstellen der Formel ergibt sich nun:
:<math>R_2=\frac{-t}{C_1 \cdot ln\left(\frac{U_{th}}{U_0} \right)}</math>

Ein Taster prellt üblicherweise etwa 10ms. Zur Sicherheit kann bei der Berechnung der Widerstandes eine Prellzeit von 20ms angenommen werden. U_0 ist die Betriebsspannung also Vcc. Die Schwellwertspannung muss aus dem Datenblatt des eingesetzten Schmitt-Triggers abgelesen werden. Für den 74HC14 lassen sich 2,0V aus dem Datenblatt ablesen. Nimmt man für den Kondensator einen mit einer Kapazität von 1µF und eine Betriebsspannung von 5V ergibt sich für den Widerstand der Wert etwa 22kOhm.

Wird der Schalter geöffnet lädt sich der Kondensator nach folgender Formel:
:<math>U_C(t) = U_0 \cdot \left( 1-e^{\frac{-t}{(R_1+R_2)\cdot C_1}} \right)</math>

Mit U_th=U_C ergibt das Umstellen nach (R_1+R_2):
:<math>R_1+R_2 = \frac{-t}{C_1 \cdot ln\left(1-\frac{U_{th}}{U_0} \right)} </math>

Für die Schwellspannung lässt sich aus dem Datenblatt von 2,3V ablesen. Mit diesem Wert und den Annahmen von oben ergibt sich für R_1+R_2 der Wert 32kOhm. Somit ergibt sich für R_1 ein Wert von etwa 10kOhm.

Anmerkung: Beim 74LS14 von Hitachi z.B. sind die oberen und unteren Schaltschwellwerte unterschiedlich. Es muss darauf geachtet werden, dass U_{th} beim Endladen die untere Schwelle und U_{th} beim Laden die obere Schwelle einnimmt.

== Softwareentprellung ==

Bei Verwendung eines Mikrocontrollers kann man sich die zusätzliche Hardware sparen, da die Entprellung genau so gut in Software funktioniert. Dabei ist zu beachten, dass zusätzliche Rechenleistung und je nach Umsetzung auch Hardwareressourcen benötigt werden (z. B. Timer).

=== Flankenerkennung ===
Bei einem Taster gibt es insgesamt 4 Zustände:

* 1. war nicht gedrückt und ist nicht gedrückt
* 2. war nicht gedrückt und ist gedrückt (steigende Flanke)
* 3. war gedrückt und ist immer noch gedrückt
* 4. war gedrückt und ist nicht mehr gedrückt (fallende Flanke)

Diese einzelnen Zustände lassen sich jetzt bequem abfragen/durchlaufen. Die Entprellung geschieht dabei durch die ganze Laufzeit des Programms.

Die Taster werden hierbei als Active-Low angeschlossen um die internen Pull-Ups zu nutzen.

Diese Routine gibt für den Zustand "steigende Flanke" den Wert "1" zurück, sonst "0"

<c>
#define TASTERPORT PINC
#define TASTERBIT PINC1

char taster(void)
{
static unsigned char zustand;
char rw = 0;

if(zustand == 0 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gedrueckt (steigende Flanke)
{
zustand = 1;
rw = 1;
}
else if (zustand == 1 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
else if (zustand == 2 && (TASTERPORT & (1<<TASTERBIT))) //Taster wird losgelassen (fallende Flanke)
{
zustand = 3;
rw = 0;
}
else if (zustand == 3 && (TASTERPORT & (1<<TASTERBIT))) //Taster losgelassen
{
zustand = 0;
rw = 0;
}

return rw;
}
</c>

=== Warteschleifen-Verfahren ===

Siehe [[AVR-GCC-Tutorial#.28Tasten-.29Entprellung|Abschnitt (Tasten-)Entprellung im AVR-GCC-Tutorial]].

Der ''DEBOUNCE'' Befehl in dem BASIC-Dialekt BASCOM für AVR ist ebenfalls nach dem Warteschleifen-Verfahren programmiert. Die Wartezeit beträgt defaultmässig 25 ms, kann aber vom Anwender überschrieben werden. Vgl. [http://avrhelp.mcselec.com/bascom-avr.html?DEBOUNCE BASCOM Online-Manual zu DEBOUNCE].

Der Nachteil dieses Verfahrens ist, dass der Controller durch die Warteschleife blockiert wird. Günstiger ist die Implementierung mit einem Timer-Interrupt.

==== Warteschleifenvariante mit Maske und Pointer (nach Christian Riggenbach) ====

Hier eine weitere Funktion um Taster zu entprellen. Durch den zusätzlichen Code kann eine Entprellzeit von durchschnittlich 1-3ms (mindestens 8*150us = 1ms) erreicht werden. Grundsätzlich prüft die Funktion den Pegel der Pins auf einem bestimmten Port. Wenn die/der Pegel 8 mal konstant war, wird die Schleife verlassen. Diese Funktion kann sehr gut gebraucht werden, um in einer Endlosschleife Taster anzufragen, da sie, wie erwähnt, eine kurze Wartezeit hat.

<c>
void entprellung( volatile uint8_t *port, uint8_t maske ) {
uint8_t port_puffer;
uint8_t entprellungs_puffer;

for( entprellungs_puffer=0 ; entprellungs_puffer!=0xff ; ) {
entprellungs_puffer<<=1;
port_puffer = *port;
_delay_us(150);
if( (*port & maske) == (port_puffer & maske) )
entprellungs_puffer |= 0x01;
}
}
</c>
Die Funktion wird wie folgt aufgerufen:
<c>
entprellung( PINB, (1<<PINB2) );
</c>
Als Maske kann ein beliebiger Wert übergeben werden. Sie verhindert, dass nicht verwendete Taster die Entprellzeit negativ beeinflussen.

=== Interrupt-Verfahren (nach Peter Dannegger) ===

==== Grundroutine (AVR Assembler) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-20435.html#new Forum]

Vorteile
* besonders kurzer Code
* schnell
* sicher (4-fach-Abtastung)

Außerdem können 8 Tasten gleichzeitig bearbeitet werden, es dürfen also
alle exakt zur selben Zeit gedrückt werden. Andere Routinen können z.B. nur eine Taste verarbeiten, d.h. die zuerst oder zuletzt gedrückte gewinnt oder es kommt Unsinn heraus.

Die eigentliche Einlese- und Entprellroutine ist nur 8 Instruktionen
kurz. Der entprellte Tastenzustand ist im Register "key_state". Mit nur 2 weiteren Instruktionen wird dann der Wechsel von Taste offen zu
Taste gedrückt erkannt und im Register "key_press" abgelegt. Im Beispielcode werden dann damit 8 LEDs ein- und ausgeschaltet. Jede Taste entspricht einem Bit in den Registern, d.h. die Verarbeitung erfolgt bitweise mit logischen Operationen. Zum Verständnis empfiehlt es sich daher, die Logikgleichungen mit Gattern für ein Bit = eine Taste aufzumalen. Die Register kann man sich als Flip-Flops denken, die mit der Entprellzeit als Takt arbeiten. D.h. man kann das auch so z.B. in einem GAL22V10 realisieren.

Als Kommentar sind neben den einzelnen Instruktionen alle 8 möglichen
Kombinationen der 3 Signale dargestellt.

Beispielcode für AVR (Assembler):

<avrasm>
.nolist
.include "c:\avr\inc\1200def.inc"
.list
.def save_sreg = r0
.def iwr0 = r1
.def iwr1 = r2

.def key_old = r3
.def key_state = r4
.def key_press = r5

.def leds = r16
.def wr0 = r17

.equ key_port = pind
.equ led_port = portb

rjmp init
.org OVF0addr ;timer interrupt 24ms
in save_sreg, SREG
get8key: ;/old state iwr1 iwr0
mov iwr0, key_old ;00110011 10101010 00110011
in key_old, key_port ;11110000
eor iwr0, key_old ; 11000011
com key_old ;00001111
mov iwr1, key_state ; 10101010
or key_state, iwr0 ; 11101011
and iwr0, key_old ; 00000011
eor key_state, iwr0 ; 11101000
and iwr1, iwr0 ; 00000010
or key_press, iwr1 ;store key press detect
;
; insert other timer functions here
;
out SREG, save_sreg
reti
;-------------------------------------------------------------------------
init:
ldi wr0, 0xFF
out ddrb, wr0
ldi wr0, 1<<CS02 | 1<<CS00 ;divide by 1024 * 256
out TCCR0, wr0
ldi wr0, 1<<TOIE0 ;enable timer interrupt
out TIMSK, wr0

clr key_old
clr key_state
clr key_press
ldi leds, 0xFF
main: cli
eor leds, key_press ;toggle LEDs
clr key_press ;clear, if key press action done
sei
out led_port, leds
rjmp main
;-------------------------------------------------------------
</avrasm>

==== Komfortroutine (C für AVR) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-310276.html Forum]

Funktionsprinzip wie oben plus zusätzliche Features:
* Kann Tasten sparen durch unterschiedliche Aktionen bei kurzem oder langem Drücken
* Wiederholfunktion, z.B. für die Eingabe von Werten

Das Programm ist für avr-gcc/avr-libc geschrieben, kann aber mit ein paar Anpassungen auch mit anderen Compilern und Mikrocontrollern verwendet werden. Eine Portierung für den AT91SAM7 findet man [http://www.google.com/codesearch?q=show:ac2viP-2E2Y:pzkOO5QRsoc:RPICuprYy-A&sa=N&cd=1&ct=rc&cs_p=svn://mikrocontroller.net/mp3dec/trunk&cs_f=keys.c#a0 hier] (aus dem Projekt [[ARM MP3/AAC Player]]).
<c>
/************************************************************************/
/* */
/* Debouncing 8 Keys */
/* Sampling 4 Times */
/* With Repeat Function */
/* */
/* Author: Peter Dannegger */
/* danni@specs.de */
/* */
/************************************************************************/

#include <stdint.h>
#include <avr/io.h>
#include <avr/interrupt.h>

#ifndef F_CPU
#define F_CPU 1000000 // processor clock frequency
#warning kein F_CPU definiert
#endif

#define KEY_DDR DDRB
#define KEY_PORT PORTB
#define KEY_PIN PINB
#define KEY0 0
#define KEY1 1
#define KEY2 2
#define ALL_KEYS (1<<KEY0 | 1<<KEY1 | 1<<KEY2)

#define REPEAT_MASK (1<<KEY1 | 1<<KEY2) // repeat: key1, key2
#define REPEAT_START 50 // after 500ms
#define REPEAT_NEXT 20 // every 200ms

#define LED_DDR DDRA
#define LED_PORT PORTA
#define LED0 0
#define LED1 1
#define LED2 2

volatile uint8_t key_state; // debounced and inverted key state:
// bit = 1: key pressed
volatile uint8_t key_press; // key press detect

volatile uint8_t key_rpt; // key long press and repeat

ISR( TIMER0_OVF_vect ) // every 10ms
{
static uint8_t ct0, ct1, rpt;
uint8_t i;

TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms

i = key_state ^ ~KEY_PIN; // key changed ?
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
i &= ct0 & ct1; // count until roll over ?
key_state ^= i; // then toggle debounced state
key_press |= key_state & i; // 0->1: key press detect

if( (key_state & REPEAT_MASK) == 0 ) // check repeat function
rpt = REPEAT_START; // start delay
if( --rpt == 0 ){
rpt = REPEAT_NEXT; // repeat delay
key_rpt |= key_state & REPEAT_MASK;
}
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed. Each pressed key is reported
// only once
//
uint8_t get_key_press( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_press; // read key(s)
key_press ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed long enough such that the
// key repeat functionality kicks in. After a small setup delay
// the key is reported beeing pressed in subsequent calls
// to this function. This simulates the user repeatedly
// pressing and releasing the key.
//
uint8_t get_key_rpt( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_rpt; // read key(s)
key_rpt ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_short( uint8_t key_mask )
{
cli(); // read key state and key press atomic !
return get_key_press( ~key_state & key_mask );
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_long( uint8_t key_mask )
{
return get_key_press( get_key_rpt( key_mask ));
}

int main( void )
{
KEY_DDR &= ~ALL_KEYS; // konfigure key port for input
KEY_PORT |= ALL_KEYS; // and turn on pull up resistors

TCCR0 = (1<<CS02)|(1<<CS00); // divide by 1024
TIMSK = 1<<TOIE0; // enable timer interrupt

LED_PORT = 0xFF;
LED_DDR = 0xFF;

while(1){
if( get_key_short( 1<<KEY1 ))
LED_PORT ^= 1<<LED1;

if( get_key_long( 1<<KEY1 ))
LED_PORT ^= 1<<LED2;

// single press and repeat

if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
uint8_t i = LED_PORT;

i = (i & 0x07) | ((i << 1) & 0xF0);
if( i < 0xF0 )
i |= 0x08;
LED_PORT = i;
}
}
}
</c>

Das single-press-und-repeat Beispiel geht nicht in jeder Beschaltung, folgendes Beispiel sollte universeller sein (einzelne LED an/aus):
<c>
// single press and repeat

if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){

LED_PORT ^=0x08;
</c>

== Links ==
* [[AVR-Tutorial: Tasten]]
* [[AVR-GCC-Tutorial#.28Tasten-.29Entprellung|AVR-GCC-Tutorial Tastenentprellung]]
* http://www.mikrocontroller.net/forum/read-4-20435.html (AVR Assembler)
* http://www.mikrocontroller.net/forum/read-1-140056.html#140946 (AVR-ASM 1 Taste)
* http://www.ganssle.com/debouncing.pdf A guide to debouncing (engl.), praktische Erläuterungen zum Entprellen in Soft- und Hardware
* http://www.mikrocontroller.net/forum/read-1-242461.html
* http://www.mikrocontroller.net/topic/94829
* http://www.mikrocontroller.net/topic/18764#135843
* [http://www.pololu.com/docs/0J16/all Understanding Destructive LC Voltage Spikes]

[[Category:AVR]]

ATEVK1105

2009-10-18T11:43:17Z

Blackhat-blade: typos

''von Daniel Wolf (danie)''

== Einleitung ==

Das ATEVK1105 ist ein Applikations-board mit dem Atmel die Audio-Funktionalität der AVR32: UC3A-Familie demonstriert.
Die aufgespielte Beispielapplikation demonstriert das Dekodieren von MP3 oder WMA in Software.
Bevor das Board mit eigener Software bespielt wird, sollte die aufgespielte Software gesichert werden, um notfalls den Ursprungszustand des Boards wiederherstellen zu können.

Komponenten:
* AVR32 (Haupt-CPU): AT32UC3A0512
* AVR32 (USB->Seriell | USB->JTAG): AT32UC3B1256-AUT
* Ethernet PHY: DP83848I
* Farbdisplay (TFT mit BackLight): ET024006DHU
* 32MB SDRAM: MT48LC16M16A2
* 8MB DataFlash: AT45DB642D-CNU
* SD/MMC-Slot
* PWM-Audio mit Kopfhörer-Verstärker: TPA6130A2RTJ
* DAC-Audio + Mikrofon: TLV320AIC23B
* Debug und Trace-Interface (JTAG + NEXUS)
* 5 QTouch-Sensoren: QT1081
* 4 Leds am UC3A, 2 Leds am UC3B, 1 Power-Led

== Packungsinhalt ==
[[Bild:ATEVK1105_packung.jpg]]
# ATEVK1105 Board
# Ethernet-Leitung
# USB-Leitung (Typ-A auf Mini-B 5Pol.) (2 Stück)
# USB-OTG-Adapter (Mini-B 5Pol. auf USB-Master-Buchse)
# DVD: Technical Libary
# CD: IAR Embedded Workbench
# Kurzanleitung: ''AVR32913: EVK1105 Getting Started Guide''

== Downloads ==
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4428 ATEVK1105 auf Atmel.com]
* [http://www.atmel.com/dyn/resources/prod_documents/EVK1105-Schematics_BOM.zip Schaltplan]
* [http://www.atmel.com/dyn/resources/prod_documents/doc7745.pdf Offizielle Beschreibung des werkseitigen Bootloaders (DFU)]
* [http://www.atmel.com/dyn/resources/prod_documents/doc7817.pdf AVR32709: AVR32 UC3 Audio Decoder Over USB on AT32UC3A0512]
* [http://alvidi.de/data_sheets/erster_schritt.pdf Ein gutes einsteiger Tutorial zu einem AVR32 Modul (deutsch)]
* [http://www.edtc.com/edt/Products/tft_subsearch.asp?search=240+(RGB)+x+320&page=2 Link zum Hersteller des Displays]

== Erste Inbetriebnahme der vorinstallierten Beispielsoftware ==
[http://www.avrtv.com/2009/03/17/evk1105-uc3-audio-player-kit/ Eindrucksvolle Demonstration von Atmel mittels eines Videos]

== Vorbereitungen ==
=== Installieren der Entwicklungsumgebung ===

# AVR32 Studio laden und installieren
# AVR32 GNU Toolchain laden und installieren
# FLIP-Tool laden und installieren
# AVR32-Studio ausführen
Das auf der Eclipse-IDE basierende Studio fragt beim ersten Start nach einem Ziel für den "Workspace", welches das Verzeichnis für Sourcen und Projekte sein wird, dies kann nach belieben gewählt werden.
siehe auch:
* [[AVR32 Studio]]
* [[AVR32 Studio Einstiegshilfe]]

=== Anlegen des neuen Target (ATEVK1105) ===
* Auf den New-Target Button klicken
[[Bild:ATEVK1105_target_window_0003.png]]
* Im Property-Window die Eigenschaften konfigurieren:
** General
*** Name: '''ATEVK1105'''
*** Binaries: hier muss nichts eingetragen werden
** Details
*** Debugger/Programmer: '''USB DFU''' auswählen
*** Mikrocontroller: '''UC3A0512''' auswählen
*** Clock Source: '''Crystal connected to OSC0''' auswählen
*** Board: '''ATEVK1105''' eingeben
*** Connection: hier kann nichts eingetragen werden
*** Clock: hier kann nichts eingetragen werden
*** Voltage: hier kann nichts eingetragen werden
** Daisy Chain
*** Der DFU-Mechanismus unterstützt kein Daisy Chain, daher kann nichts eingetragen werden
** Information
*** Memory: hier kann nichts eingetragen werden
[[Bild:ATEVK1105_target_propertie_0000.png]]

=== Vorbereiten des Boards ===
Da bei Auslieferung des Boards der Pfostenstecker '''J16''' nicht bestückt ist, dieser jedoch benötigt wird um den UC3A in den DFU-Modus zu bringen, muss er noch aufgelötet werden. bei Verwendung eines JTAG- oder NEXUS-Interfaces ist dies nicht zwingend nötig.
[[Bild:ATEVK1105_J16.jpg]]

Manche Boards wurden mit einer fehlerhaften Firmware auf dem UC3B Prozessor ausgeliefert. Eine FAQ zur Behebung des Problems ist unter folgendem Link zu finden:
[http://support.atmel.no/bin/customer?=&action=viewKbEntry&id=740 EVK1105 - USB Virtual COM Port does not work ]

=== UC3A im DFU-Modus starten ===
==== Allgemeines ====
Um den Prozessor im DFU-Modus (Device Firmware Update) zu starten muss der Pin PA9 auf GND gezogen werden. PA9 ist auf der Pfostenleiste J16-1 (WLESS) zu finden, GND ist auf J16-9. Da dies zu Beginn die erste Wahl des Programmierens ist, macht man sich am besten einen Pfostenverbinder mit Taster. Für fortgeschrittenes Entwickeln mit Debug-Möglichkeit wird dann das JTAG-Interface verwendet. Wenn es professionell mit Debug- und Trace-Möglichkeit zu Werke geht, wird das NEXUS-Interface genutzt.
[[Bild:ATEVK1105_DFU.jpg]]

==== Vorgehensweise ====
# Das Board über die USB-User-Schnittstelle mit dem PC verbinden.
# PA9 auf GND ziehen (und halten)
# Reset-Taster drücken (und loslassen)
# PA9 loslassen
# Windows-Meldung abwarten: [[Bild:ATEVK1105_neue_HW.png]]
# Auf die Nachfrage ob man sich mit Windows-Update verbinden will, mit Nein, diesmal nicht anworten
# Es erscheint die Windows-Meldung um den Treiber zu installieren, diesen manuell aus dem FLIP-Installationsverzeichniss auswählen [[Bild:ATEVK1105_neue_treiber.png]]
# den evtl. geforderten Neustart des Systems ausführen
Nun sollte das Board durch den Target-Dialog in AVR32-Studio angesprochen werden können.

== Auslesen von programmierter Software ==
=== Die vorprogrammierte Beispielapplikation stand unter NDA ===
Die bei Auslieferung des ATEVK1105 aufgespielte Beispielsoftware (mp3-Player) ist im Sourcecode von Atmel erhältlich, bis vor kurzem jedoch leider nur unter NDA.
Dies hat es nötig gemacht die aufgespielte Software vom Prozessor zu sichern.
Es ist mir gelungen die aufgespielte Software vom Prozessor herunter zu laden und als *.hex File zu speichern. Die Nützlichkeit des ganzen sei jedoch in Frage gestellt, da auf diese Weise ja kein Sourcecode verfügbar ist, anhand dem irgendwelche Mechanismen erklärt werden. Diese Beschreibung zeigt allgemein das Auslesen Software, die bereits auf den Prozessor gespielt wurde.


Die Application Note AVR32709 enthält seit Juli 2009 den komletten Source-Code.
Link: [http://www.atmel.com/dyn/products/app_notes.asp?family_id=682 Application Notes zum AVR32].

=== Herunterladen der Beispielsoftware vom Board ===
* Starten von AVR32-Studio
* Verbinden des PC mit dem Board (PC:USB nach Board:User-USB)
* Haupt-CPU des Boards im DFU-Modus starten
* Herunterladen und speichern des ROM-Images als hex-File:
* Es wird ein korrekt konfiguriertes Target-Window benötigt (wichtig ist nur das Target ATEVK1105)
[[Bild:ATEVK1105_target_window_0000.png]]

* Rechtsklick auf das ATEVK1105-Target und auswählen von '''Read...'''
[[Bild:ATEVK1105_target_window_0001.png]]

* Eingabe des Speicherorts, des Dateiformats, des Offset (0x0 passt), der Länge (0x4ffff passt, habe dies empirisch ermittelt in dem ich mehrfach ausgelesen habe, bis die letzen bytes im hex-File 0x00 waren
[[Bild:ATEVK1105_read_window_0000.png]]
* Die Datei '''readout.hex''' enthält nun das Image der Beispielapplikation

== Beispielcode aus AVR32-Studio verwenden ==
Im AVR32-Studio sind einige Beispiele zum ATEVK1105 enthalten, die Verwendung soll hier beschrieben werden.
=== Aufsetzen eines neuen Beispiel-Projekts ===
* Die Erzeugung der Beispielcodes wird über: File->New->Example... aufgerufen: 
[[Bild:ATEVK1105_file_new_example.png]]
* Im folgenden Dialog wählt man das gewünschte Beispiel-Projekt aus: 
[[Bild:ATEVK1105_examples.png]]
* Nun wird man aufgefordert einen Namen für das Projekt einzugeben, dieser kann frei gewählt werden. Als Workspace sollte Use default location aktiv sein.
* Das neue Beispiel-Projekt ist nun im Project-Explorer unter dem vorher vergebenen Namen verfügbar:
[[Bild:ATEVK1105_project_explorer.png]]
=== Übersetzen des Beispielprojekts ===
* Das Projekt das Übersetzt werden soll im Project-Explorer markieren
* Durch drücken des Build-Hammers wird das Projekt übesetzt:
[[Bild:ATEVK1105_build.png]]
* Ein Fenster mit dem fortlaufenden Build-Prozess-Balken wird eingeblendet:
[[Bild:ATEVK1105_build_project.png]]
* In der Console kann überprüft werden ob der Übersetzungsvorgang erfolgreich verlaufen ist:
[[Bild:ATEVK1105_build_console.png]]

== Programmieren des UC3A ==
=== Programmieren über USB ===
* Laden des Bootloaders (DFU-Modus) (siehe 6.4.2: UC3A im DFU-Modus starten - Vorgehensweise)
* Schreiben der Software mit AVR32-Studio
** Rechtsklick auf das Target ATEVK1105 und auswählen von Program...
** Folgendes Fenster erscheint: [[Bild:ATEVK1105_program.png]]
** Hier ist file.elf durch das zu programmierende File mit Pfad zu ersetzen, verwende hierzu den Browse... - Dialog
** Der Offset muss 0x0 betragen.
** Die Dateilänge automatisch mit Entire file ermitteln lassen
** Bei Options müssen alle Haken gesetzt sein
** mit OK bestätigen
* Das Herunterladen abwarten (rechts unten warten bis folgende Meldung verschwindet: [[Bild:ATEVK1105_program_process.png]]
* Der Programmiervorgang kann im Consolen-Fenster kontrolliert werden: [[Bild:ATEVK1105_program_console.png]]
* Das Board wird durch den Bootlader nach dem Programmieren automatisch gestartet (haben wir vorher in den Options angegeben)

=== Programmieren über JTAG ===
Beim Programmieren über JTAG muss darauf geachtet werden, dass der DFU-Bootloader nicht unbeabsichtigt überschrieben wird. Ein gelöschter Bootloader kann nur unter Einsatz des JTAGICE-MKII oder des AVR-One! wieder in den Prozessor geschrieben werden!

==== Erzeugen des JTAG-Target ====
* Verbinden des JTAG MKII mit dem PC (evtl. Treiber installieren)
* Rechtsklick ins Target-Window und Auswahl von Scan Targets -> Es wird ein neues Target angelegt
* Umbenennen des Targets (Properties-Window) in ATEVK1105-JTAG
* Ausfüllen der restlichen Eigenschaften analog zum DFU-Target

==== Reprogrammieren des DFU-Bootloaders ====
* Rechtsklick auf das JTAG-Target und auswahl von Program Bootloader...
* Konfiguration der Pins etc.

== Beispielcode ==
Im AVR32Studio sind zahlreiche Beispielcodes enthalten, diese sind erreichbar über...
/*ToDo*/
* Für ein vollständiges Projekt (OS, TCP/IP Stack, Grafik-Bibliothek usw.) sowie AVR32 Simulator - [http://www.utasker.com/avr32.html http://www.utasker.com/avr32.html]

== Notizen ==
Um Mathematische Funktion zu nutzen müssen folgende Punkte eingebaut werden:
* #include <math.h>
* die Linkeroptionen müssen um ein -lm erweitert werden (wobei -l von avrstudio hinzugefügt wird)
hierzu: rechtsklick auf das projekt und dann Properties\C/C++Build\Settings\AVR32/GNU C Linker\Libaries\im obigen Feld ein m hinzufügen

[[Category:Starterkits]]
[[Category:AVR32-Boards]]

FPGA

2009-10-17T20:01:55Z

Blackhat-blade: typos

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 davor geschalteten Logikelementen. Diese Logikelemente sind entweder Verschaltungen verschiedener Logikgatter (Actel) oder aber kleine 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 (Ausnahme: Actel ProASIC und Fusion, dort bilden die Flashzellen diese Funktion direkt ab) 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 und Actel) oder AntiFuse- (Actel) Technologie. Die sogenannten AntiFuse FPGAs sind einmalig programmierbar.

=== I/O Anschlüsse ===
FPGAs unterstützen als universal einsetzbare Digital-ICs 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 4 Gbps. Oftmals sind weitere Eigenschaften wie Treiberstärke und Flankensteilheit für jeden benutzerdefinierbaren Anschluss (User-IO) einstellbar. Meist sind die Pins zu Bänken 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. Zudem befinden sich hinter vielen IO-Pads sog. [[boundary scan]] Zellen.

Das I/O Verhalten wird mit den IO-Constraints in einem setting-File (Xilinx *.ucf, Altera *.acf, Lattice *.lpf) festgelegt. Alternativ können diese auch als Syntheseoption im Kommentarfeld des Verilog/VHDL Codes mit angegeben werden.

Einige Pins übernehmen besondere Funktionen und sind somit vom Anwender nicht uneingeschränkt oder z.T. auch gar nicht nutzbar. Dazu zählen neben der JTAG-Schnittstelle z.B. die Pins zum Einlesen der Konfigurationsdaten.

Ferner sind einige wenige Pins (2 - 8) zum Einspeisen des Taktes für das Design vorgesehen. Für schnelle Schaltung müssen diese reservierten Pins benutzt werden.

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 bei FPGA Designs häufig unverzichtbar. CPUs sind zwar im Allgemeinen langsamer und weniger effizient, als eine vollständige Implementation aus Logik-Primitiven - aber bei komplexen Abläufen auch deutlich einfacher zu entwickeln. Insbesondere bei sequentiellen Aufgaben (Benutzerinterface, komplexe Steueraufgaben etc.) wird man gerne auf eine
klassische CPU zurückgreifen.

Manche FPGAs integrieren dazu einen oder mehrere Prozessorkerne (z. B. [[AVR]] bei Atmels FPSLIC oder PowerPC bei Xilinx' Virtex) als ''HardCores'' auf einem IC.

Auf der anderen Seite gibt es auch ''SoftCores'' (z. B. ARM-Cortex-M1 bei IGLOO-FPGA von [http://www.actel.com ACTEL]), Prozessorkerne die als Quelltext oder als vor-synthetisierte Netzliste vorliegen. In Abhängigkeit von den zur Verfügung stehenden Ressourcen können diese ''SoftCores'' beliebig instanziiert 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-600 MHz für die Schaltgeschwindigkeit der reinen Logikelemente. Je nach der Anzahl und Komplexität der pro Takt durchzuführenden Operationen ergeben sich dann reale Systemtaktfrequenzen von meist 10-100 MHz für global operierende Einheiten und bis zu 300 MHz für schnelle lokale Module. 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 somit der effektive Datendurchsatz erhöht wird, mit dem Nachteil der gesteigerten Latenz durch das Mehr an Takten. Der Datendurchsatz 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). Ferner kommen diese Familien mit grundsätzlich geringeren Schaltgeschwindigkeiten.

Funktionstechnisch 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.actel.com Actel]
* [http://www.altera.com Altera]
* [http://www.latticesemi.com/ Lattice]
* [http://www.xilinx.com Xilinx]
* [http://www.atmel.com Atmel]

== 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
|-
| [[Digilent Nexys 2]]
| 121
| XC3S500E/1200E
| 16
| 16
| -
| -
| 1x
| Cypress FX2
| 4 Taster, 8 Schalter, 8 LEDs
| 4x7Seg, Programmierung & Stromversorgung über USB oder über Netzteil (5V-15V)
|-
| [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
| ~173,-
| XC3S500E
| -
| 4
| 2.0
| -
| -
| FX-2
| -
| 28 x 44mm, 50 I/O auf 2.54mm Stiftleiste, WIN und LINUX Treiber
|-
| [http://shop.trenz-electronic.de/catalog/product_info.php?products_id=456 Avnet Spartan 3A Evaluation Kit]
| 50
| XC3S400A
| -
| 16
| 2.0
| -
| -
| -
| -
| 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
* 640x480 LCD Display mit touch screen function
* 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,- über ALtera Webseite
* Bei EBV €349,- inkl. MwSt.

==== 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,-

=== Boards für Lattice-FPGAs ===
==== www.hardware-design.de ====
* bietet verschiedene einfache Boards mit Lattice-Bausteinen an
* FPGA-Board mit XP2-17/XP2-8/XP2-5 -> 113,- bis 101,- Euro
* CPLD-Boards u.a. mit MachXO640 -> 89,- Euro

=== Debugging-Hilfen ===
Gerade beim [[Debugging]] größerer FPGA-Designs ist es oft notwendig, auf interne Signale und Busse zuzugreifen, die aus routing- oder Platzgründen nicht an Pins des FPGAs gelegt - und mit konventionellen Analysatoren beobachtet werden können. Nebst den einschlägigen Tools der Hersteller, welche Signal probing über JTAG gestatten (z.B. ChipsScope und SignalTap), werden in FPGAs oft mehr oder weniger komplexe [[Logic Analyzer]] integriert, welche die internen Signale in vielfältiger Weise aufzeichnen. Diese werden in Block-RAMs oder FIFOs gespeichert und durch externe Master ausgelesen. Hier kommen auf der Platine befindliche MCUs oder fremd zugreifende FPGAs / CPUs in Betracht, welche über unterschiedliche Kommunikationsverbindungen (seriell, parallel, LVDS) angeschlossen sind. Dazu werden in die FPGAs entsprechende Cores / Treiber eininstanziiert.

Nachfolgend einige Beispiele:

====Proprietärer serieller Logic Analyzer ====

Die einfachste Möglichkeit ist die direkte Instanziierung eines Blockrams als FIFO mit "breitem" Busanschluss: Linksseitig besitzt das FIFO eine Breite von z.B. 256 Bit (Xilinx-Rams lassen sich ohne weitere Umbeschaltung über den Wizzard mit bis zu 1024 Bits deklarieren und nutzen). Rechtsseitig einen 16- oder 32 Bit breiten Busanschluss für einen Prozessor bzw Parallelinterface oder einen 1 Bit breiten Anschluss für ein serielles streaming interface. Mit einem FiFo-enable können die zu sampelnden Zeiten (Busphasen) festgelegt werden, z.B. anhand eines Kriteriums wie die Erfüllung einer bestimmten mathematischen Bedingung, die man in VHDL formuliert, oder es wird einfach ein Trigger gesetzt. Solange das FiFo nicht voll ist, kann geschrieben werden, was durch die interne FiFo-Verwaltung selbst bereits komplett geregelt wird.

Beim einfachen seriellen Logic Analyzer benötigt man nur noch einen kleinen Core, der permanent das FiFo liest, und den seriellen Overhead (Startbit, Stoppbit, Parity und gfs CRC) hinzufügt. Mit einem einfach Pegelwandler kann so ein PC direkt angeschlossen werden.

Auch denkbar ist die Anbindung an ein fremdes FPGA-board mit viel Speicher über (LV-)DS-Kommunikation. In komplexeren Systemen wird ein CAN- oder USB-Core eingesetzt.

Wenn mittels des Kriteriums nur ganz bestimmte kritische Phasen herausgesampelt werden (z.B. das Auftauchen eines bestimmten Rechenfehlers im FPGA) und so das Datenaufkommen je Zeiteinheit über längere Zeit betrachtet eher gering ist, kann bei geeignetem Datendurchsatz in Echtzeit dauerhaft mitprotokolliert werden.

==== BusProbe, der Debugging Core von abaxor engineering ====
Mit der BusProbe kann der Entwickler den Signalfluss im FPGA-Design auch über einen längeren Zeitraum überwachen und am PC aufzeichnen. Der Core verarbeitet an jedem Eingang einen kompletten Bus.

Die Daten werden gemultiplext zum PC geschickt und dort per Software demultiplext. Im PC erfolgt auch die Auswertung mit beliebigen Analyse-Tools.

Gegenüber dem Betriebssystem verhält sich die BusProbe wie eine Festplatte, von der die Daten mit gewöhnlichen Zugriffen gelesen werden können.

* Streaming der Daten zum PC mit mehr als 20 MByte/s
* keine Treiber im PC da Nutzung von Standardschnittstellen (USB oder IDE)
* Hot-Plugging
* 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 Eigenen einstellen und an anderen mitarbeiten. U.a. gibt es verschiedene CPUs für FPGAs.
* [http://members.optushome.com.au/jekent/FPGA.htm John's FPGA Page]
* [http://www.embedded.com/columns/whatsnew/197003073 More about designing with embedded FPGAs] by Bernard Cole, Embedded.com

[[Category:FPGA und Co]]