CRE117 FPGA

Wie man sich seine eigene Hardware herbeiprogrammiert

Episode image forCRE117 FPGA 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.

Dauer: 1:28:34

On Air
avatar Tim Pritlove Paypal Icon Bitcoin Icon
avatar Benedikt Heinz
Shownotes:

Links:

12 Gedanken zu “CRE117 FPGA

  1. 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 ;)

  2. 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.

  3. 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?

  4. 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.

  5. Pingback: CRE151 Die ARM-Architektur | CRE: Technik, Kultur, Gesellschaft

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *