Wie man sich seine eigene Hardware herbeiprogrammiert
FPGA und und CPLD sind Technologien, die es erlauben, sich seine eigenen Spezial-Chips zu bauen, ohne dabei selbst Hardware herstellen zu müssen. Im Gespräch mit Tim Pritlove erläutert Benedikt Heinz anhand Details eigener Projekte die Grundlagen, die zum Verständnis von selbstprogrammierbarer Hardware erforderlich ist.
Shownotes
Links:
- Benedikt Heinz
- WP: Digital Visual Interface (DVI)
- WP: Phase Alternating Line (PAL)
- WP: RGB-Signal
- WP: ATA/ATAPI
- WP: FireWire
- WP: Field Programmable Gate Array (FPGA)
- WP: Mikrocontroller
- CRE067 Microcontroller
- WP: Logikgatter
- WP: Boolesche Algebra
- WP: Logische Verknüpfung
- WP: Gate Array
- WP: Lookup-Tabelle
- WP: Random Access Memory
- WP: IP-Core
- OpenCores
- WP: Endlicher Automat (finite state machine)
- WP: Verilog
- WP: Very High Speed Integrated Circuit Hardware Description Language (VHDL)
- WP: Flipflop
- WP: Farbraum
- WP: YUV-Farbraum
- Transition Minimized Differential Signaling (TMDS)
- WP: Flash-Speicher
- WP: Serial Peripheral Interface
- WP: Intel MCS-51 (8051)
- WP: ARM-Architektur
- Atmel AVR
- WP: PicoBlaze
- WP: MicroBlaze
- WP: Pipeline
- WP: MIPS-Architektur
- WP: Sun SPARC
- OpenSPARC
- XILINX
- Altera
- WP: Memory Mapped I/O
- WP: PowerPC
- WP: Reverse Engineering
- WP: Amiga 500
- WP: Dual-Port-RAM
- WP: GHDL VHDL simulator
- WP: Compute Unified Device Architecture (CUDA)
- WP: OpenCL
Der Link zum Podcast ist leicht falsch. Korrekte URL:
http://cre.fm/cre117-fpga
Cool, endlich, interessiert mich sehr, hör ich gleich morgen in der Badewanne.
Der Amiga, oder besser das Board http://en.wikipedia.org/wiki/Minimig erfreut sich großer Beliebtheit und wir auch verkauft.
http://de.wikipedia.org/wiki/C-One für den C64 …
Hab nochmal nachgeguckt und gemerkt dass ich Mist erzählt hab: multiplizieren geht schon in einem Takt: http://de.wikipedia.org/wiki/Multiplizierer_(Digitaltechnik)
@hunz
war das nich MAD, was immer ewig dauert(e)?
Sehr schöner Podcast. Leider ein wenig kurz. Hätte es schön gefunden wenn auch SystemC zur Sprache gekommen wäre: http://de.wikipedia.org/wiki/SystemC
Auch hätte das Thema adaptiver Rechner Erwähnung finden können. Eine kurze Einführung dazu kann man hier finden: http://www.eis.cs.tu-bs.de/eis/research/current/researchHG.htm
Aber trotzdem danke dafür, dass ihr über das Thema FPGA geredet habt.
SystemC waere tatsaechlich noch schoen gewesen. Vielleicht gibt es ja auch Stoff fuer nen eigenen Podcast.
Eine weiter opensource IP Quelle ist auch noch die GRLIB von http://www.gaisler.com . Dort ist auch ein Multiprozessor faehiger SPARC core enthalten.
Noch eine kleine Anmerkung. Man kann meines Wissens nach auch mit nur NOR- oder nur NAND-Gatter alle logischen Funktionen aufbauen. Da kommen grausame Schulerinnerungen hoch. De Morgan lässt grüßen. Lustig war auch wie Tim immer wieder das Wort Gatter aussprach, als wäre das was furchteinflößendes ;)
Ja juchu, der 30.3. ist der Tag, an dem ich über genau das Tema eine Klausur schreiben durfte. Also FPGA VHDL etc. Selten, dass etwas so auf den Tag genau passt. Leider ist der Podcast nur zu spät gekommen, um mir noch zu helfen. Hab die Klausur aber auch ohne Chaos Radio bestanden.
Hi, ein schönes Thema. Leider ist Tim des ganzen ja schon relativ früh müde geworden. Einen schönen Überblick stellt das ganze trotzdem dar.
Mich haben manchmal Formulierungen wie „es ist alles zur gleichen Zeit im FPGA drin und wird auch ausgeführt“ gestört. Ok, ein Programmierer kann damit vielleicht schneller etwas anfange, aber man kommt besser auf den Trichter, was man bei der Hardwarebeschreibung (nicht Programmierung) für einen FPGA machen muss, wenn man sich vor Augen hält, dass man kein Programm schreibt, das ausgeführt wird, sondern eine Schaltung baut, wo Spannung angelegt wird und Strom fließt. Und wenn man die Schaltung halt so aufgebaut hat, dass alle Teile gleichzeitig aktiv sind, dann werden halt alle gleichzeitig von Strom durchflossen, und je nach Signalen am Eingang liegen nach kurzer Zeit entsprechende Signale an allen Ausgängen an.
Hier passt auch mein Senf zu VHDL:
Das ist eine furchtbare Sprache. Sie ist zwar sehr mächtig in der Hardwarebeschreibung, aber auch mächtig und inkonsistent in sachen Syntax. Dadurch ist sie ätzend zu lesen. Schwer zu verstehen sind die in VHDL geschriebenen Konstrukte oft auch, und das liegt meiner Meinung daran, dass sie gerade den Unterschied zwischen Programmierung und Hardwarebeschreibung nicht klar werden lässt. Sie sieht aus wie eine Programmiersprache (Ada ist schon richtig, oder Pascal), beschreibt aber keine Algorithmen, sondern Netze. Dann kommt aber noch hinzu, dass es zusätzlich zu den Beschreibungen von Signalverknüpfungen noch sowas wie Schleifenkonstrukte und Variablen gibt. Diese Konstrukte sind eigentlich nur sowas wie Makros, die einem zum Beispiel Schreibarbeit beim Belegen von großen Signalvektoren abnehmen. Blöderweise heben sie sich aber nicht von der Schaltungsbeschreibung ab und erwecken so den Eindruck, man hätte es mit einem Algorithmus zu tun, der in der Schaltung läuft.
Ich glaube Verilog ist da recht ähnlich, obwohl ich noch nicht viel Zeit mit dieser Sprache verbracht habe. Interessant finde ich Ansätze wie JHDL (Java based Hardware Description Language), welche die Hardware durch richtige Objekte beschreibt. Leider hatte ich auch noch nicht viel Zeit mich damit zu beschäftigen. Wenn ich richtig viel Zeit hätte, dann würde ich mir Gedanken über eine Sprache machen, welche die Funktion von einzelnen „Hardwarebrocken“
in einer schönen reinen funktionalen Sprache beschreibt und diese dann objektorientiert miteinander verknüpft. Ideen bitte hierhin: http://notes.setvisual.de/HDL (jetzt noch leere Wikiseite).
Zu dem Thema synthetisieren: Ja, das ist eine verdammt komplexe Aufgabe. Ich verstehe zwar auch nicht, warum die Xilinx Tools so viel Platz auf der Platte brauchen, aber im Speicher ist das schon verständlich. Die müssen ja aus dem Code, den man da in einer Hochsprache geschrieben hat erstmal Gatterlogik bauen, die sie in Netzlisten speichern, und dann muss das ganze irgendwie auf die vorhandene Hardware gematcht werden, und zwar möglichst optimal. Wenn der Synthetisierer im FPGA zu lange Leitungen legt, kann es schon mal zu lange Signallaufzeiten geben, so dass signale in den falschen Takt reinlaufen oder so. Das ganze ist jedenfalls ein hässliches routing Problem, für das es einfach keine eleganten Algorithmen gibt. Oder?
Lustig, wenn Tim die Zuhörer an den Hörgeräten begrüßt. Wusste gar nicht, dass die CRE Hörerschaft im Schnitt SO alt ist.
Pingback: CRE151 Die ARM-Architektur | CRE: Technik, Kultur, Gesellschaft
Tippfehler auf der Webseite, doppelt und am Anfang.