FPGA-Benutzung als Bastler sinnfrei?

Also im Retrocomputer Bereich gibt es z.B. massig Bastelprojekte. 
FPGASid als ein Beispiel unter vielen.

Ich hab bisher mit FPGAs auch nur im Praktikum im Studium gearbeitet und 
zuhause etwas damit rumgespielt. Ich kann dir ja aber mal erzählen, wozu 
ich jetzt ein FPGA in einem konkreten Projekt einsetze, allerdings auch 
ein wenig um des FPGAs willens, man könnte das Problem sicher auch 
anders lösen.
Ich habe in meinem vorherigem Projekt eine Regelung mit einem µC. Diese 
will ich jetzt recyclen. Dazu brauche ich u.A. eine Wurzel-Berechnung. 
Diese ist auf dem µC aufwändig und passt nicht mehr in das vorhandene 
Zeitfenster. Deshalb lagere ich diese und andere Berechnungen auf das 
FPGA aus.

FPGAs haben zwei typische Anwendungsgebiete:
a) viel Rechenleistung und viel I/O-Leistung
b) schnelles Pinwackeln

Gerade bei Bildverarbeitung kommt man schnell an die Grenzen der CPUs, 
aber Du hast recht, das ist den meisten Bastlern zu komplex.

Bleibt das Pinwackeln. Wenn Du zB 10 schnelle SPI-Schnittstellen 
brauchst, dann ist das für einen FPGA kein Problem, aber es gibt meines 
Wissens nach keinen µC, der sowas hat.

Bei einem aktuellen Bastelprojekt von mir kommt ein FPGA zum Einsatz um 
ein altes paralleles Interface zu emulieren und auf einen DDR RAM 
abzubilden. Die Taktrate ist zwar nur 2MHz aber man hat letztendlich 
nach dem Anlegen der Adresse ans parallele Interface nur 250ns Zeit die 
angefragten Daten zu liefern. Auf einem Mikrocontroller wird das doch 
etwas knapp.

Horst schrieb:
> Md M. schrieb:
>> Ich habe in meinem vorherigem Projekt eine Regelung mit einem µC. Diese
>> will ich jetzt recyclen. Dazu brauche ich u.A. eine Wurzel-Berechnung.
>> Diese ist auf dem µC aufwändig und passt nicht mehr in das vorhandene
>> Zeitfenster. Deshalb lagere ich diese und andere Berechnungen auf das
>
> https://en.wikipedia.org/wiki/Fast_inverse_square_root

Eine Wurzel Rechenoperation ist definitiv ein schlechter Grund, FPGAs zu 
nutzen. Jeder 2€ µC rechnet das mittlerweile in Hardware.

Timmy schrieb:
> Der Nachteil des erheblichen Stromverbrauchs spielt ja eine grosse
> Rolle
Wieso "erheblicher Stromverbrauch"? Worauf beruht diese Aussage?

> Was meint Ihr zum Thema?
Wenn du kein Problem hast, das ein FPGA zur Lösung benötigt, dann nimm 
einen µC. Das ist einfacher und billiger.

Wenn du aber die FPGA-Technik nicht beherrschst, dann wirst du eben 
zwangsweise versuchen, ein vermeintlich kompliziertes Problem mit einem 
µC zu lösen, das auf einem FPGA völlig simpel beherrschbar ist.

Ich würde ganz einfach sagen: lern FPGA-Technik, dann kannst du selber 
bestimmen, wann du was einsetzt und musst nicht krampfhaft Vor- und 
Nachteile der einen oder anderen Technik abwägen.

Md M. schrieb:
> u.A. eine Wurzel-Berechnung. Diese ist auf dem µC aufwändig und passt
> nicht mehr in das vorhandene Zeitfenster. Deshalb lagere ich diese und
> andere Berechnungen auf das FPGA aus.
Ich würde da einfach einen anderen, potenteren µC nehmen. Denn einen µC 
brauchst du ja trotzdem noch.

Horst schrieb:
> https://en.wikipedia.org/wiki/Fast_inverse_square_root

Interessant, werde ich mir durchlesen, danke.

Vincent H. schrieb:
> Eine Wurzel Rechenoperation ist definitiv ein schlechter Grund, FPGAs zu
> nutzen. Jeder 2€ µC rechnet das mittlerweile in Hardware.

Sind auch andere Sachen. Filter, die Regelung an sich (wird 
aufwendiger), etc. Es soll eben alles an Rechnerei ausgelagert werden 
bis auf Sachen wie z.B. Kommunikation mit einem PC.

Lothar M. schrieb:
> Ich würde da einfach einen anderen, potenteren µC nehmen. Denn einen µC
> brauchst du ja trotzdem noch.

Klar, wenn ich von Grund auf neu bauen würde schon. Wie gesagt, es gibt 
sicher andere Wege, das zu lösen. Mein Board ist aber schon fertig und 
der Flansch für das FPGA-Board schon vorhanden. Das ganze war von Anfang 
an als "Projekt in zwei Schritten" geplant.

Ich habe im Studium mit einer mitlerweile hoffnungslos veralteten 
Auflage von VHDL-Synthese (Reichardt, Schwarz) gelernt und fand das 
sehr gut. Ich persönlich wüsste aber im Moment nicht, ob ich mir 
überhaupt ein Buch kaufen würde. In der Tat gucke ich zur Zeit immer 
zuerst auf Lothars Seite vorbei. Ist quasi meine kleine VHDL-Bibel 
geworden. http://www.lothar-miller.de/s9y/

Nun, was bastelt man denn und warum?
Entweder man möchte etwas lernen, dann ist der Weg das Ziel.
Oder man möchte etwas lösen was es nicht fertig gibt/teuer ist/sonst 
nicht passt. Und dann kommt es ganz auf das Problem an was man 
verwendet.

Es gibt viele nette Bastelprojekte mit FPGAs die es so in kaufbar nur 
für etwas mehr Geld gibt. Z. B. einen Logikanalyzer/Oszi das die Samples 
in Echtzeit zum PC streamt. Mit USB2 bekommt man da >30MSamples/s bei 
8Bit hin, klar ist nicht viel, dafür hat man keine Totzeit. Und da gibt 
es eben echt viele nette Features die man in manchen Situationen gut 
brauchen kann, die fertige Geräte aber erst für viel Geld bieten.
Mir macht das jedenfalls irre viel Spaß.

Michel schrieb:
> Ich kenne kaum wirklichen Bedarf für FPGA-Knowhow, weil das Meiste so
> einfach ist, dass es jeder Student kann und die wenigen richtigen
> Anwendungen nur von einigen wenigen Experten beherrscht werden. Das
> FPGA-Thema ist hier dank Simulation, Matlab, SOPC und
> Programmierlibraries und Toolboxen sowieso untergeordnet. Es kommt auch
> die Beherrschung der Tools an und vor allem das Thema.

?? Ich hoffe doch schwer, dass das ironisch gemeint ist!
Klar sind FPGA "einfach" und von Studenten beherrschbar, wenn die 
Taktfrequenz <50MHz ist. Bei 200MHz und mehr wird es dann ohne konkretes 
Verständnis schon schwierig.
Ausserdem haben heutige Studenten oftmals keine Ahnung, was der 
Unterschied zwischen synchron und asynchron ist. Ergo haben sie KEIN 
Verständnis für FPGA-Technik.

Patrick B. schrieb:
> Ergo haben sie KEIN Verständnis für FPGA-Technik.

Bleibt die Frage: Brauchen sie es denn?

Als Hobby ist das cool, keine Frage.
Wirkliche Beherrschung davon ist extrem aufwändig, auch klar.
Und wenn in unserem Umfeld die Firmen reden, dann klingt das tatsächlich 
auch stark nach Matlab und Freunden (gilt im Übrigen auch für Teile der 
Softwareentwicklung, also der Algorithmen).

Andi schrieb:
> Ist es die Angst den Anschluss in Bastlerkreisen zu verlieren oder
> vielleicht nicht die neuste Technik zu besitzen?

Das eher nicht, die FPGAs gibt es ja schon eine Weile. So gefühlt 25 
Jahre, sage Ich mal.

> Wenn eines deiner Bastelprojekte ein FPGA erfordert wirst du es schon
> merken.
So ist es.

Hier wäre ein nettes Projekt für einen FPGA:
Beitrag "Re: Suche MOPPEL Projekt in Heft oder .PDF"


Schreiber schrieb:
> ...oder weil man irgendwie die eine Emailfunktion für Gefriertruhen-,
> Heizungs- und Drainagepumpenstörungen nachrüsten will
> ...oder weil die Oma leider schon leicht dement und gebrechlich wird und
> man den Herd nachrüsten will. Jetzt muss man beim Kochen alle 10 Minuten
> auf einen Taster drücken.
> ...und Nachbars Fuchs- und Waschbärfallen melden sich per SMS, wenn sie
> gefunden wurden. Die meisten Finder dürfen dann zum Kürschner...

> Häufig bastelt man auch, weil man für irgendein Problem eine Lösung
> benötigt und das was verfügbar ist nicht den Anforderungen entspricht.
Da stimme Ich zu, wobei Ich etwas unsicher bin, ob ausgerechnet diese 3 
Beispiele ideale Ziele fürs FPGA-Basteln sind.

Patrick B. schrieb:
> Klar sind FPGA "einfach" und von Studenten beherrschbar, wenn die
> Taktfrequenz <50MHz ist. Bei 200MHz und mehr wird es dann ohne konkretes
> Verständnis schon schwierig.

Nun, an der Frequenz direkt kann man es nicht so festmachen, denke Ich, 
die ist beim FPGA nur interessant, wenn es an die Grenzen desselben geht 
und man tricksen muss. Steigende Frequenzen sind eher ein Peripherie- 
und ein IO-Thema, das natürlich dazu gehört.

> Ausserdem haben heutige Studenten oftmals keine Ahnung, was der
> Unterschied zwischen synchron und asynchron ist.
Was verwunderlich ist, weil das eigentlich in jeder 
Digitaltechnikvorlesung erklärt wird und mit FPGAs direkt nicht viel zu 
tun hat, sondern immer schon ein Thema war, wenn man mit Logikgattern 
mit irgendwelchen Chips verknüpft hat.

Timmy schrieb:
> Nur leider fällt mir absolut kein Bastelprojekt ein, wozu ein
> FPGA wirklich sinnvoll ist.

Wem gar nichts einfällt, einfach mal das aktuelle Angebot an PMods 
anschauen (z.B. http://store.digilentinc.com/pmod-modules/), da kommt 
man schon auf Ideen.

Ob Projekte wie eine LED-Strip Frequenzanzeige 
(http://www.instructables.com/id/Nexys-4-DDR-LED-strip-Audio-Spectrum/) 
oder eine FPGA basierte Orgelsemulation (https://github.com/heise/HOAX) 
als "sinnvoll" durchgehen, muss jeder Bastler für sich selbst 
entscheiden.
Meine erste Fingerübung war ein DCF77-Decoder - schreit nicht wirklich 
nach nem FPGA - hat aber Spaß gemacht und ich habe mir wichtige Konzepte 
dabei erarbeitet.

Und nicht zuletzt - manche Dinge sind auf dem FPGA plötzlich einfach, 
z.B. "krumme" Taktraten für Peripheriegeräte (immer gerne: Audio Codecs, 
z.B. CS4344), ein 24bit NCO von 1 bis 50 MHz oder die Ansteuerung von 
Geräten mit nicht-standardkonformen Protokollen.

Burkhard K. schrieb:

> oder eine FPGA basierte Orgelsemulation (https://github.com/heise/HOAX)
Oha, ausgerechnet den HOAX zu linken, ist schon etwas gewagt. Der hat 
den Status des "Bastelns" signifikant hinter sich gelassen. Laut 
Entwickler sind es zwar in erster Linie "schmutzige DDSen, die da 
laufen" (Originalzitat), aber die klangliche Nachbildung einer Hammond 
setzt sehr viel funktionelles Knowhow über das System voraus, das nicht 
einmal Ich habe. Wenn man sich in Musikerkreisen so umhört, hat er es 
wohl am Besten hinbekommen, was die Authentizität des Klangs anbelangt.

Etwas einfacher und immer noch nach Orgel klingend, wäre dies hier:
http://www.96khz.org/htm/virtualpldorgan07spartan3e.htm

Was es noch braucht (und was noch keiner so richtig hinbekommen hat) ist 
eine Verbrennungsmotorsimulation, um z.B. einen Ferrari oder einen 
Bugatti nachzubilden, wenn er Gas gibt. Vielleicht wäre das was ...

Wer mag:

Die einzelnen Elemente, aus denen sich so ein Motor zusammensetzt, 
müssen bezüglich Torsionen, Schwingungen und generellen mechanischen 
Spannungen, so exakt modelliert werden, dass sie in einer Rechenpipeline 
parallel arbeiten und wenigstens alle 2-5us ein stabiles, lokal 
eingeschwungenes Ergebnis liefern, damit man eine entsprechende 
Audio-Abtastrate hinbekommen kann. Es muss dabei - anders, als Viele 
wahrscheinlich erwarten, bis weit
 in den Ultraschallbereich simuliert werden und Schallausbreitung in 
Metallen, in komprimierten und unkomprimierten, trockenen und feuchten 
Gasen berücksichtigt werden.

Ach ja: Mit MATLAB geht da nix. Gleich zwei mir bekannte angehende 
Wissenschaftler sind mit der Umsetzung von akustischer Modellierung in 
ähnlichen Projekten mittels Modellierung und Erzeugung des Codes über 
den C- oder HDL-Coder schwer gescheitert. Da ist 4D-Denken (Raum+Zeit) 
und die Umsetzung in entsprechende partiell iterative Rechenpipelines 
gefordert.

Lothar schrieb:
> Md M. schrieb:
>> Ich habe in meinem vorherigem Projekt eine Regelung mit einem µC. Diese
>> will ich jetzt recyclen. Dazu brauche ich u.A. eine Wurzel-Berechnung.
>> Diese ist auf dem µC aufwändig und passt nicht mehr in das vorhandene
>> Zeitfenster. Deshalb lagere ich diese und andere Berechnungen auf das
>> FPGA aus
>
> Genau sowas meine ich :-)

Md M. schrieb:
> allerdings auch
> ein wenig um des FPGAs willens, man könnte das Problem sicher auch
> anders lösen.

Jo. Ich wollte halt ein FPGA einsetzen. Erstens, weil ich es halt als 
Fingerübung wollte und zweitens fand ich es auch sinnvoll, weil ich im 
ersten Teil des Projekts noch nicht genau wusste, was ich im zweiten 
Teil genau machen werde, in welche Richtung es geht und wie 
rechenintensiv das wird. Es sid Projekte fürs Studium, wobei das zweite 
möglichst auf dem ersten aufbauen soll.

Kurze Ergänzungsfrage: gibt es für Bastler günstige PIC(e) FPGA Karten? 
Idealerweise mit Netzwerkbuchse? Damit man die Daten schnell ins FPGA 
bekommen könnte?

Vielen Dank im Voraus,
Andreas

Andreas R. schrieb:
> Kurze Ergänzungsfrage: gibt es für Bastler günstige PIC(e) FPGA Karten?
> Idealerweise mit Netzwerkbuchse? Damit man die Daten schnell ins FPGA
> bekommen könnte?
>

Für die Versa ECP5-Dinger von Lattice gabs vor ner Weile die hier schon 
öfters genannte 99$ Promo-Aktion, frag mal deinen Lieblingsdisti.
Den PCIe habe ich aber noch nicht genutzt, dafür hat das Ding zwei 
1G-Ethernetbuchsen.
Und wo ich, wenn ich mich recht entsinne, über die Tools gemotzt habe: 
Mit Diamond v3.9 wurde offenbar das lästige Pfadnamenproblem behoben.
Thumbs up, Lattice Semi!

Vielen Dank für den freundlichen Tip! Meinte natürlich ne PCIe Karte...

Das Ding sieht auf den ersten Blick irgendwie ziemlich anders aus als 
der Altera oder Xilinx Kram, den ich bis jetzt gesehen hab. Muss ich 
mich erst noch bischen einlesen...

Danke nochmal!

Andreas R. schrieb:
> Also im Retrocomputer Bereich gibt es z.B. massig Bastelprojekte.
> FPGASid als ein Beispiel unter vielen.

Wobei Ich noch keinen virtuellen SID gefunden habe, der wirklich klingt, 
wie ein echter SID. Das liegt an den analogen Komponenten im Chip und 
bei der Klangausgabe.

Weiss nicht...ich such ne ausbaubare CPU.

Also wo man ne Reihe eigener Befehle einbauen kann für so paar 
Spezialprobleme.

Ich hab die Sache ja auf so nem Intel und AMD Kram laufen. Aber nun soll 
es schnell werden.

Ha, spannendes Thema..


C. A. Rotwang schrieb:
> Andreas R. schrieb:
>> Weiss nicht...ich such ne ausbaubare CPU.
>>
>> Also wo man ne Reihe eigener Befehle einbauen kann für so paar
>> Spezialprobleme.
>

An sowas experimentiere ich schon länger rum, und hätte da inzwischen ne 
Lösung, aber leider nich OpenSource.

> Spezialbefehle bremsen aber die 08-15 Befehle aus. Da kommst mit (FPGA-)
> Co-Prozessor besser. Ausnahme vielleicht Bitoperationen, aber das ist
> wieder die Stärke von Signalprozessoren, die es auch in Taktfrequenzen
> jenseits des FPGA-möglichen gibt:
> http://www.eetimes.com/document.asp?doc_id=1195819
>

Wenn es nur ein "Beschleuniger" sein muss, der inline (wie ein 
Funktionsaufruf) laufen soll, geht das ganz gut. Wenn es volle Pulle 
laufen muss und wild Memories indizieren muss, dann hat man halt mit dem 
DSP mehr Spass.

> Und wenn man doch der FPGA den DSP aussticht, dann ist die
> Entwicklungszeit deutliche höher als bei einem DSP.
>

Nicht mehr zwingend, würde ich sagen - wenn die Toolchain mal steht. Die 
meisten DSP-Ops kannst du in Python hinschreiben, und im Gegensatz zum 
DSP ist alles funktional verifizierbar und auf HDL-Level beweisbar.
Aber sobald es aus klassischen Problemen rausrennt, bist du wieder da, 
wo du mit HLS halt eben schnell mal auch bist.

>>Ich hab die Sache ja auf so nem Intel und AMD Kram laufen. Aber nun soll
>>es schnell werden.
>
> FPGA-CPU-Cores sind aber so faktor 10 langsamer als die Top-runner von
> intel & Co. Aber dafür deutlicher teurer.
>
> Um welche Sache geht es denn?

Oder so: Kann man die Sache auf einer GPU/VPU laufen lassen?

Hab mal eben noch den alten Thread zu dem Thema ausgegraben, passt 
eigentlich nicht so ganz in die "Bastelecke"..

Beitrag ""Neue" CPU-Architektur-Aspekte (FPGA softcores)"

Also mein Problem ist hauptsächlich Text parsen und zusammensetzen. 
Singlethread, also OpenCL nützt gerade wenig .

MagIO schrieb:
> Was PCI betrifft:
> Wenn ich das richtig verstehe kommen zu dem Lattice Sonderangebot zu ca.
> 250€ noch die Kosten für die Entwicklungsumgebung und für die benötigten
> IP, damit man PCI überhaupt nutzen kann, richtig?

Mit der Probierlizenz kannst du immerhin ein Jahr lang spielen und den 
Core im Demo-Modus ausprobieren. Aber ok, es gibt Kunden, die sowas 
unsäglich nervt und dann lieber mehr für ein Spartan6-Board mit 
'fertigem' PCIe ausgeben.

Andreas R. schrieb:
> Also mein Problem ist hauptsächlich Text parsen und zusammensetzen.
> Singlethread, also OpenCL nützt gerade wenig .

Dann nützt dir ein FPGA aber auch wenig. Es scheint grade ein 
oszillierender Hype zu sein, mit FPGAs Genom-Analyse zu machen, aber das 
ist im Vergleich zu einer 0815 i86-Cruncherfarm eher sinnlos.

Wieso nützt mir FPGA da wenig? Wenn ich z.B. als ersten Schritt mal 
einen Befehl implementiere, der alle Delimiter in einem String findet 
und in eine Tabelle einträgt, dann hätte ich mir schonmal eine Schleife 
gespart.

Text kommt übers Netz. Sind max. paar hundert Byte. Meine Idee war die 
Zeichenvergleiche alle parallel laufen zu lassen und dann ein Bitfeld 
entsprechend zu setzen.

Andreas R. schrieb:
> Wenn ich z.B. als ersten Schritt mal einen Befehl implementiere,
> der alle Delimiter in einem String findet und in eine Tabelle einträgt,
> dann hätte ich mir schonmal eine Schleife gespart.
Du denkst viiiieeeeel zu abstrakt für ein FPGA.
Dort musst du denken: was ist ein String? Was ist ein Tabelle? Was 
bedeutet "finden"?

> Text kommt übers Netz.
Also tendenziell schnarchlangsam.

> Meine Idee war die Zeichenvergleiche alle parallel laufen zu lassen und
> dann ein Bitfeld entsprechend zu setzen.
Einarmiger Handstand mit Händeklatschen? Wie schnell brauchst du die 
Lösung? Wenn du jetzt sagst "100ns", dann mach das parallel mit einem 
Monstermultiplexer in einem FPGA. Wenn aber die Zeichenkette schon nur 
mit 100MBit/s reinkommt, dann löse das Problem mit einem Prozessor.

Du kannst übrigens einen Parser auch als FSM auf einen seriellen 
Datenstrom Zeichen für Zeichen laufen lassen. Also nicht erst alles 
empfangen und dann parsen, sonder schon während des Empfangs den Parser 
mitlaufen lassen...

MagIO schrieb:
> Und so massiv parallel, dass man 1MB an Text auf einen Schlag
> durchsuchen könnte, ist ein FPGA auch nicht, würde ich sagen.
Schon bei den angesprochenen "paar hundert Byte" wird der Vergleicher 
und der Multiplexer so groß, dass diese Logik, wenn sie stupide nach dem 
"komplett empfangen, dann verarbeiten" Motto aufgebaut ist, sicher 
Laufzeiten im µs Bereich ergibt (wenn die Tools das Ding so massiv 
parallel überhaupt noch reinkriegen).
Und im FPGA kann man sich die überschlägige "paar hundert Byte" 
Denkweise gleich mal abschminken. Dort sollte man schon zu Beginn genau 
wissen, ob es 100 oder 500 Byte sind. Denn dazwischen liegen Welten...

Lothar M. schrieb:
>> Meine Idee war die Zeichenvergleiche alle parallel laufen zu lassen und
>> dann ein Bitfeld entsprechend zu setzen.
> Einarmiger Handstand mit Händeklatschen? Wie schnell brauchst du die
> Lösung? Wenn du jetzt sagst "100ns", dann mach das parallel mit einem
> Monstermultiplexer in einem FPGA. Wenn aber die Zeichenkette schon nur
> mit 100MBit/s reinkommt, dann löse das Problem mit einem Prozessor.
>
> Du kannst übrigens einen Parser auch als FSM auf einen seriellen
> Datenstrom Zeichen für Zeichen laufen lassen. Also nicht erst alles
> empfangen und dann parsen, sonder schon während des Empfangs den Parser
> mitlaufen lassen...

So ähnlich mach ich das gerade mit einer CPU. Braucht da aber über 
300ns. Jetzt möchte ich die Sache halt weiterentwickeln.