Forum: FPGA, VHDL & Co. Vom Softwareentwickler zum FPGA-Entwickler - Einstiegshilfe gesucht


von Alex H. (isenhard)


Lesenswert?

Moin moin!
Ich habe "Angewandte Informatik" (Bachelor) studiert, war dann 3 Jahre 
als IT-Berater/Softwareentwickler berufstätig und habe mich dann 
entschieden doch noch einmal den Master in Informatik nachzuholen. Nun 
bin ich so weit, dass ich nur noch 2 Projekte vor mir habe und dann mit 
der Masterarbeit beginnen kann.

Mit meinem Prof. haben wir uns darauf geeinigt einmal einen FPGA zur 
Signalverarbeitung auszuprobieren. Konkret geht es dabei um das Falten 
von Raumimpulsantworten mit einem Audiosignal, um hinterher eine 
Mehrkanal-Aufnahme zu erhalten. Das alles möglichst in Echtzeit und 
genau das wollen wir herausfinden, wie gut es eben funktioniert.

Zu meinem Problem: Ich war bisher immer nur Softwareseitig unterwegs und 
habe leider nie im Leben von Anfang an einen Mikrocontroller oder FPGA 
programmiert. Mir fehlt sowohl das technische Verständnis als auch die 
Idee das hinterher umzusetzen. Wie und wo fange ich am besten an? Ich 
bräuchte vielleicht einfach nur ein paar Stichworte mit denen ich mich 
beschäftigen soll. Ob das jetzt am Ende in VHDL, Verilog oder 
Matlab/Simulink realisiert wird, soll erst einmal weniger die Rolle 
spielen.
Mir geht es eher um solche Fragen wie: Wie ist so ein Entwickler-Board 
aufgebaut? Wie ist es dort mit einer ARM-CPU verbunden und wie steuern 
sich diese gegenseitig an? Wenn ich mit dem Programmer mein Programm auf 
den FPGA lade, wo ist es gespeichert und in welcher Form? Wenn ein 
Projekt auf dem Board fertig ist und es z.B. in der Industrie eingesetzt 
werden soll: Wie geht es da weiter? Es werden vermutlich keine 
Entwicklerboards mehr eingesetzt sondern nur noch der FPGA und...? Kann 
man einen FPGA mit einer CPU überhaupt vergleichen? etc. etc. etc.

Wie Ihr seht, bin ich vielleicht kein einfacher Fall, ich möchte das 
aber auf jeden Fall durchziehen, es lernen und auch verstehen, wenn auch 
erst einmal nur Grundlegend und für das Projekt ausreichend. Gibt es 
gute Literatur hierfür?
Dann brauche ich natürlich noch ein Entwickler-Board, am besten mit dem 
ganzen Zubehör, welches benötigt wird, also Stromversorgung, 
Programmierer etc.. Vielleicht eins, zu dem es auch viele Tutorials und 
Beispiele gibt. Bevorzugt wird hier von der Uni Xilinx, das ganze sollte 
die 1000€ Marke nicht überschreiten. Könnt Ihr mir da vielleicht etwas 
empfehlen? Ich brauche einen analogen Signaleingang, einen ADC und 
entweder acht DACs und analoge Signalausgänge oder eine Möglichkeit die 
acht Signale möglichst einfach und erweiterbar per Ethernet 
weiterzuleiten.

Für etwas Einstiegshilfe und einen guten Rat bin ich immer sehr dankbar!
Alex

: Bearbeitet durch User
von Bürovorsteher (Gast)


Lesenswert?

Gegenfrage: wieviel Zeit hast du dafür?

von Christoph Z. (christophz)


Lesenswert?

Alex H. schrieb:
> Konkret geht es dabei um das Falten
> von Raumimpulsantworten mit einem Audiosignal, um hinterher eine
> Mehrkanal-Aufnahme zu erhalten.

Deine Frage bezieht sich zwar auf alles was FPGAs zu tun hat, aber damit 
du überhaupt eine Chance hast, da irgendwo hin zu kommen, muss ich dich 
fragen, ob du die Aufgabe "falten von Raumimpulsantworten mit einem 
Audiosignal" schon gelöst hast. Also läuft dazu ein Prototyp, sind die 
Algorithmen bekannt, ist bekannt wie viel Speicher diese 
Raumimpulsantwort belegt etc.

Gibt es schon eine Implementierung mit Integers oder ist das noch alles 
Float?

Das Entwicklerboard brauchst du noch gaaanz lange nicht. Simulator 
genügt für dein Projekt für eine längere Zeit bzw. hat mehr Aussicht auf 
Erfolg.

> Das alles möglichst in Echtzeit und
> genau das wollen wir herausfinden, wie gut es eben funktioniert.

Definiere "gut" :-)

Performance/Watt
Performance/Geld
Entwicklungszeit
Anzahl zusätzliche graue Haare des Entwicklers
...

Alex H. schrieb:
> Kann man einen FPGA mit einer CPU überhaupt vergleichen?

Nein. Das wäre wie wenn man LEGO und Playmobil vergleicht.

Zum Einstieg:
https://www.mikrocontroller.net/articles/FPGA

http://www.lothar-miller.de/s9y/categories/1-VHDL

von Alex H. (isenhard)


Lesenswert?

Geplant war es bis Ende des Jahres zu schaffen. 2-3 Tage die Woche hätte 
ich Zeit dafür.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Alex H. schrieb:
> Vielleicht eins, zu dem es auch viele Tutorials und Beispiele gibt.

Da ich auch gerade (endlich mal) damit angefangen habe, mich mit dieser 
Technik zu beschäftigen: ein Tutorial oder Beispiel als allererster 
Einstieg ist gut. Aber danach beherzige Lothars Rat (den er mir in einer 
privaten Mail gab): das erste Projekt ist eine blinkende LED. Zieh das 
von vorn bis hinten durch, bis du jede Zeile darin verstanden hast.

Als die LED blinkte, habe ich mich dann an ein analoges Fernsehsignal 
getraut, weil es einfach interessant klang, und habe die 
Bildschirmsteuerung meines vor 35 Jahren gebauten Z80-Computers 
nachimplementiert. Die zeigt nun zumindest ein "Hello world!" :-). Aber 
es war schon mal ein gutes Stück auf dem Pfad der Erkenntnis bis 
hierhin, und von DSP-Algorithmen bin ich damit immer noch ein ganzes 
Stück entfernt (wenngleich es sicher nicht der Anspruch ist, dort auch 
alles bis zur letzten Zeile zu verstehen).

ps: Interessant, mit was für einer matschigen Bildschirmdarstellung man 
dazumals schon glücklich war. ;-) Das hier ist zwar nicht der originale 
Fernseher, den ich damals benutzt habe, aber wirklich besser war der 
wohl auch nicht.

: Bearbeitet durch Moderator
von Alex (Gast)


Lesenswert?

Alex H. schrieb:
> Geplant war es bis Ende des Jahres zu schaffen. 2-3 Tage die Woche hätte
> ich Zeit dafür.

Würdest du dich als mathematisch begabt bezeichnen? Digitale 
Signalbehandlung (Abtasten, FFT, FIR, IIR, Windowing, etc.) ist recht 
mathelastig und man sollte mathematisch schon recht fit sein, um die 
Ergebnisse interpretieren und die Algorithmen entsprechend anpassen zu 
können.

Der FPGA ist dann die zweite Hürde, die es zu meistern gilt.

Gruß,

von Inspizierender Instruktor (Gast)


Lesenswert?

Alex H. schrieb:
> Gibt es
> gute Literatur hierfür?

Ja! Auch wenn es sich auf einen bestimmten Typ von FPGA und zumal einen 
SoC einschiesst, finde ich das Zynq-book gerade für Anfänger geeignet.

https://all-med.net/pdf/the-zynq-book/

Vor den ganzen SoC-Theater war dies IMHO das beste Buch:
https://www.pearson.com/us/higher-education/product/Wakerly-Digital-Design-Principles-and-Practices-and-Xilinx-4-2-i-Student-Package-3rd-Edition/9780131760592.html?tab=Features

weil es eben Digitaltechnik und nicht allein FPGA-Gehampel lehrt.

>Gegenfrage: wieviel Zeit hast du dafür?
Ich würde diese wichtige Frage anders formulieren - Wieviel Zeit musst 
du unbedingt einplanen!? Es nützt nichts, sich für ein komplexes Thema, 
sagen wir mal 8 Wochen für alles, inklusive Einarbeitung, Schaffung 
Arbeitsumgebung einzuplanen aber dann wichtige Lernschritte (bspw. 
Simulationstaktiken, passendes IO-Constraining, Timing Closure 
techniques) auszulassen, weil sonst die Zeit nicht reicht.
Ebenso ist es wenig zielführend sich gleich alles aufzubürden, bei dir 
klingt es stark danach, das ihr auch ein FPGA-Board selbst designen 
wollt - lasst das bloss bleiben wenn ihr in einem halben Jahr was 
brauchbares haben wollt.

Ich würde als Minimum für einen Quereinsteiger aus der 
SW-Programmierecke als Minimum 3 Monate einplanen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

BAlex H. schrieb:
> Ob das jetzt am Ende in VHDL, Verilog oder Matlab/Simulink realisiert
> wird, soll erst einmal weniger die Rolle spielen.
Genau das ist aber der Knackpunkt, an dem sich das Gelenk biegt. Denn 
wenn du mit Matlab möglichst abstrakte Modelle aufstellst und dann auf 
einem fertigen FPGA-Board am besten zusammen mit einem ARM darauf zum 
Laufen bekommen willst, dann bist du von der eigentlichen Hardware so 
weit weg wie die Sonne vom Mond, die zwar jeweils am Himmel leuchten, 
aber nie so wirklich zusammen.

> Wenn ein Projekt auf dem Board fertig ist und es z.B. in der Industrie
> eingesetzt werden soll: Wie geht es da weiter?
Das kommt darauf an, wie sowas entwickelt wurde. Mit einem Eval-Board 
wird bestenfalls ein rudimentäres Funktionsmodell aufgebaut. Daran wird 
untersucht, welche Ressourcen benötigt werden, und darauf basierend wird 
ein möglichst punktgenaues, den Anforderungen genügendes Board 
entworfen, hergestellt und in Betrieb genommen. Und auf diesem Board 
wird das Projekt dann erst richtig fertig entwickelt.

> Kann man einen FPGA mit einer CPU überhaupt vergleichen?
Nein.
Schon die Denkweise einer strukturellen, paralellen 
HardwareBESCHREIBUNGSsprache ist eine völlig andere als wenn ich eine 
prozedurale sequentielle PROGRAMMIERsprache anwende. Man sollte sich da 
nicht zu viel vom Traumsand in die Augen streuen lassen.

> Kann man einen FPGA mit einer CPU überhaupt vergleichen?
Das sind 2 völlig unterschiedliche Dinge.
Man könnte zwar einen CPU-Kern in ein FPGA packen, der wäre aber einem 
dedizierten und optimierten CPU-Kern in sämtlichen Belangen 
(Strombedarf, Flächenbedarf, max. Takt,...) signifikant unterlegen.
Nicht umsonst bauen FPGA-Hersteller einfach in die Ecken ihres Siliziums 
fertige CPU Blöcke. Denn diese CPU können nicht das, was das 
danebenliegende FPGA kann und auch nicht umgekehrt.

Bürovorsteher schrieb:
> Gegenfrage: wieviel Zeit hast du dafür?
Das ist mir auch zu allererst in den Sinn gekommen.

Jörg W. schrieb:
> Aber danach beherzige Lothars Rat (den er mir in einer privaten Mail
> gab): das erste Projekt ist eine blinkende LED. Zieh das von vorn bis
> hinten durch, bis du jede Zeile darin verstanden hast.
Samt Simulation...  ;-)
Hört sich zwar blöd an, eine blinkende LED zu simulieren, man lernt 
dabei aber fürs Leben. Aber dieser Weg ist ja der "HDL"-Weg, nicht der 
"Nimm-Matlab-und-per-Knopfdruck-wird-eine-VHDL-Beschreibung-draus"-Weg 
(eng verwandt mit dem bekannten chinesischen "Auspack-und-freu"-Weg... 
;-)

: Bearbeitet durch Moderator
von Kest (Gast)


Lesenswert?

Wenn ich soetwas machen müsste:

Das Thema FPGA ist ganz schön umfangreich, bis Ende des Jahres ist es 
nur zu schaffen, wenn Du auf vieles "verzichtest".

Als erstes würde ich in C/C++ die Algorithmen durchspielen: eine 
.wave-Datei einlesen, prozessieren, eine .wave-Datei schreiben. Das 
kannst Du jetzt schon anfangen.
Als nächstes würde ich XILINX Vitis Software herunterladen und das Ganze 
in C/HLS/OpenCL nachimplementieren. Dann siehst Du auch, wo die 
Stolpersteine sind, wie die interne Struktur (MACs, Speicheranbinmung 
und so weiter) aufgebaut werden soll. Dazu musst Du keine einzige Zeile 
VHDL/Verilog schreiben. In der Zeit verstehst Du auch dann hoffentlich, 
worin der Unterscheid zw. dem FPGA und einer CPU besteht.

Dann kompillierst Du Deinen Projekt als HW-Emulation. Du siehst die 
Simulation, kannst noch mehr erkennen, lernst auch dabei viel. Und wenn 
Du damit fertig bist (Ende des Jahres), kaufst Du Dir ein XILINX Board, 
z.B.:
AVNET ULTRA96:
https://de.farnell.com/avnet/aes-ultra96-v2-g/sbc-64-bit-arm-cortex-a53-r5/dp/3050481?st=Ultra96

oder ZCU104
https://www.xilinx.com/products/boards-and-kits/zcu104.html

Du kannst dann immer noch .wav-Dateien von der SD Karte laden und 
processieren oder schließt eine USB-Soundkarte an (ist ja Linuxbasiert, 
also kein Problem)...

Ist aber ein langer und beschwerlicher Weg. Du sollst Dir klar machen, 
was Du erreichen möchstest: Algorithmen verifizieren, 
Hardware-Implementierung, Echtzeit-Implementierung oder sonstiges. Alles 
zusammen wird kaum machbar

Grüße
Kest

von Martin S. (strubi)


Lesenswert?

Den Thread hier schon gesehen?

Beitrag "Welches Zynq-Board für Mess-Applikationen ?"

Das Thema ist ein Dauerbrenner.
Das Zauberwort heisst: Fokussiere, Simuliere. Und du brauchst dafuer 
keine HW.

Alex H. schrieb:
> Ob das jetzt am Ende in VHDL, Verilog oder
> Matlab/Simulink realisiert wird, soll erst einmal weniger die Rolle
> spielen.

Python/MyHDL schon in Betracht gezogen? Da findet man schnell einen 
Einstieg. Gibt es einige Tutorials (inkl. Synthese-Ausgabe im Browser).

Alex H. schrieb:
> Kann
> man einen FPGA mit einer CPU überhaupt vergleichen?

Der hier sorgt auch immer wieder fuer dieselben ausufernden 
Diskussionen.
Klar kann man sie vergleichen, sollte man auch tun. Guck dir einfach mal 
an, was an harter Logik (Silicon) drinsteckt.

Im Sinne von: "Fokussiere" wuerde ich mich halt eher mal fuer eins der 
beiden Themen, also entweder FPGA-Synthese oder Signalverarbeitung, dann 
aber auf DSPs, entscheiden.
Du kannst natuerlich, wenn du von der Software her kommst, selber eine 
programmierbare DSP-Pipeline entwickeln, viel Schreibarbeit sparen und 
damit von beiden Tellerchen essen. Ist aber anspruchsvoller..

von PittyJ (Gast)


Lesenswert?

Bei mir ist das jetzt 10 Jahre her. Ich hatte mir ein Eval-Board 
(Xlilinx) besorgt, dazu Bücher zu VHDL, und was man alles so hier 
findet.

Und dann bin ich die Beispiele in den Buch durch und habe die 
nachgebaut. Versucht etwas zu verändern und das Konzept zu verstehen.

Das Konzept unterscheidet sich doch sehr zu einer Programmiersprache. 
Und es muss erst einmal Klick machen, das man Signale und Variablen 
unterscheidet und was alles bedeutet. Es gibt nichts, was mit einem 
sequentiellen Programm vergleichbar ist.

Auch, dass man nicht losprogrammiert, sondern für alles erst einmal 
Testbenches schreibt, weil man nicht debuggen kann, Braucht eine gewisse 
Zeit.

Bis es Klick macht, würde ich mal 3 Monate ansetzen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Alex H. schrieb:
> Geplant war es bis Ende des Jahres zu schaffen. 2-3 Tage die Woche hätte
> ich Zeit dafür.
Mal ganz ohne Witz: wie sieht es mit den Nächten aus?
So manche Nuss habe ich erst nachts um 3 geknackt...  ;-)

Alex H. schrieb:
> Konkret geht es dabei um das Falten von Raumimpulsantworten mit einem
> Audiosignal, um hinterher eine Mehrkanal-Aufnahme zu erhalten. Das alles
> möglichst in Echtzeit und genau das wollen wir herausfinden, wie gut es
> eben funktioniert.
Es ist also bereits mit "Offline-Berechnungen" z.B. anhand von 
Audiodateien nachgewiesen, dass das Verfahren prinzipiell 
funktioniert? Und es muss jetzt nur noch nachgewiesen werden, dass man 
das auch in Echtzeit kann und welcher Aufwand dafür nötig ist?

: Bearbeitet durch Moderator
von Alex H. (isenhard)


Lesenswert?

Vielen Dank für die zahlreichen Antworten! Ich hätte nicht gedacht, dass 
sich innerhalb so kurzer Zeit doch so viele - vor allem verschiedene - 
Antworten finden.
Ich bin aktuell zeitlich (durch die bevorstehende Hochzeit meiner 
Schwägerin) sehr eingespannt und wollte nur Bescheid geben, dass ich 
erst kommende Woche dazu komme auf die ganzen Fragen zu antworten bzw. 
weitere Fragen zu stellen. Also bitte nicht böse sein oder denken ich 
antworte nicht mehr :).

Also noch einmal vielen Dank bis hierher und allen ein schönes, langes 
Wochenende!
Alex

von Inspizierender Instruktor (Gast)


Lesenswert?

Lothar M. schrieb:

> Mal ganz ohne Witz: wie sieht es mit den Nächten aus?
> So manche Nuss habe ich erst nachts um 3 geknackt...  ;-)

ja so manches Problem auf dem Bildschirm knackt man, sobald man nicht 
mehr auf dem Bildschirm starrt …

Dieses Problemlösungsverfahren (Kontextwechsel) kann man beim FPGA easy 
anwenden, bspw indem man statt im VHDL-Code zu wühlen sich die reale 
Logic im Chiplevelviewer reinzieht. Oder mal einen (virtuellen oder 
realen) Logicanalyzer dranhängt. Oder als Einschlafhilfe ein paar 
Dutzend Seiten von den mehreren tausend Blättern Datasheets und Appnotes 
des FPGA-Herstellers liest. Oder,...

von Larry (Gast)


Lesenswert?

> Bis es Klick macht, würde ich mal 3 Monate ansetzen.

Wer schon viel Hardwareentwicklung mit klassischer Technik
gemacht hat, hat den Vorteil das es intuitiv Klick macht.

3 Monate brauchen eher die, die Probleme bislang in
Software auf "normalen" Architekturen geloest haben.

Das ganze mag mit einer HLS wohl einfacher implementierbar sein,
aber ein FPGA-Entwickler ist man danach erst recht nicht.

Spaetestens wenn man in der Industrie Projekte umsetzen will,
muss die Implementierung nebenbei die noetige Effizienz,
d.h. den angemessenen Umgang mit Ressourcen aufweisen.
Da sieht es bei HLS doch immer noch ziemlich duester aus.
Aber bei einem Forschungsprojekt mag das tragbar sein.

von Udo K. (Gast)


Lesenswert?

Lass die Finger davon, weil:

- kaum jemand im Audio Bereich sowas in der Industrie auf einem FPGA 
macht
     => kein Job nacher
- sehr spezialisiert
     => VHDL Stellen gibts nur in wenigen Ballungszentren
- sehr aufwändige Einarbeitung
     => wird nicht fertig
- kein Neuland
     => keine Anerkennung im akademischen Bereich

von Gustl B. (-gb-)


Lesenswert?

Alex H. schrieb:
> Geplant war es bis Ende des Jahres zu schaffen. 2-3 Tage die Woche hätte
> ich Zeit dafür.

Das ist tatsächlich gar nicht so wenig Zeit. Wenn Ende des Jahres auch 
bei dir wirklich im Dezember liegt, dann ist das schon machbar wenn du 
schon weißt, was du machen willst. Also wenn du das eigentliche Problem 
der Signalverarbeitung schon z. B. in Matlab gelöst hast.

Auch wichtig wäre das abzugrenzen was du alles nicht machen willst in 
der Zeit. Du willst in der Zeit kein FPGA Board selber designen. Du 
willst dich eigentlich gar nicht um die Hardware kümmern, sondern das in 
HDL schreiben, simulieren, gucken in welches FPGA das reinpasst und dann 
die passende Hardware kaufen.

Und das kannst du alles schön kleinschrittig machen.
Zuerst würde ich einige Zeit komplett Projektunabhängig VHDL lernen. 
Also Standardanfängeraufgaben lösen. Vielleicht sogar mit einem billigen 
FPGA Board weil das eben motivierend ist, wenn man da auch ein Ergebnis 
sehen kann. Aber trotz Hardware die Simulation nicht vernachlässigen.
Wenn du dann etwas sicherer in der Hardwarebeschreibung und Simulation 
bist, also schon etwas Hardware denken kannst, dann kannst du anfangen 
die ersten kleineren Teile deiner Softwarelösung in VHDL zu beschreiben. 
Alles aussen herum, also die AD und DA Wandler und so, das beachtest du 
erstmal nicht. Da kommen die Daten aus einer Datei und werden wieder in 
eine Datei geschrieben in der Simulation. Das erweiterst du dann Stück 
für Stück um Komponenten die dir sinnvoll erscheinen.

Wenn ich das richtig verstanden habe, dann machst du das mit dem FPGA 
zum Selbstzweck? Das ist völlig OK, mach das. Nur Mut, das ist ein sehr 
schönes Themenfeld das du da lernen möchtest. Die Lernkurve ist anfangs 
aber sehr steil wenn man tatsächlich HDL machen möchte und keine 
Hochsprache/Blockdesign aus Fertigbausteinen verwendet.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Martin S. schrieb:
> Python/MyHDL schon in Betracht gezogen?
Wozu? Eine Faltung ist eine Multiplikation mit den Eingangsdaten. Es 
braucht ein RAM für den Echtzeit-Input und einige mit den 
Impulsantworten, die er falten will. Dann ein FSM, die die Adressen 
steuert.

Ganz ehrlich: Das schreibe ich in 2h hin. Simulieren, Verifizieren und 
anpassen auf das board maximal 1 Tag. Das Problem des TE ist weniger das 
FPGA, sondern dass er gar keine Übersicht über die Technologien und die 
Mathe dahinter hat.

Und dann wäre noch die Frage, wie man die Impulsfiles bestimmt und 
berechnet. Die sind nämlich (aus dunkler Erinnerung) das Ergebnis einer 
umgekehrten Laplace-Transformation.

von Martin S. (strubi)


Lesenswert?

Weltbester FPGA-Pongo schrieb im Beitrag #6272364:
> Ganz ehrlich: Das schreibe ich in 2h hin. Simulieren, Verifizieren und
> anpassen auf das board maximal 1 Tag. Das Problem des TE ist weniger das
> FPGA, sondern dass er gar keine Übersicht über die Technologien und die
> Mathe dahinter hat.

NB: Er will irgendwie damit anfangen. Da will man sich vielleicht nicht 
unbedingt mit einer Menge Tools, Programmiersprachen und deren 
Eigenheiten herumschlagen, damit man's dann nach 1-2 Monaten 
Einarbeitung in 2h hinschreiben kann.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Aber genau das wird er tun müssen, "sich mit einer Menge tools 
rumschlagen". Die technische Lösung besteht aus Wissen um Faltung 
(Mathematik), Elektronik (Auswertung der Wandler) und Programmierung 
(VHDL). Mit allen drei Dingen wird man sich befassen müssen.

Zweckmäßiger wäre es, man knöpft sich erst mal die Mathe vor und löst 
das Thema in MATLAB, um den Hintergrund zu verstehen, arbeitet sich dann 
mit einem einfachen Beispiel in Elektronik ein, um AD-Wandlung, 
Filterung und Datenaquise zu verstehen und überlegt sich dann wie das 
alles mit VHDL erledigt werden kann. VHDL lernt man aber auch eher an 
einem einfachen Beispiel. Für alle drei Dinge sind eine Monate gfs aogr 
knapp, wenn man gar nichts weis.

Diese kombinierten "Ich mache alles aus dem Stand"-Geschichten bleiben 
dann oberflächlich und löchrig.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Alex H. schrieb:
> Wie ist so ein Entwickler-Board
> aufgebaut?

Solche Fragen z.B. zeigen mir, dass hier die falsche Person (IT-Berater) 
am falschen Thema dran ist. Der Umgang mit Elektronik ist wohl doch eher 
etwas für Studenten der Elektronik. Dort wird eigentlich alles rund um 
ADC, DAC und Signalverarbeitung geklärt.

Warum sich jetzt die ITler dort noch einmischen und autodidaktisch mal 
eben ins Fachfremde stürzen, will sich mir nicht erschließen. Da kommt 
dann meisten eben wieder irgendeine von MATHWORKS automatisch 
zusammengeschossene C-Software aus dem Coder heraus, der mit viel 
Aufwand auf einen Prozessor gebracht wird, welcher sich in einem FPGA 
befindet, damit man "mal etwas mit FPGAs gemacht hat". Der Code ist dann 
umfangreich, langsam und unbrauchbar.

Damit hat man das, worauf es eigentlich ankommt, nämlich eine Schaltung 
zu entwickeln, nicht einmal angekratzt.

Quereinsteiger, die Cores in die Schaltung schmeißen und fett Silizium 
verbrauchen, gibt es im Markt auch schon genug :-)  Mehr als genug !

von J. S. (engineer) Benutzerseite


Lesenswert?

Alex H. schrieb:
> Konkret geht es dabei um das Falten
> von Raumimpulsantworten mit einem Audiosignal, um hinterher eine
> Mehrkanal-Aufnahme zu erhalten.

Das war vor gut 20 Jahren der große Hit, einen Faltungshall zu 
applizieren, weil man hoffte, so an neue Klangdimensionen zu gelangen. 
Es war aber nur sehr kurz ein richtiger Hit, weil man schnell gemerkt 
hat, dass das nur mit trockenen, also reflexionsfreien Signalen 
funktioniert und auch dort nur begrenzt wegen der Artefakte, die die FFT 
mit sich bringt.

Eine Sourrundaufnahme bekommt man damit schon gar nicht hin, weil immer 
derselbe Datenstrom dupliziert und manipuliert wird, während bei einer 
richtigen Raumantwort Reflexionen der Signale kommen, die ein Instrument 
zur Seite abstrahlt. Das ist also nur dann Dasselbe, wenn es ein 
Punktstrahler ist.

Das ist aber nicht der Fall. Ein Orchester, ja schon eine einzelne 
Geige, strahlt in jede Richtung anders ab. Man kann sich das vorstellen, 
wie ein Spiegel an der Wand, in welchem man den Geiger von der Seite 
sieht. Das ist ein völlig anderes Bild, dass sich mit keinem 
Signalprozessor der Welt aus der Frontansicht ableiten lässt. Die 
Impulsfiles können das nicht leisten, wie man sich vorstellen kann.

Diese müssen aber auch erst einmal prozessiert werden, was nur in der 
Theorie sehr einfach ist, praktisch aber auch wieder an der endlichen 
Auflösung der FFT scheitert. Ich würde daher zunächst mal auf Existentes 
zurückgreifen. Impulse files gibt es wie Sand am Meer.

Bauen kann man das durchaus in DSPs, aber sehr fein und hochaufgelöst 
geht das nur in FPGAs mit sehr stark überlappenden FFTs, wie es 
ansatzweise hier dargestellt ist:

http://www.96khz.org/htm/pitchmodule.htm

Ich habe für einen solchen Fall ein VHDL-Modul entwickelt, da braucht es 
aber auch noch entsprechendes smoothing für die Resynthese des Signals.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.