FPGAs für Maker - Cord Elias - E-Book

FPGAs für Maker E-Book

Cord Elias

0,0

Beschreibung

Field Programmable Gate Arrays (FPGAs) sind relativ komplexe programmierbare Logikbausteine. Mithilfe von FPGAs können mittlerweile jedoch auch Maker und Elektronikbastler eigene Chips entwerfen. Wie das geht, zeigt Ihnen dieses Buch. Zunächst wird erklärt, was FPGAs sind und wie sie funktionieren. Es folgt eine Einführung in die Hardwarebeschreibungssprache VHDL, die für die Projekte in diesem Buch verwendet wird. Danach wird Schritt für Schritt anhand zunächst ganz einfacher Beispiele erläutert, wie man eine Schaltung mithilfe eines FPGA realisiert. Im weiteren Verlauf werden die Schaltungen anspruchsvoller. Den Abschluss bildet ein Projekt, bei dem das Spiel "Pong" in Hardware realisiert wird. Die Anzeige erfolgt auf einem RGB-LED-Matrix-Display, dessen Ansteuerung per FPGA im Detail beschrieben wird. Die Projekte im Buch werden auf Basis kostenlos verfügbarer FPGA-Entwicklungsumgebungen der Hersteller Altera, Lattice, Microsemi und Xilinx sowie günstiger FPGA-Boards konkret umgesetzt. Dabei wird auf die Übertragbarkeit auf andere Systeme geachtet. Die verwendeten Entwicklungsumgebungen und FPGA-Boards werden außerdem kurz vorgestellt. Cord Elias konzentriert sich primär auf die Vermittlung von Fähigkeiten zum selbstständigen Umgang mit FPGAs. Er nimmt die Leserinnen und Leser an die Hand und leitet sie sicher durch eine Vielzahl von Details. Dass der Spaß dabei nicht zu kurz kommt, versteht sich von selbst. Der Quellcode zu allen Design-Beispielen steht zum Download bereit.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 364

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Dipl.-Ing. Cord Elias hat über 20 Jahre Industrieerfahrung im Bereich »Embedded Systems«. Seit einigen Jahren ist er in diesem Fachgebiet als selbstständiger Berater tätig. Seine Schwerpunkte beinhalten modellbasierte Entwicklung und automatische Codegenerierung.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:www.dpunkt.de/plus

FPGAs für Maker

Eine praktische Einführung in programmierbare Logik

Cord Elias

Cord Elias

[email protected]

Lektorat: Dr. Michael Barabas

Copy-Editing: Petra Kienle

Satz: Cord Elias

Grafikentwurf: Gerdi Elias

Bildbearbeitung: Johannes Scherer

Herstellung: Susanne Bröckelmann

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print   978-3-86490-173-7

PDF   978-3-96088-030-1

ePub   978-3-96088-031-8

mobi   978-3-96088-032-5

1. Auflage 2016

Copyright © 2016 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

FPGAs – Field Programmable Gate Arrays – sind programmierbare Logikbausteine mit einer recht hohen Komplexität. Dieses Buch möchte Makern – Anwendern, die sich mit der Materie nicht primär aus beruflichem Interesse befassen – einen praktischen Einstieg in die spannende Welt der FPGAs und ihrer Anwendungen geben. Dabei stehen Aspekte wie Spaß an der Sache, das möglichst spielerische und leichte Erlernen von neuen Dingen und das praktische Realisieren von funktionstüchtigen Anwendungen im Vordergrund und nicht eine theoretisch-exakte Abhandlung mit gelegentlich eingestreuten Beispielen. Das Buch ist so angelegt, dass es für längere Zeit nutzbar bleibt. Es greift nicht einen schnelllebigen Hype in Bezug auf eine bestimmte Hardwareplattform auf und ist bezüglich der verwendeten Software-Tools nicht von ganz bestimmten Versionen abhängig.

Der Leser sollte über Grundkenntnisse in Digitaltechnik verfügen, die hier nicht noch einmal wiederholt werden. Das Literaturverzeichnis enthält entsprechende Hinweise ([15], [9], [3], [14]).

Als sinnvolle Erstinvestition neben diesem Buch fällt lediglich der Kauf eines FPGA-Boards an (mit einem FPGA-Baustein von Altera, Lattice, Microsemi oder Xilinx). Wer hier sehr sparsam ist, kommt dafür mit weniger als 30 € aus. Auf solch einem Board befinden sich als Periphierieelemente einige Schalter und Leuchtdioden, weiter Peripherie muss selbst ergänzt werden.

Wer bereit ist, ca. 100 € auszugeben, bekommt ein Board mit guter Ausstattung an Schaltern, Tastern, LEDs etc. Damit lassen sich die meisten Beispiele aus diesem Buch ohne weitere Bastelei sofort umsetzen. Ab ca. 160 € erhält man ein Board, das zusätzlich ein vierstelliges Siebensegment-Display, einen VGA-Ausgang und ggf. weitere Schnittstellen bietet. Damit lassen sich auch komplexere Schaltungen ohne weiteren Aufwand realisieren.

Die erforderliche Entwicklungs-Software ist kostenlos verfügbar, in der Regel für Windows und für Linux.

Aber selbst die Ausgabe für ein FPGA-Board ist nicht unbedingt erforderlich, um sich mit Hilfe dieses Buchs in die Materie einzuarbeiten. Alle hier vorgestellten Beispiele können auch mit einem Simulator nachvollzogen werden. Jede hier vorgestellte Werkzeugkette enthält einen Simulator, außerdem ist mit »GHDL« auch ein Open-Source-Simulator verfügbar.

Zur Erstellung von Designs für das FPGA wird hier die Sprache VHDL benutzt. Es werden keinerlei VHDL-Vorkenntnisse erwartet; die Sprache wird schrittweise und systematisch eingeführt, aber nur mit den hier wirklich notwendigen und nützlichen Sprachelementen, ohne akademische Beschreibungen und Anspruch auf Vollständigkeit. VHDL ist zumindest in Europa der De-facto-Standard in Sachen Hardwarebeschreibung und ermöglicht u.a. auch die Teilnahme an der Open-Source-Community (die es auch für konfigurierbare Hardware gibt).

Neben den bereits erwähnten »Makern«, für welche dieses Buch eigentlich geschrieben wurde, ist es durchaus auch für Studenten technischer Fachrichtungen und andere Interessierte geeignet, die praktische Ergänzungen zu eher theoretischem Unterrichtsmaterial suchen oder sich im Selbststudium in die FPGA-Thematik einarbeiten wollen.

Ich wünsche allen Leserinnen und Lesern viel Spaß bei der Beschäftigung mit programmierbarer Logik! Über Hinweise, Anregungen und Verbesserungsvorschläge freue ich mich jederzeit.

Cord Elias

Aachen, August 2016

Inhaltsverzeichnis

I      Einführung

1      Wieso FPGAs für Maker?

2      Struktur und Verwendung dieses Buchs

3      FPGA-Grundlagen

3.1    Was ist ein FPGA?

3.2    Entwicklungsablauf im Überblick

3.3    VHDL-Einführung

3.4    Eine erste Dosis VHDL

3.5    Notwendige Ausstattung

II      Einfache Schaltungen

4      Los geht’s – das erste FPGA-Projekt

4.1    Einführung

4.2    Vorbereitendes Experiment und Workflow

4.3    Logik-Gatter

4.4    Simulation

4.5    Zusammenfassung

5      »Hello World« – es blinkt

5.1    Getaktete Digitalsysteme

5.2    Zähler

5.3    Simulation des Binärzählers

5.4    Ein Teiler für die LED

5.5    Blinken mit Hardware

5.6    Verfeinerter Binärzähler

5.7    Zusammenfassung

6      VHDL-Intermezzo

6.1    Sprachstandards

6.2    Struktur eines VHDL-Files

6.3    VHDL-Statement

6.4    Concurrent ↔ Sequential

6.5    Ein wenig mehr VHDL

6.6    Ausgewählte VHDL-Konstrukte und -Designmuster

6.7    Synchrone Digitalsysteme

6.8    Universelle Grundstruktur

6.9    Zusammenfassung

7      Bausteine und Entwurfsmuster

7.1    Clock-Signale

7.2    Verwendung von IP

7.3    Synchronisierung und Entprellung

7.4    Zustandsautomat

7.5    Zusammenfassung

8      Siebensegmentanzeigen

8.1    Aufbau und Funktion

8.2    Einfacher Test mit einem Element

8.3    Umwandlung von Binärcode in eine Hex-Zahlendarstellung

8.4    Umwandlung von Binärcode in eine Dezimalzahlendarstellung

8.5    Mehr als ein Digit – Multiplexing

8.6    Komplettbeispiel

8.7    Zusammenfassung

9      Spielereien mit Leuchtdioden

9.1    Als die Lichter laufen lernten

9.2    Dimmen einer LED

9.3    RGB-LEDs

9.4    Zusammenfassung

III      Weiterführendes und Projekte

10      Wie kommt man weiter?

10.1    FPGA-Board

10.2    FPGA-Entwicklungsumgebung und Workflow

10.3    VHDL

11      Digitaluhr auf FPGA-Basis

11.1    Merkmale der Digitaluhr

11.2    Anforderungen an die Hardware

11.3    Entwicklung des Schaltungskonzepts

11.4    Implementierung

11.5    Integration

11.6    Zusammenfassung

12      Ansteuerung eines RGB-LED-Matrix-Displays

12.1    Grundlagen

12.2    Schaltung zur Display-Ansteuerung

12.3    Pong

12.4    Zusammenfassung

13      Ausflug zu Verilog

13.1    Einstieg in Verilog

13.2    Einbinden eines Verilog-Moduls in ein VHDL-Projekt

13.3    Simulation bei der Verwendung von Verilog-Modulen

IV      Anhang

A      VHDL-Kurzübersicht

A.1    entity

A.2    architecture

A.3    component

A.4    process

A.5    Datentypumwandlungen

A.6    Initialisierung mit others

A.7    Bedingte Ausführung

B      FPGA-Werkzeugketten

C      Altera-Werkzeugkette »Quartus Prime Lite Edition«

C.1    Anlegen eines neuen Projekts

C.2    Anlegen eines neuen VHDL-Files

C.3    Einbinden eines schon vorhandenen VHDL-Files

C.4    Analyse und Synthese

C.5    Pin Planning

C.6    Place & Route, Erzeugung des Bitstreams

C.7    Download

D      Lattice-Werkzeugkette »Diamond«

D.1    Anlegen eines neuen Projekts

D.2    Anlegen eines neuen VHDL-Files

D.3    Einbinden eines schon vorhandenen VHDL-Files

D.4    Eingabe von Constraints

D.5    Synthese, Mapping, Place & Route

D.6    Generierung der Konfigurationsdaten

D.7    Download

E      Microsemi-Werkzeugkette »Libero SoC«

E.1    Anlegen eines neuen Projekts

E.2    Anlegen eines neuen VHDL-Files

E.3    Einbinden eines schon vorhandenen VHDL-Files

E.4    Synthese

E.5    Definition von I/O-Constraints

E.6    Erzeugen der Konfigurationsdaten

E.7    Download

F      Xilinx-Werkzeugkette »ISE«

F.1    Anlegen eines neuen Projekts

F.2    Anlegen eines neuen VHDL-Files

F.3    Anlegen von I/O-Constraints

F.4    Einbinden eines schon vorhandenen VHDL-Files

F.5    Implementierung

F.6    Erzeugung des Bitstreams

F.7    Download

G      Vergleich der Werkzeugketten

H      FPGA-Boards für Maker

H.1    Einige Bezugsquellen

H.2    Board-Übersicht

H.3    Boards, Boards, Boards

Glossar

Literaturverzeichnis

Index

Teil I

Einführung

1 Wieso FPGAs für Maker?

»FPGAs – das ist doch nur etwas für Profis, Bastler sollen doch besser bei ihren Arduinos und ähnlichen Boards bleiben, damit haben sie doch genug zu tun«. So lautete der Kommentar eines »Profis« gegenüber dem Autor vor Beginn dieses Buchprojekts. Wie der Leser spätestens jetzt ahnt, sieht der Autor dies anders, sonst wäre dieses Buch nicht entstanden.

Vor einigen Jahren wäre das Vorhaben »FPGAs für Maker« allerdings rein an den Kosten gescheitert. Mittlerweile sind aber FPGA-Entwicklungstools von allen in diesem Buch erwähnten FPGA-Herstellern in kostenlosen Versionen verfügbar, welche für die in diesem Buch vorgestellten Projekte und noch einiges mehr vollkommen ausreichen.

Somit ist es jetzt auch für Maker gut möglich, FPGAs für eigene Projekte einzusetzen. Die schon vorhandene Werkzeugsammlung wird quasi um ein leistungsfähiges Werkzeug erweitert. Das ist vergleichbar mit der Anschaffung eines Schweißgeräts durch einen Maker, der bislang schon Dinge aus Metall hergestellt hat, sich zuvor bei der Verbindungstechnik aber immer auf Schrauben, Kleben und Nieten beschränken musste. Beim Schweißen ist es nicht mit dem Kauf eines Geräts getan, sondern man muss sich auch die entsprechenden Kenntnisse und Fähigkeiten aneignen, um Metallteile mittels Schweißen miteinander zu verbinden. Wenn man einmal über anfängliche »Bruzzeleien« hinauskommt, eröffnen sich sehr viele neue Gestaltungsmöglichkeiten. Mit den FPGAs ist es ähnlich: Man braucht am Anfang ein wenig Geduld und Durchhaltevermögen, aber ab einem gewissen Punkt ist man in der Lage, selbstständig schöne Projekte zu realisieren, die vorher so nicht möglich gewesen wären.

Das Ziel dieses Buchs ist es, den Leser zu diesem Punkt hinzuführen und zu begleiten. Dazu wird mit ganz einfachen, teilweise womöglich banal anmutenden Dingen angefangen. Der Autor weiß aber aus langjähriger Berufspraxis im Embedded-Umfeld, dass es oft gerade diese vermeintlich einfachen Dinge sind, die letztendlich den Unterschied zwischen Erfolg und weniger zufriedenstellenden Ergebnissen ausmachen.

Eine erste Anwendung eines FPGAs für Maker kann der Ersatz des Breadboards sein. Anstatt diskrete Logik-ICs aufzustecken und mit Drähten miteinander zu verbinden, wird ein FPGA eingesetzt. Das bietet bereits bei kleineren Projekten viele Vorteile:

Einfache Änderbarkeit

Beliebige Digitalbausteine sind jederzeit verfügbar, weil sie im FPGA enthalten sind (in Form von Grundelementen, die entsprechend konfiguriert werden)

Anstatt eines schwer zu pflegenden und zu erweiternden »Drahtverhaus« ergibt sich bei Verwendung eines FPGAs ein sauberer Aufbau

Es können wesentlich höhere Taktfrequenzen erreicht werden (Breadboards setzen da konstruktionsbedingt relativ früh Grenzen)

Der Ersatz von diskreter Digitaltechnik in evtl. bereits schon realisierten Projekten ist ein möglicher Weg, um den Umgang mit FPGAs zu lernen und zu vertiefen. Man kann aber auch gleich mit neuen Projekten anfangen. Zu Anfang wird es eher so sein, dass diese Projekte auch mit einem Mikrocontroller realisiert werden könnten. Es lohnt sich aber, für den Einstieg die Anforderungen nicht zu hoch zu setzen.

Wenn man dann die ersten guten Erfahrungen mit einem FPGA gesammelt hat, kann man z.B. die Ansteuerung eines LED-Matrix-Displays angehen, die mit einem Mikrocontroller so einfach (oder überhaupt) nicht zu machen ist.

Und wer dann weitermacht, realisiert vielleicht einen Video-Coprozessor für seinen Lieblings-Mikrocontroller in einem FPGA oder integriert einen Mikrocontroller in Form eines sog. Soft-Cores gleich mit in das FPGA – die Möglichkeiten sind fast unbegrenzt.

2 Struktur und Verwendung dieses Buchs

»FPGAs für Maker« ist so angelegt, dass man es von vorne bis hinten durcharbeiten kann, aber nicht muss. Wer sich mit der Materie noch gar nicht auskennt, fängt am besten wirklich ganz vorne an und arbeitet die Teile »Einführung« und »Einfache Schaltungen« systematisch durch. Wer schon Vorwissen und Vorerfahrung mitbringt, kann an beliebiger Stelle quer einsteigen und sich gleich mit fortgeschritteneren Dingen befassen.

Kapitel 3 »FPGA-Grundlagen« beginnt mit grundlegenden Dingen über Aufbau und Funktionsweise von FPGAs. Es wird eine Einführung in den Workflow zur Entwicklung mit FPGAs inklusive Simulation gegeben und die Hardwarebeschreibungssprache VHDL wird in ihren Grundzügen erläutert. Bemerkungen zu der notwendigen Ausstattung runden dieses Kapitel ab.

In dem folgenden Kapitel 4 »Los geht’s – das erste FPGA-Projekt« wird der Leser an die Hand genommen und Schritt für Schritt anhand eines ganz simplen Beispiels durch den FPGA-Entwicklungsprozess geführt. Als FPGA-Entwicklungswerkzeug wird dabei »Vivado« (die kostenlose Web-Edition) von der Firma Xilinx verwendet, als FPGA-Board meistens »Arty« des Herstellers »Digilent Inc.«. Das Vorgehen wird so erläutert, dass es auch auf andere Werkzeugketten und FPGA-Boards übertragbar ist. Weitere für Maker geeignete (= in einer kostenlosen Version verfügbare) FPGA-Entwicklungswerkzeuge werden im Anhang vorgestellt; dort wird der Basis-Workflow anhand eines standardisierten Beispiels in Verbindung mit einem passend gewählten FPGA-Board für jedes dieser Werkzeuge demonstriert:

Altera: »Quartus Prime Lite Edition«

Lattice: »Diamond«

Microsemi: »Libero SoC«

Xilinx: »ISE« (zur Unterstützung von Designs für die ältere »Spartan-6«-FPGA-Familie)

Am Ende von Kapitel 4 sollte jeder Leser ein einfaches Beispiel mit kombinatorischer Logik auf seinem Board erfolgreich umgesetzt haben.

In Kapitel 5 »Hello World – es blinkt« werden getaktete Digitalsysteme eingeführt. Es wird am Beispiel erklärt, wie solche Systeme in VHDL beschrieben werden. Die für die Welt der eingebetteten Systeme so typische Demo »Blinkende Leuchtdiode« dient als anschauliches Beispiel und Ausgangspunkt für Verfeinerungen.

In Kapitel 6 »VHDL-Intermezzo« wird die Hardwarebeschreibungssprache VHDL ein wenig intensiver beleuchtet. Es werden bereits in vorherigen Kapiteln vorgestellte Merkmale rekapituliert und neue Sprachelemente eingeführt. Eine wichtige Rolle spielt dabei die Behandlung von parallelen und sequentiellen Abläufen, deren Besonderheiten zu Anfang nicht ganz leicht zufassen sind. Auch auf Datentypen wird eingegangen, als stark typisierte Sprache macht es VHDL dem Anfänger mit diesem Thema nicht immer ganz leicht.

Besonders wichtig ist die Grundstruktur für synchrone Digitalsysteme, die ausführlich erläutert wird. Mit Hilfe dieser Struktur ist es möglich, auch kompliziertere Schaltungen so zu beschreiben, dass sie gut funktionieren und die Beschreibung trotzdem übersichtlich bleibt. Das Kapitel wird mit einfachen Beispielen abgeschlossen, welche diese Grundstruktur verwenden und zum Ausprobieren einladen.

In Kapitel 7 »Bausteine und Entwurfsmuster« werden weitere Elemente für gutes FPGA-Design vermittelt. Hier geht es um Themen wie Clock-Generierung, Entprellung und Zustandsautomaten. Es sind Beispiele in VHDL enthalten, die leicht nachvollziehbar sind.

Die beiden folgenden Kapitel 8 »Siebensegmentanzeigen« und 9 »Spielereien mit Leuchtdioden« enthalten Anwendungsbeispiele, die mit überschaubarem Aufwand nachvollzogen werden können. Die Beispiele sind so aufgebaut, dass immer neue Aspekte dazukommen und sich somit das Know-how des Lesers immer weiter entwickeln kann. Der Fokus wurde bewusst auf »optische Effekte« gelegt, weil diese Anwendungen ohne aufwendige Peripherieelemente auskommen und mit dem Auge beurteilt werden können. Es werden hier auch Zustandsautomaten verwendet, um einfache User-Interfaces zu realisieren. Als Eingabegeräte werden lediglich Schalter und Taster verwendet.

In dem folgenden Teil »Weiterführendes und Projekte« folgen zunächst kurze Hinweise, die beim selbstständigen Entwickeln eigener Anwendungen helfen sollen.

Die beiden folgenden Kapitel enthalten komplexere Projekte, welche sowohl zum Nachbau geeignet sind als auch als Anregung für weitere Projekte dienen sollen.

Den Abschluss ein Kapitel zu der Hardwarebeschreibungssprache Verilog. Dabei ist das Ziel, gerade so viel zu dieser Sprache zu vermitteln, dass in Verilog geschriebene Schaltungsbeschreibungen in eigene VHDL-Projekte eingebunden werden können.

Neben den schon erwähnten Beschreibungen diverser FPGA-Entwicklungsumgebungen und enthält der Anhang einen kurzen Vergleich dieser Toolketten, eine VHDL-Kurzübersicht sowie Kurzbeschreibungen einiger FPGA-Boards, die zur Realisierung der in diesem Buch vorgestellten Schaltungen verwendet werden können.

Auch wenn dieses Buch viele Details enthält – es ist vollkommen unmöglich, hier alle Features, Einstellmöglichkeiten usw. auch nur einer FPGA-Werkzeugkette zu erläutern. Die für den Anwender gedachte Dokumentation eines solchen Werkzeugs mit UserManuals, den wichtigsten Application Notes etc. umfasst viele Hundert bis mehrere Tausend Seiten, je nachdem, wie wissbegierig man ist und mit welchem Werkzeug man arbeitet. Für VHDL gilt das Gleiche. Viele Dinge werden erwähnt, aber längst nicht alles. Wer ambitioniert ist und sich intensiver mit FPGAs und ihren überaus spannenden Möglichkeiten und Anwendungen befasst, wird weitere Literatur hinzuziehen, auch technische Informationen, die sich speziell auf das verwendete FPGA beziehen. Unterlagen zu den Tools und den FPGAs sind auf den Webseiten der FPGA-Hersteller im pdf-Format verfügbar. Zu VHDL findet man im Web auch viele Beiträge unterschiedlicher Qualität. Außerdem enthält das Literaturverzeichnis am Ende des Buchs Verweise auf Bücher zu diesem Thema [1], [2], [4], [5], [6], [7], [8], [10], [11], [12], [13].

Weiterhin finden sich im Web Beschreibungen von FPGA-Projekten, oft auch mit Quellcode. Diese können als Anregung für eigene Projekte dienen.

Zu diesem Buch existiert eine Projektseite, dort ist auch der Quellcode der abgedruckten Beispiele in elektronischer Form verfügbar: www.dpunkt.de/fpga.

Noch ein Hinweis zu dem Quellcode: Die meisten Kommentare sind in Englisch gehalten, weil das zu VHDL nach Meinung des Autors am besten passt. Alle Beispiele wurden getestet, trotzdem liegt es natürlich in der Verantwortung eines jeden Lesers dafür zu sorgen, dass keine Schäden an FPGA-Boards etc. entstehen.

Und nun viel Spaß beim Lesen, Lernen und Tüfteln mit FPGAs!

3 FPGA-Grundlagen

3.1 Was ist ein FPGA?

Ein FPGA kann als Ansammlung von Grundelementen wie Gatter, Flip-Flop, Speicherzelle etc. angesehen werden, die in einem gemeinsamen Gehäuse vorhanden sind, aber noch miteinander verdrahtet werden müssen, um eine bestimmte Funktion zu realisieren. Sehr vereinfacht kann ein FPGA auch als vorbestücktes Steckbrett im Mikroformat betrachtet werden. Elemente wie Gatter und Flip-Flops sind schon fertig aufgesteckt, nur die Verdrahtung muss noch vom Anwender vorgenommen werden. Anstatt wie auf dem Steckbrett Drähte einzustecken, werden beim FPGA die elektrischen Verbindungen durch das Schließen von auch schon vorhandenen »Schaltern« vorgenommen. Abbildung 3-1 zeigt den sehr stark vereinfachten prinzipiellen Aufbau eines FPGA. Man erkennt in Abbildung 3-1 Folgendes:

Es gibt Grundelemente, die intern flexibel miteinander verbunden werden können (hier: UND-Gatter, Inverter, D-Flip-Flop).

Die meisten Pins des Chips können flexibel den Ein- bzw. Ausgängen der internen Elemente zugeordnet werden (die hier dargestellte Aufteilung in Eingangs- und Ausgangspins existiert in der Praxis so nicht, vielmehr sind die meisten Pins sowohl als Eingang als auch als Ausgang konfigurierbar).

Es gibt auch spezielle Pins (hier ein Clock-Eingangs-Pin).

Weitere spezielle Pins, zum Beispiel zur Spannungsversorgung, sind vorhanden, auch wenn sie hier nicht explizit gezeigt werden.

Die hier als Schalter dargestellten Verbindungspunkte sind bei einem FPGA im Auslieferzustand alle offen. Mit Hilfe der entsprechenden Designsoftware wird festgelegt, welche »Schalter« für die gewünschte Anwendung geschlossen werden. Man kann sofort erkennen, dass beim Definieren der Verbindungspunkte sorgfältig vorgegangen werden muss, weil sonst schnell Fehler passieren können (z.B. das Kurzschließen zweier Eingänge), die unter Umständen zur Zerstörung des Chips führen. Allein aus diesem Grund werden die »Schalterstellungen« nicht manuell definiert, sondern durch eine spezielle Entwicklungssoftware; einmal ganz davon abgesehen, dass selbst einfachste FPGA so komplex sind, dass ein manuelles Definieren der Konfiguration auf Low-Level-Ebene vollkommen unpraktikabel ist.

Abbildung 3-1: FPGA – prinzipieller Aufbau

Weiterhin erwähnenswert ist, dass die Pins in der Regel auch in Hinsicht auf physikalische Details wie I/O-Pegel (z.B. 3.3V, 2.5V, 1.8V; ein FPGA kann auch sehr elegant als Pegel-Konverter eingesetzt werden), max. Ausgangsstrom usw. konfiguriert werden können bzw. müssen. Die spezifischen Details hängen immer vom verwendeten Chip ab und müssen in der Entwicklungspraxis neben vielen anderen Dingen bei der Auswahl eines FPGA für einen bestimmten Anwendungsfall berücksichtigt werden.

Zu den I/O-Pegeln sei an dieser Stelle schon angemerkt, dass heute verfügbare FPGAs in aller Regel nicht 5V-kompatibel sind. Wer z.B. ein FPGA mit einem Arduino Uno »verheiraten« möchte, sollte die Verbindungsleitungen zwischen Arduino und FPGA über für diesen Zweck geeignete Pegelkonverter leiten.

Selbst mit dem in Abbildung 3-1 dargestellten idealisierten Mini-FPGA lassen sich bereits diverse Schaltungen realisieren, von denen in Abbildung 3-2 einige dargestellt sind. Jede Schaltung kann durch einfache Umkonfiguration des FPGA schnell erzeugt werden, ohne dass an der Hardware irgendetwas geändert werden muss. Dieses Merkmal ist besonders für das Rapid Prototyping interessant. FPGAs sind aber auch im Serieneinsatz und haben dort in einigen Bereichen ASICs1 abgelöst (natürlich auch in Abhängigkeit von Faktoren wie Stückzahlen). Beim Serieneinsatz von FPGAs ist ein interessanter Aspekt, dass auch nach der Auslieferung noch vergleichsweise einfach Änderungen am Hardwaredesign vorgenommen werden können, vergleichbar mit einem Software- bzw. Firmwareupdate.

Abbildung 3-2: Beispielschaltungen

Zum Speichern der Konfigurationsinformationen in dem FPGA existieren im Wesentlichen zwei Ansätze:

Statisches RAM (SRAM): Hier gehen die Konfigurationsinformationen komplett verloren, sobald das FPGA von der Spannungsversorgung getrennt wird. Das bedeutet, dass beim Hochfahren der Hardware (= Anlegen der Versorgungsspannung) die Konfiguration jedes Mal wieder neu »eingespielt« werden muss. Dazu gibt es verschiedene Verfahren, verbreitet ist die Verwendung spezieller EEPROMS mit SPI-Schnittstelle.

Flash-Speicher: Hier bleibt die Konfiguration beim Abschalten erhalten. Auf der anderen Seite benötigt Flash-Speicher mehr Platz auf dem Chip und ist relativ teuer.

In Wirklichkeit ist das Ganze noch wesentlich komplexer als bisher dargestellt. Beispielsweise finden sich in einem typischen FPGA keine einzelnen UND-Gatter etc. Die Basisbausteine bilden vielmehr Elemente, die je nach Hersteller z.B. »Logic elements« oder »Logic Cells« genannt werden. Sie beinhalten als wesentliche Bestandteile ein bis zwei Lookup-Tables und ein oder zwei Flip-Flops sowie Infrastruktur zum Routen der Signale wie Multiplexer (alles abhängig vom Hersteller und vom genauen FPGA-Typ). Mit Hilfe eines Lookup-Table können sämtliche logischen Kombinationen zwischen den Eingangssignalen (für die hier betrachteten FPGAs typisch 3 ... 6) dieses Basisbausteins gebildet werden.

Abbildung 3-3: LUT-Beispielschaltung

Die (booleschen) Eingangssignale ›il‹, ›i2‹ und ›i3‹ können als Indices für den Lookup-Table angesehen werden, für jede Kombination dieser Eingangswerte ergibt sich ein eindeutiger Ausgangswert ›o‹.

Dieses einfache Beispiel sollte man mit Papier und Bleistift nachvollziehen, wenn es beim ersten Lesen nicht klar ist. Es wäre dann sinnvoll, zunächst den Ausgang des ODER-Gatters als Zwischenwert zu bestimmen und im zweiten Schritt die UND-Verknüpfung dieses Zwischenergebnisses mit dem dritten Eingang zu ermitteln, was dann auch schon das gesuchte Ausgangssignal ›o‹ liefert. Genauso kann man sich auch andere einfache oder auch komplexere Schaltungen überlegen und dazu den entsprechenden Lookup-Table aufstellen. Letztendlich wird man zu dem Schluss kommen, dass jede beliebige kombinatorische Schaltung mit Hilfe eines Lookup-Table realisiert werden kann. Im Web findet man auch Generatoren für Lookup-Tables, z.B. unter http://programming.dojo.net.nz/study/truth-table-generator/.

i1

i2

i3

0

0

0

0

0

0

0

1

0

0

1

0

0

0

1

1

1

1

0

0

0

1

0

1

1

1

1

0

0

1

1

1

1

Tabelle 3-1: Wahrheitstabelle zu Abbildung 3-3

Eine wiederum stark vereinfachte und idealisierte Version einer »Logic Cell« (oder wie auch immer dieses Basiselement vom jeweiligen Hersteller bezeichnet wird) ist in Abbildung 3-4 dargestellt.

Neben dem Lookup-Table (LUT) sind noch ein Multiplexer (MUX) und ein Flip-Flop (FF) dargestellt. Als Flip-Flop-Typ (D, J/K etc.) wird in der Regel das D-Flip-Flop verwendet. Außerdem sind für das Flip-Flop neben Daten- und Clock-Eingang noch Eingänge für Clock-Enable (CE) und Set/Reset (S/R) dargestellt.

Diese Logikzellen werden häufig paarweise zusammengefasst, dieses Konstrukt nennt sich dann zum Beispiel »Slice«. Selbst einfache FPGA, wie sie für Maker interessant sind, enthalten in der Regel wenigstens 1000 Logikzellen.

Neben den Logikzellen befinden sich auf einem FPGA noch weitere Basisbausteine, die hier jetzt nur kurz erwähnt werden (Ausprägung und Menge hängen wieder stark vom FPGA-Typ ab):

I/O-Zellen: Spezielle Elemente, welche die Verbindung zwischen den Pins und den weiteren Resourcen des FPGAs herstellen. Zum Teil befinden sich dort auch Flip-Flops, welche z.B. zum Abtasten eines Eingangssignals mit der Basisfrequenz des FPGAs verwendet werden können. Auch spezielle Schaltungen z.B. zum Interfacing mit Schnittstellen wie dem PCI-Bus sind dort untergebracht.

Abbildung 3-4: Idealisierte Logikzelle

PLLs2 und Clock-Manager: FPGA-Boards enthalten häufig einen Quarzgenerator mit einer festen Frequenz, z.B. 100 MHz, der das FPGA mit einem zentralen Clock-Signal versorgt. Für verschiedenste Anwendungen werden jedoch Clock-Signale mit einer anderen Frequenz oder sogar mehrere Clock-Signale benötigt. Dafür sind PLLs und Clock-Manager zuständig.

Embedded Memory: Für manche Anwendungen ist es vorteilhaft, dediziertes RAM zu verwenden, anstatt die in den Logikzellen vorhandenen Flip-Flops als Speicher zu verwenden.

DSP-Blöcke3: Wichtig für die digitale Signalverarbeitung, wo z.B. eine »Multiply and Accumulate«-Operation sehr häufig vorkommt. Diese Funktion steht (neben anderen Merkmalen) in DSP-Blöcken in optimierter Form zur Verfügung.

Infrastruktur zum Routen und Transportieren von Signalen

Spezielle Transceiver-Einheiten für die schnelle serielle Kommunikation mit anderen Chips

Es ergibt sich somit für den inneren Aufbau eines FPGA eine Struktur, wie sie in Abbildung 3-5 dargestellt ist. Die dort mit »int« (wie Interconnection) bezeichneten Blöcke stellen die für die Verbindungen zuständige Infrastruktur dar. Mit ein wenig Phantasie kann man sich vorstellen, dass es mit steigender Ressourcenausnutzung des FPGA immer schwieriger wird, die erforderlichen Verbindungen so anzulegen, dass nirgendwo Engpässe entstehen, welche die Funktionalität und Stabilität der im FPGA realisierten Schaltung beeinträchtigen. Dies ist durchaus mit der Situation im Straßenverkehr zu vergleichen, wie wir sie häufig in Deutschland in Ballungsgebieten vorfinden. Ein entscheidender Unterschied bei diesem Vergleich ist jedoch, dass das Umfahren eines Staus im Straßenverkehr zwar lästig, in der Regel aber in Ordnung ist, solange man sicher an sein Ziel kommt. Im FPGA bedeutet ein Umweg jedoch automatisch längere Laufzeiten für die betroffenen Signale. Es muss dann sichergestellt sein, dass dies noch akzeptabel ist und nicht dazu führt, dass sich das algorithmische Verhalten ändert. Dazu gibt es in den Entwicklungswerkzeugen spezielle Tools, z.B. für die Timing-Analyse. Im Kontext dieses Buchs werden wir mit solchen Problemen aber eher nicht konfrontiert, weil die hier vorgestellten Applikationen das FPGA längst nicht so auslasten, dass solche Dinge eine entscheidende Rolle spielen. Als Faustformel kann man sich merken, dass man sich bei einer Ressourcenauslastung von ≤ 50% in der Regel im grünen Bereich bewegt, in dem keine besonderen Anstrengungen erforderlich sind, um das Design sicher zum Laufen zu bekommen.

Abbildung 3-5: Prinzip-Blockdiagramm eines FPGA

Bei Betrachtung von Abbildung 3-5 kann man sich außerdem vorstellen, dass man die Eigenheiten und Merkmale des verwendeten FPGA im Detail kennen muss, wenn man ein optimiertes Design erstellen möchte. Von kleinen Ausnahmen abgesehen, werden wir in diesem Buch aber nicht bis zu diesem Level vordringen, sondern in der Regel generische Konstrukte zur Hardwarebeschreibung verwenden, die dann auch für diverse FPGAs von verschiedenen Herstellern nutzbar sind.

3.2 Entwicklungsablauf im Überblick

Nachdem nun zumindest im Prinzip klar ist, wie ein FPGA funktioniert, geht es im nächsten Schritt darum zu beschreiben, wie man ein Design, im Laborjargon formuliert, »auf einem FPGA ans Laufen bekommt«. Mit Design ist hier immer eine Schaltung gemeint! Auch wenn im Folgenden einiges sich so »anfühlt« wie Softwareentwicklung, hier geht es um den Entwurf und die Realisierung von Hardware!

In Abbildung 3-6 ist der grundsätzliche Entwicklungsablauf (oder auf Neudeutsch Workflow) dargestellt, wie wir ihn anwenden werden. Dieser Ablauf wird komplett von jeder (frei verfügbaren) FPGA-Entwicklungssoftware unterstützt, die in diesem Buch vorgestellt wird. Natürlich gibt es in den Details Unterschiede, aber der grundsätzliche Ablauf ist überall gleich.

Abbildung 3-6: FPGA-Entwicklungsablauf

Es beginnt mit der Spezifikation. Darin muss festgelegt werden, was die zu entwickelnde Schaltung leisten soll, wie die Schnittstellen zur Außenwelt aussehen, etc. Aus diesen Anforderungen ergibt sich auch, welches FPGA-Board für das Projekt geeignet ist.

Mit »Design Entry« ist die Eingabe des Designs mit der FPGA-Entwicklungssoftware gemeint. In diesem Buch wird zur Hardwarebeschreibung die Sprache »VHDL« benutzt. Neben weiteren Beschreibungssprachen stehen dafür u.a. noch folgende Möglichkeiten zur Verfügung:

Schematic Entry – Eingabe per Schaltplan. Diese Beschreibungsart wurde früher ausschließlich benutzt. Auf den ersten Blick scheint sie gerade für den Anfänger leichter zu sein als eine Hardwarebeschreibungssprache. Dieser vermeintlichen Einfachheit stehen jedoch schwerwiegende Nachteile entgegen. So sind Schaltpläne kaum von einer FPGA-Entwicklungssoftware in das Paket eines anderen Herstellers portierbar. Dieser Aspekt ist u.a. im Kontext von »Open Source« bzw. »Open Hardware« sehr wichtig4. Auch können in Schaltplänen nicht wie in einem Texteditor bestimmte Ausdrücke automatisch gesucht und ggf. ersetzt werden. Ab einem bestimmten Designumfang werden Schaltpläne auch sehr unhandlich.

Verwendung der MathWorks-Produkte »MATLAB« und »Simulink« zur Modellierung/Simulation und »HDL Coder« zur automatischen Codegenerierung. Dies ist für Maker allein aus Kostengründen kein praktikabler Weg. Abgesehen von diesem Aspekt ist es aber auch sehr sinnvoll, den Workflow auf die traditionelle Art und Weise zunächst von Grund auf zu lernen, bevor man sich mit automatischer Codegenerierung befasst.

Verwendung der Programmiersprache C, anschließend halb automatische Konvertierung in eine Hardwarebeschreibungssprache. In diesem Bereich existiert z.B. das Framework »OpenCL«, welches C zur Modellierung heterogener Systeme benutzt. Dieser Weg wird von Altera unterstützt. Von Xilinx gibt es auch einen auf C basierenden Workflow mit dem Namen »HLS« (High Level Synthesis), der seit kurzem sogar im Rahmen der kostenlosen Webpack-Edition von Vivado verfügbar ist. Für diese und andere Lösungen in dieser Richtung gilt nach Meinung des Autors jedoch auch, dass eine Beschäftigung damit erst dann Sinn macht, wenn eine solide Grundlage mit dem klassischen Ansatz – basierend auf einer Hardwarebeschreibungssprache – vorhanden ist.

Nach der der Eingabe des Designs (hier wird von der Verwendung von VHDL ausgegangen) erfolgt sinnvollerweise eine Analyse. Dabei wird die Schaltungsbeschreibung auf Dinge wie syntaktische Korrektheit überprüft. Die Analyse erfolgt entweder als automatischer Hintergrundprozess während der Designeingabe oder wird vom Anwender explizit »angestoßen«.

Wenn die Analyse erfolgreich durchlaufen wurde, kann eine funktionale Simulation durchgeführt werden. Natürlich kann es spannender sein, das Design sofort auf einem Board zu testen, aber durch eine Simulation erkennt man viel besser, ob das Design überhaupt funktionieren kann. Bei komplexeren Projekten ist die erste Designversion meistens nicht fehlerfrei, und in einer Simulation findet man Fehler viel bequemer und schneller als direkt auf einem Board. Um eine Simulation durchführen zu können, muss eine sog. »Testbench« erstellt werden – Details dazu folgen später. An dieser Stelle sei nur noch erwähnt, dass sich dieser Mehraufwand lohnt und dass man die Erstellung einer Testbench nicht lange vor sich herschieben sollte.

Wenn man davon ausgehen kann, dass das Design auch funktional in Ordnung ist, folgt als nächster Schritt die Synthese. Dieser Punkt wird automatisch durch die Software abgearbeitet, manuelle Interaktion ist höchstens zum Einstellen von Parametern erforderlich, welche einen Einfluss auf diesen Prozess haben. In der Synthesephase erfolgt eine Abbildung der verwendeten Designelemente (hier: Konstrukte in VHDL-Code) auf Schaltungselemente, welche das FPGA, für das entwickelt wird, zur Verfügung stellt.

Im Prozessteil Place/Route erfolgt – bei zuvor erfolgreich durchgeführter Synthese – das Platzieren und Verbinden der während der Synthese ermittelten Elemente. Dabei laufen im Hintergrund sehr ausgeklügelte Optimierungsverfahren ab, so dass unter Berücksichtigung vieler Einflussfaktoren (Laufzeiteffekte, Signalintegrität, Datendurchsatz etc.) eine optimale Anordnung und Verschaltung der Basiselemente gefunden wird (wenn alles glatt geht). Im Extremfall kann es auch passieren, dass der Place/Route-Lauf erfolglos abgebrochen wird und man zurück zum Design-Entry gehen muss, um das Design zu ändern. Dies kommt in der industriellen Praxis vor, bei den in diesem Buch vorgestellten Projekten jedoch garantiert nicht.

Wenn Place/Route geklappt hat, ist als Nächstes die Erzeugung der Konfigurationsdaten für das FPGA dran, in den Tools meistens als »Bitstream Generation« bezeichnet. Die Bits dieses »Streams« legen fest, welcher »Konfigurationsschalter« (Bezug: Abbildung 3-1 auf Seite 10) wie gesetzt wird. Auch »Bitstream Generation« läuft vollkommen automatisch ab.

Zum Schluss wird das FPGA mit dem erzeugten Bitstream konfiguriert. Während der Entwicklung läuft dies in den meisten Fällen so ab, dass über ein Download-Utility, welches Bestandteil der jeweiligen FPGA-Entwicklungsumgebung ist, der Bitstream über ein JTAG-Interface5 (welches wiederum meistens via USB mit dem Entwicklungs-PC verbunden ist) auf das FPGA geladen wird. Bei vielen FPGA-Boards ist das JTAG-Interface bereits auf dem Board vorhanden, ansonsten ist ein externer Adapter erforderlich, der oft als »Download Cable« o.Ä. bezeichnet wird.

3.3 VHDL-Einführung

VHDL ist eine Hardwarebeschreibungssprache. Der Name dieser Sprache ist auch eine Abkürzung und steht für »Very High Speed Integrated Circuits Hardware Description Language«. Die Sprache wurde in den 1980er-Jahren entwickelt und standardisiert, die erste offizielle Version erschien 1987. Weitere Versionen des Standards folgten 1993, 2002 und 2008. Wie bei anderen (Programmier-)Sprachen auch wurden Neuerungen von den Tool-Herstellern nicht immer zeitnah umgesetzt. Bis heute ist der Standard VHDL-2008 längst nicht in allen Werkzeugen vollständig umgesetzt. Daher werden in diesem Buch in der Regel nur VHDL-Konstrukte verwendet, die auch mit VHDL-93 funktionieren (dies ist in manchen Werkzeugen immer noch die Default-Einstellung für den VHDL-Sprachstandard).

»Hardware Description Language« ist aber nicht die ganze Wahrheit. Ein Teil von VHDL dient nämlich nur zur Erstellung von Simulationen (sog. Test Benches). Mit anderen Worten, bestimmte VHDL-Konstrukte können nicht in Hardware umgesetzt werden, man spricht dann auch von »nicht synthetisierbaren VHDL-Ausdrücken«. Alle synthetisierbaren VHDL-Konstrukte können aber auch zur Simulation verwendet werden (mit der Ausnahme von speziellen herstellerspezifischen Anweisungen zur Steuerung der Synthese, die von den Simulationswerkzeugen normalerweise einfach ignoriert werden).

Die komplette Sprache ist ziemlich umfangreich. Zudem lebt VHDL, ähnlich wie die Programmiersprache C, auch von Libraries, ohne die VHDL gar nicht sinnvoll eingesetzt werden kann. In diesem Buch wird daher nur ein Subset von VHDL verwendet, der für den Einstieg und anschließende Projekte vollkommen reicht.

Neben VHDL gibt es u.a. noch Verilog (bzw. System Verilog als neueste Version) zur Beschreibung von Hardware und den zugehörigen Simulationen. Beide Sprachen haben ihre speziellen Merkmale, die je nach Betrachtungsweise als Vor- oder Nachteil angesehen werden können. Verilog wird in den USA bevorzugt, während in Europa VHDL stärker vertreten ist.

Auch wenn in diesem Buch VHDL benutzt wird, folgt weiter hinten ein kurzes Kapitel zu Verilog. Dort geht es vor allem um die Integration von in Verilog geschriebenen Modulen in VHDL-Projekte; Verilog und VHDL können in der Regel (das hängt letztendlich von den verwendeten Werkzeugen ab) sowohl für die Synthese als auch die Simulation im Gemischtbetrieb genutzt werden.

Das Standardbuch für VHDL ist [2], dort wird der gesamte Sprachumfang ausführlich erläutert.

3.4 Eine erste Dosis VHDL

Nach dieser Vorrede kommt nun ein erstes Beispiel zur Einführung von VHDL.

Die Spezifikation lautet: Zwei Eingangssignale ›in1‹ und ›in2‹ sollen UND-verknüpft werden, das Ergebnis soll ›out_and‹ sein. Bei einer Realisierung mit einem FPGA-Board würden die Eingangssignale durch Schalter gespeist, das Ausgangssignal würde auf eine Leuchtdiode geschaltet.

Das folgende Listing (Listing 3-1) zeigt das File and_logic.vhd; die Zeilennummern tauchen hier nur zu Referenzzwecken auf und sind in dem eigentlichen Quellfile nicht enthalten. In diesem File wird die gerade spezifizierte Funktionalität implementiert.

Listing 3-1: and logic.vhd

 1     -- and_logic.vhd 2 3     library ieee; 4     use ieee.std_logic_1164.all; 5 6     entity and_logic is 7       port 8       ( 9         in_1 : in std_logic;10         in_2 : in std_logic;11         out_and : out std_logic12       );13     end and_logic;1415     architecture impl of and_logic is16     begin17       out_and >= in_1 and in_2;18     end impl;

Zeile 1 ist eine Kommentarzeile. Kommentare in VHDL beginnen mit der Zeichenkette --.

Zeile 2 ist einfach eine Leerzeile. In Bezug auf sog. Whitespace (also Leerzeichen, Tabs, Zeilenumbrüche, Leerzeilen) verhält sich VHDL gutmütig. Dies gilt auch für Groß-/Kleinschreibung, sie hat in VHDL keinerlei Bedeutung!

In Zeile 3 wird eine Library eingebunden, hier »ieee«. In Zeile 4 wird auf diese Library Bezug genommen, ein Teil von »ieee« wird zur Verwendung in diesem VHDL-File definiert, der komplette Inhalt (».all«) des Teils »std_logic_1164« (was sich dahinter verbirgt, wird später erläutert). Wer die Programmiersprache C kennt, fühlt sich jetzt wahrscheinlich an Header-Files erinnert; diese Assoziation passt auch ganz gut. Auch in VHDL sind wesentliche Teile des Sprachumfangs in Libraries definiert. Ein VHDL-File ohne wenigstens ein library- und use-Statement zu Beginn ist sinnlos.

Die Zeilen 6 bis 13 enthalten ein entity-Konstrukt. Damit wird beschrieben, welche Ein- und Ausgänge die Schaltung hat und wie sie heißt. Wenn man sich die Schaltung exklusiv in einem Gehäuse vorstellt, entspricht dies der Beschreibung der »Verpackung« im Sinne einer Black Box. Es wird festgelegt, welche Signale hinein- und hinausgehen, welche Namen sie haben und welchen Datentyp. Es wird an dieser Stelle jedoch nichts darüber ausgesagt, wie die Black Box intern arbeitet. Auch wird hier nicht festgelegt, auf welche realen I/O-Pins des FPGAs die Ein- und Ausgänge »aufgelegt« werden (wie das geschieht, folgt später). Hier enthält das entity-Konstrukt als Unterelement port6, worin jedes Eingangs- und Ausgangssignal des »Chips« aufgelistet wird.

Die I/O-Defininition ist eigentlich recht einfach: In Zeile 9 wird beispielsweise beschrieben, dass es ein Signal mit dem Namen in_1 gibt, das ein Eingangssignal ist (in-Attribut nach dem Doppelpunkt) und das den Datentyp std_logic7 hat.

Die Zeilen 15 bis 18 enthalten ein architecture-Konstrukt. Damit wird die eigentliche Funktion der Schaltung beschrieben. Der Bezeichner impl in Zeile 15 ist willkürlich gewählt und steht für »implementation«. Oft sieht man an dieser Stelle auch »behavioral« oder »rtl« (für »register transfer level«). Dieser Bezeichner ist auch nur erforderlich, weil VHDL die Möglichkeit bietet, zu einer entity-Definition mehrere architecture-Definitionen anzulegen. Das kann z.B. interessant sein, wenn man verschiedene Implementierungsvarianten durchspielen will. Es muss dann natürlich festgelegt werden, welche Architektur verwendet werden soll. Solange nur ein architecture-Konstrukt auftaucht, ist die Sache eindeutig.

In Zeile 17 erfolgt eine Zuweisung an out_and mit Hilfe der Zeichenkette <= (also nicht =). Auf der rechten Seite von <= erfolgt die UND-Verknüpfung der beiden Eingangssignale, dazu wird in VHDL das Schlüsselwort and benutzt. Auch wenn sich Zeile 17 fast wie ein Statement in C liest, wird hier keine Anweisung für einen Prozessor erzeugt, sondern eine UND-Schaltung in Hardware mit zwei Eingängen und einem Ausgang, vgl. Abbildung 3-7!

Abbildung 3-7: Generiertes UND-Gatter

Listing 3-2: simple_logic.vhd

 1     -- simple_logic.vhd 2 3     library ieee; 4     use ieee.std_logic_1164.all; 5 6     entity simple_logic is 7       port 8       ( 9         in_1 : in std_logic;10         in_2 : in std_logic;11         out_and : out std_logic;12         out_or : out std_logic13       );14     end simple_logic;1516     architecture impl of simple_logic is1718     begin19       out_and <= in_1 and in_2;20       out_or <= in_1 or in_2;21     end impl;

Es wird parallel zu dem UND- noch ein ODER-Gatter generiert, vgl. Abbildung 3-8.

Beide logischen Operationen werden auf der Hardware absolut parallel (oder nebenläufig) ausgeführt. Bei einer Realisierung auf einem Mikrocontroller würden die beiden Operationen nacheinander ausgeführt.

Gerade wenn man bereits einige Erfahrung mit hardwarenaher Programmierung (z.B. mit Arduino, Raspberry Pi, ...) hat, muss man sich immer wieder klarmachen, dass beim FPGA die Dinge gleichzeitig ablaufen, auch wenn im VHDL-Code das Statement für die UND- bzw. ODER-Operation hintereinander stehen.

Abbildung 3-8: Parallelschaltung von UND- und ODER-Gatter

3.4.1 Erste Testbench

Der nächste Schritt ist, die entworfene Schaltung zu simulieren. Dazu wird – ebenfalls in VHDL – eine sog. Testbench erstellt. Das ist ein VHDL-File, welches das eigentliche Design einbindet und mit Stimulus-Signalen an den Eingängen versorgt. Mit einem Simulator (Bestandteil der FPGA-Entwicklungsumgebung) wird die Testbench ausgeführt (dazu wird die Testbench automatisch compiliert), als Ergebnis erhält man einen Plot von Ein- und Ausgangssignalen, anhand dessen man die Funktion überprüfen kann8.

Listing 3-3 zeigt die Testbench für simple_logic.vhd. Die Testbench selbst ist hier in der Datei simple_logic_tb.vhd untergebracht. Das Anhängen von _tb an den Dateinamen des Files mit der zu testenden Schaltung ist lediglich eine sinnvolle Konvention, aber kein »Muss«.

Listing 3-3: simple_logic_tb.vhd

 1     -- simple_logic_tb.vhd 2     -- 3     -- test bench for simple_logic 4 5     library ieee; 6     use ieee.std_logic_1164.all; 7 8     entity simple_logic_tb is 9     end simple_logic_tb;1011     architecture sim of simple_logic_tb is12       component simple_logic13         port14         (15           in_1 : in std_logic;16           in_2 : in std_logic;17           out_and : out std_logic;18           out_or : out std_logic19         );20       end component;2122       signal in_1_sim : std_logic;23       signal in_2_sim : std_logic;24       signal out_and_sim : std_logic;25       signal out_or_sim : std_logic;2627     begin28       dut : simple_logic29       port map30       (31         in_1 => in_1_sim,32         in_2 => in_2_sim,33         out_and => out_and_sim,34         out_or => out_or_sim35       );3637       process38       begin39         in_1_sim <= '0';40         in_2_sim <= '0';4142         wait for 50 ns;43         in_1_sim <= '1';44         in_2_sim <= '0';4546         wait for 50 ns;47         in_1_sim <= '0';48         in_2_sim <= '1';4950         wait for 50 ns;51         in_1_sim <= '1';52         in_2_sim <= '1';5354         wait;55       end process;5657     end sim;

In den Zeilen 8 und 9 wird in simple_logic_tb.vhd eine leere »Entity« angelegt, da in der Testbench selbst keine neue Hardware beschrieben wird, sondern bereits zuvor definierte Hardware getestet werden soll.

Ab Zeile 11 folgt der architecture-Teil. Es fällt in simple_logic_tb.vhd im Vergleich mit simple_logic.vhd auf, dass zwischen den Schlüsselworten architecture (Zeile 11) und begin (Zeile 27) nun VHDL-Statements stehen, während dieser Bereich in simple_logic.vhd leer ist.

In den Zeilen 12 bis 20 erscheint ein component-Konstrukt. Damit wird Bezug genommen auf eine Hardwaredefinition, die schon (außerhalb des aktuellen Files) vorgenommen wurde und die nun verwendet werden soll. Beim Vergleich der Zeilen 12 bis 20 in simple_logic_tb.vhd mit den Zeilen 6 bis 14 in simple_logic.vhd (Listing 3-2) bemerkt man, dass sich jeweils nur die erste und die letzte Zeile voneinander unterscheiden. Der eigentliche Inhalt – die Beschreibung der I/O-Schnittstelle der Schaltung, die durch den Code in simple_logic_tb.vhd getestet werden soll – ist gleich!

Die Zeilen 22 bis 25 von simple_logic_tb.vhd enthalten signal-Definitionen. In VHDL wird signal für schaltungsinterne Verbindungen genutzt, die nicht von außen »sichtbar« sind. Daher werden die signal-Elemente auch in dem Abschnitt architecture angelegt und nicht in entity. Für jedes Ein- bzw. Ausgangssignal des zu testenden Systems (DUT, »Device Under Test«) wird hier das »Gegenstück« angelegt. Sehr häufig bekommen diese Signale denselben Namen wie das korrespondierende Ein- bzw. Ausgangssignal des DUT, was aber gerade für Anfänger verwirrend sein kann. Daher wird hier für die internen Signalnamen die Endung _sim benutzt.

In Zeile 28 wird in der Testbench eine Instanz von simple_logic angelegt. In den Zeilen 29 bis 35 wird diese Instanz mit den oben angelegten Signalen der Testbench verbunden. Somit ergibt sich die in Abbildung 3-9 dargestellte Situation.

In den Zeilen 37 bis 55 werden die Stimuli für die Eingänge des DUT generiert9. Nachdem alle Stimuli erzeugt wurden, wird die Simulation quasi in den Wartemodus versetzt (wait, Zeile 54).

Abbildung 3-9: Verbindung von Testbench und DUT

Wenn die Testbench syntaktisch korrekt ist, kann sie mit einem VHDL-Simulator ausgeführt werden. Abbildung 3-10 zeigt das Ergebnis eines Testlaufs. Alle in der Testbench definierten Signale werden automatisch angezeigt, dazu sind keine separaten Statements erforderlich.

Abbildung 3-10: Simulationsergebnis für simple_logic

3.5 Notwendige Ausstattung

Wer bis hier aktiv mitgemacht bzw. eher mitgedacht hat, möchte nun sicherlich die erlernte Theorie in der Praxis anwenden. Es gibt jetzt folgende Möglichkeiten:

Der finanzielle Aufwand soll zunächst minimal sein. Daher wird nur VHDL-Code entwickelt und simuliert. Ein FPGA-Board wird zunächst nicht angeschafft. Zur Simulation kann entweder die kostenlose Version der FPGA-Entwicklungsumgebung eines beliebigen FPGA-Herstellers verwendet werden oder »GHDL«10.

Es wird ein FPGA-Board beschafft bzw. ein schon vorhandenes Board wird benutzt. Das Board wird entsprechend den Ambitionen und dem zur Verfügung stehenden Budget ausgewählt. Man kann ein Board kaufen, das von einem größeren Hersteller stammt, sämtliche gewünschten Peripherieelemente enthält, mit einer guten Dokumentation daherkommt und noch viel »Luft« für Projekte bietet, die man in der fernen Zukunft evtl. einmal angehen möchte (z.B. ein System-On-Chip-Design mit Mikrocontroller-Core und FPGA-Anteil). Oder man wählt zunächst ein kleineres Board, das nicht sämtliche Peripherie bietet, die man vielleicht einmal benutzen möchte, wo die Dokumentation evtl. nicht ganz so gut ist, welches dafür aber billiger zu bekommen ist. Peripherie kann man ggfs. auch selbst später »andocken«, wenn man z.B. auch noch Spaß am ganz klassischen Hardwaredesign (mit Platinenlayout etc.) hat, oder man kauft fertig verfügbare Module dazu. Im Anhang finden sich Informationen, die bei der Frage »Welches Board soll ich nehmen?« weiterhelfen.

Die meisten Maker werden wahrscheinlich Möglichkeit 2 wählen, dem wird im Folgenden auch entsprechend Rechnung getragen. Sobald man sich für ein Board entschieden hat, ergibt sich daraus auch, welche FPGA-Entwicklungsumgebung verwendet wird, nämlich die des entsprechenden FPGA-Herstellers. Es macht zu Anfang nicht wirklich Sinn, gleich mit mehreren verschiedenen Entwicklungsumgebungen parallel zu arbeiten. Erst nachdem man mit einer Umgebung ein gewisse Vertrautheit erlangt hat, sollte man erwägen, eine weitere FPGA-Entwicklungsumgebung auszuprobieren.

Wenn man noch kein Board hat und auch noch nie mit einer FPGA-Entwicklungsumgebung gearbeitet hat, kann man aber auch so vorgehen, dass man vor dem Kauf eines FPGA-Boards die entsprechende Entwicklungsumgebung installiert und sie ausprobiert. Wenn sie einem gar nicht zusagt, kann man sich dann immer noch für ein Board mit einem FPGA eines anderen Herstellers (und somit auch einer anderen FPGA-Entwicklungsumgebung) entscheiden.

Teil II

Einfache Schaltungen

4 Los geht’s – das erste FPGA-Projekt

4.1 Einführung

Unser erstes Projekt ist eine Logikdemo. Wir realisieren logische Grundschaltungen (AND, OR, ...) und benutzten ein FPGA-Board zum Ausprobieren. Als Außenbeschaltung verwenden wir zwei Schalter, welche die Eingangspegel der logischen Grundschaltungen festlegen, sowie Leuchtdioden (entsprechend der Anzahl der logischen Grundschaltungen). Als Startpunkt verwenden wir das bereits im vorherigen Kapitel vorgestellte VHDL-File simple_logic.vhd (Listing 3-2).

Im Folgenden wird die Realisierung für das FPGA-Board »ARTY« ausführlich dargestellt1. ARTY – Abbildung 4-1 zeigt dieses Board – enthält ein Xilinx-FPGA der Artix-7-Familie, benutzt wird die Toolkette »Vivado« in der kostenfreien »WebPACK«-Version. Äquivalente Beschreibungen für weitere Boards (mit anderen FPGAs und anderen Toolketten von Altera, Lattice, Microsemi und Xilinx (die ältere ISE-Umgebung)) befinden sich im Anhang. Dort wird auf das VHDL-Projekt fpga_basic Bezug genommen, welches später vorgestellt wird und ein wenig mehr als logische Grundschaltungen enthält.

Abbildung 4-1: ARTY

Der erste Schritt vor der Verwendung eines neuen FPGA-Boards ist neben dem Kauf des Boards die Beschaffung von Informationen:

Benutzerhandbuch: Ist in der Regel auf der Homepage des Herstellers beziehungsweise Distributors verfügbar. Falls kein solches Dokument verfügbar ist, sollte man (auf jeden Fall als Anfänger) die Finger von dem Board lassen.

Schaltplan: siehe Benutzerhandbuch

Support-Files für das Board, insb. ein sog. Constraints-File (wird weiter hinten erklärt)

Das Board sollte über ein »eingebautes« Debug- bzw. Programmier-Interface mit USB-Schnittstelle verfügen, so dass außer einem USB-Kabel keine weitere Hardware zum Übertragen der Konfigurationsdaten von dem Entwicklungs-PC auf das Board erforderlich ist. Allein ein JTAG-Interface reicht nicht; dann ist meistens noch ein sog. »Programming Cable« erforderlich, das schnell mit einem dreistelligen Euro-Betrag zu Buche schlägt.