Beispiele von Selbstlernenden Systemen & Robotern auf FPGA Basis

[NRicola]

Es dürfte also eher unwahrscheinlich sein, das sich jemand das zu Hobbyzwecken anschafft.

=> Ich schon...

Hallo zusammen,

ich möchte mal das Bild von FPGAs korrigieren. Wie gesagt bastel ich aktuell mit einem FPGA. Und das liegt nicht daran, dass ich bereit bin einen Vierstelligen Betrag für so ein Board und nochmal so viel für die Software auszugeben. Sondern es handelt sich tatsächlich um Bastelware für Jedermann (wenn auch nicht ganz sooooo günstig wie Arduinos oder RPis). Hier mal der Weg, den ich gegangen bin:

1. Xess (http://www.xess.com/):
Extrem gute Aufbereitung von Hardware und Tutorials. Ich hatte mir mal ein XuLA2-Board gegönnt, für sowas wie 120$ (glaub ich). Darauf war ein Spartan 6 (XC6SLX9). Nach aktuellem Stand würde ich sagen, dass man damit schon sehr viel machen kann - auch wenn man effektiv nur ca. 30 von 100 Pins des FPGAs nutzen kann (bzw. ein paar werden noch für die on-board Speicher verwendet). Aber für ein paar Motoren und Sensoren reicht das ja häufig. Und: Steckbretttauglich!

Dicker Pluspunkt: Super Dokumentation und damit toller Einstieg in die VHDL-Programmierung.
Dicker Minuspunkt: Mittlerweile kann man dort keine FPGA-Boards mehr erwerben.

Aktuell komm ich mit meinem noch völlig zurecht. Sollte ich mir mal was neues anschaffen müssen, wäre wohl

2. Trenz-Elektronik (https://shop.trenz-electronic.de/de/...nz-Electronic/) meine nächste Anlaufstelle. Die haben nicht nur vergleichbare Steckbrett-geeignete erschwingliche Boards, sondern auch die deluxeren Ausführungen mit dick RAM, den dickeren FPGAs (Kintex, Virtex und die krassen Ultrascale und besser - für den Fall, dass doch mal das eine oder andere Projekt ausartet) und man kann dort auch alle Pins des FPGA nutzen. Inwiefern man auf deren Boards auch die Tutorials von Xess umsetzen kann wäre mal eine interessante Frage. Sollte das jemand ausprobieren: bitte Bescheid geben!

Thema Software:
Ja, sie kostet viel. Aber: man braucht sie nicht. Es handelt sich um die kommerziellen Versionen, mit Super-Duper-Analyzing-Tools, bei denen man exzessive Timinganalysen und irgendwas machen kann. Braucht der Bastler nicht. Stichwort heißt: WebPack. Registrieren, frei herunterladen, Plug-and-Play-Installation. Ich hatte zumindest keine Probleme.

Wer mit einem Spartan 6, 3 (siehe z.B. c't Lab FPGA-Modul) oder älter anfangen möchte, benötigt das ISE WebPack 14.7. Das läuft zwar standardmäßig nicht mehr auf Win7 oder neuer. Aber wo ein Problem, da eine Lösung:
http://jacobpaulshaffer.com/Getting_..._on_Windows_10
Wer auf Spartan 7 und neuer aufspringt, sollte das Vivado Webpack nutzen können. Das habe ich selber aber noch nicht ausprobiert. Berichte dazu sind hier natürlich auch erwünscht.
Das Webpack bietet ausreichend Funktionen: Man kann nicht nur programmieren und kompilieren (Yeah!), sondern auch Simulationen und Floor-Planning durchführen.


Warum sollte man das jetzt auch noch tun und von PIC & Co weggehen? Achtung: es folgt Propaganda!
Geschwindigkeit und Flexibilität!
Geschwindigkeit: rein hardwarebedingt gehen Rechenoperationen (v.a. multiplikationen) schneller (nur ein Taktzyklus) als bei µCs. Warum, das habe ich nicht durchschaut, nur, dass es so ist.
Wenn da ein 12MHz-Quarz dranhängt (wie bei meinem XuLA2), heißt es nicht, dass ich auf 12MHz arbeiten muss. FPGA-intern kann man auf 300MHz (bei Spartan 6) hochskalieren - die neueren vertragen wohl auch 500MHz. Führt man nicht nur bei steigenden Flanken Operationen durch, sondern auch bei fallenden Flanken, ist man bei 1GHz. Oder man lässt es ohne Taktbezug durchlaufen - das ist am schnellsten, aber ob man es je mit anderen Prozessen wieder synchronisiert bekommt, ist die große Frage.

Außerdem (und das mag ich am meisten): Parallelisierung. Jeder Prozess, den man sich zusammenprogrammiert, arbeitet parallel zu allen anderen Prozessen. Ich kann also mit 12Mhz eine LED blinken lassen und parallel dazu irgendwelche komplexen Berechnungen durchführen. Egal wie und um was ich meinen Code erweitere, hat es keinen Einfluss auf das Timing bereits existierender Prozesse. Auch Subfunktionen, die N mal durchlaufen müssen kann ich parallel arbeiten lassen und erhalte das Ergebnis in der gleichen Durchlaufzeit, wie für einen einzigen Durchlauf benötigt wird.

Allerdings ist die interne "Verschaltung" der Prozesse etwas mühseliger. Da braucht man dann etwas mehr Aufwand, um da den Überblick nicht zu verlieren.

Und auch ganz nett: ich benötige eine Variable mit 4bit länge: ich definiere sie mir. Variable mit 35bit Länge: kein Problem...

Ich selber stehe da gewiss auch noch am Anfang von VHDL und FPGAs insgesamt. Aber mir macht es erheblich mehr Spaß, als eine µC-Programmierung und kann es deshalb nur jedem empfehlen.

Am Ende meiner aktuellen Bastelarbeit steht auch ein Machine Learning auf dem FPGA an. Allerdings muss ich dazu erstmal noch ein paar andere ToDos durchlaufen, ehe ich mich darum kümmern kann. Vielleicht kann ich dazu in einem oder zwei Jahren mal was schreiben.

In diesem Sinne!

Grüß, NRicola

[i_make_it]

=> Ich schon...

Tja, aber trotzdem nicht in den 347 Tagen zwichen dem ersten und dem zweiten Post gemeldet.
Da kommen dann halt auch so Schlussfolgerungen zustande.
Denn die Preise werden ja auch fast überall aufgerufen.
Leider ist die Hardware halt doch noch preislich oberhalb von µCs und mal eben in C einsteigen ist auch für ungeübte meist noch leichter als in VHDL
Für VHDL muß man ja erst mal ein Struktur und Zustände beschreiben, damit man weis was man programmierne will.

Mit GOTO lässt selbst Arduino C++ wilden Spagetticode und auch Anfänger bekommen meist ewas raus was zumindest dem Anschein nach das macht was sie wollen.

[NRicola]

Hallo i_make_it,

Tja, aber trotzdem nicht in den 347 Tagen zwichen dem ersten und dem zweiten Post gemeldet.

Das liegt daran, dass ich wirklich nichts wertvolles zu der Ausgangsfragestellung beitragen kann.

Zu deinen restlichen Kommentaren: ich bin programmiertechnisch eher eine Null<Komma>. C ist ok, C++ find ich auch nach mehreren Anläufen immernoch einen Krampf und alles andere als intuitiv zu lesen.
Selbst in Python hab ich nie gesunden Einstieg gefunden. Und dennoch klappt VHDL bei mir - viel mehr noch halte ich VHDL für sehr intuitiv.
So schwer ist es auch nicht, ein

for i in 0 to 7 loop
   ...
end loop;

zu interpretieren.
Ich denke, pauschal braucht man so eine Programmiersprache erstmal nicht verurteilen. Angucken lohnt sich allemal.

Ich bin mir nicht sicher, was du mit Struktur und Zustände meinst. Der Zustand einer Variable sollte natürlich immer definiert werden. Die Struktur in der FPGA-Programmierung besteht lediglich darin, zwischen Variablen und Signalen zu unterscheiden und die der Architektur (und damit global) oder einem Prozess (und damit lokal) zuzuordnen.

Ein 76€ Artix-7 klingt erstmal nicht nach der Welt. Teurer als ein Arduino-Board ist es allemal. Aber dafür kommt hier wieder der Thead-Ersteller ins Spiel, der angeregt hat, nicht über blinkende LEDs oder PWM-Ansteuerungen für Motoren nachzudenken, sondern um neuronale Netze. Und da behaupte ich mal, dass ein PIC18 oder ein Atmega328 hier schnell an Grenzen kommt, die ein FPGA so erstmal nicht besitzt. Inwiefern ein ARM oder RPi da nicht dennoch besser abschneiden kann, steht dabei natürlich noch in den Sternen.

Meine Grundbotschaft ist nur: nicht von 1000€ teuren Developer-Boards abschrecken lassen!

Grüß,
NRicola

[NRicola]

Hallo zusammen,

um vielleicht doch noch etwas auf die Sprünge zu helfen:
Ich denke, ein Blick in Google Scholar hilft schonmal ein gutes Stück:
https://scholar.google.de/scholar?hl...ork+fpga&btnG=

Vor allem kommt es aber darauf an, was das System lernen soll.
Hier zum Beispiel http://www.isfpga.org/fpga2016/index...Slides/1_2.pdf findet sich auf S. 10 eine gute Auswahl an Veröffentlichungen zu Neuronalen Netzen zur Bildverarbeitung. Das wird sich aber sicherlich von lernenden Systemen unterscheiden, die versuchen wollen, ein instabiles System zu stabilisieren.

Für mich klingt es sehr verlockend, jedem Neuron eine eigene Hardware-Region zuzuweisen und alle gleichzeitig arbeiten zu lassen.

Grüß,
NRicola

[Edit:] Das hier klingt doch ganz spannend: https://link.springer.com/book/10.1007%2F0-387-28487-7

[technick]

So einfach ist das nicht. Diese "Region" muss recht intelligent sein, um zu Lernen und sie muss mit Strageien versorgt werden. Das erfordert einen Informationsanschluss. Das ist z.B. das Problem, das mit GPUs zu machen. Die rechnen zwar schnell wie die Sau, man kriegt aber die Daten nicht schnell genug rein und raus.

Und eintrainieren muss auch jemand das System. Das ist dann das eigentliche Nadelöhr.