Forum: FPGA, VHDL & Co. FPGAs in der Lehre


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gerd (Gast)


Lesenswert?

Letzte Woche hatte ich eine Diskussion, ob die Vermittlung der 
Grundlagen von FPGAs in der Lehre an der Hochschule noch Sinn macht.
Gibt es ein Lernprojekt, mit dem den Studenten der Sinn für den Einsatz 
von FPGAs gut vermittelt werden kann?
Mir viel keines ein. In meiner beruflichen Laufbahn bin ich immer ohne 
den Einsatz von FPGAs ausgekommen. Insbesondere da es heute sehr 
schnelle Mikrocontroller gibt (bsp. die H7 Serie von ST) kann man immer 
mehr auf FPGAs verzichten.

von Jochen der Rochen (Gast)


Lesenswert?

Ja, die Vermittlung macht Sinn
Ja, Lehr-/Lernprojekte gibt es massenweise.
Gut, dass heute Freitag ist....

von Duke Scarring (Gast)


Lesenswert?

Gerd schrieb:
> ob die Vermittlung der
> Grundlagen von FPGAs in der Lehre an der Hochschule noch Sinn macht.
Das hängt vermutlich vom Studienfach ab. Bei Zahnmedizin und BWL sollte 
man sich vielleicht auf andere Themen konzentrieren, aber wenn da 
irgendwo digitale Logik in's Spiel kommt, ist FPGA aktueller denn je...

von Gerd (Gast)


Lesenswert?

Jochen der Rochen (Gast)
>Ja, Lehr-/Lernprojekte gibt es massenweise.

Na dann zeig doch mal eines, was mehr macht als eine LED blinkt und man 
wirklich ein FPGA braucht statt eines Mikrocontrollers. Zeige mal ein 
Lernprojekt, welches einen Studenten von heute überzeugen könnte.

von mm (Gast)


Lesenswert?

Gerd schrieb:
> In meiner beruflichen Laufbahn bin ich immer ohne
> den Einsatz von FPGAs ausgekommen. Insbesondere da es heute sehr
> schnelle Mikrocontroller gibt (bsp. die H7 Serie von ST) kann man immer
> mehr auf FPGAs verzichten.

Deine berufliche Laufbahn ist natürlich das Maß aller Dinge. "Ich hab's 
noch nie gebraucht, also braucht's niemand."
Ich sag' nur Maslows Hammer...

Wenn Du mir erklärst, wie Du beispielsweise Signale mit 5Gbps mit einem 
"sehr schnellen" Cortex-M verarbeitest, kannst Du mich vielleicht 
überzeugen.
Ja, man kann natürlich einen ASIC vor den Cortex-M packen, aber 
blöderweise führt der Weg zum ASIC in aller Regel über den "nutzlosen" 
FPGA.

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


Lesenswert?

Gerd schrieb:
> In meiner beruflichen Laufbahn bin ich immer ohne
> den Einsatz von FPGAs ausgekommen. Insbesondere da es heute sehr
> schnelle Mikrocontroller gibt (bsp. die H7 Serie von ST) kann man immer
> mehr auf FPGAs verzichten.
Der Witz ist der Übliche: wenn du FPGA nicht "kannst", wirst du so gut 
wie immer einen Weg finden, FPGAs nicht zu brauchen. Im Zweifelsfall 
kommt dann halt ein zweiter Prozessor aufs Board.

Wenn du FPGA "kannst", dann wirst du bestimmte (hardwarenahe) Aufgaben 
auch automatisch mit einem FPGA lösen, weil es die effizienteste Art 
ist.

Und der absolute Extremfall: wir haben hier ein uraltes Design mit einem 
Z80 samt Peripheriebausteinen von einem 30x30cm² großen Brett per FPGA 
auf eine Platine mit 10x15cm² reduziert und können ein 35 Jahre altes 
Binärfile unverändert darauf fahren und die alte Hardware drumrum weiter 
nutzen. Die "Alternative" wäre ein komplettes Redesign des Rechners mit 
neuem Prozessor und komplett neuem Code gewesen. Weil dafür kein Knowhow 
mehr in der Firma war (Kündigung, Rente...) wäre das eine komplette 
Neuentwicklung mit locker 10 Mannjahren geworden. Mit der Portierung 
konnte das alles in 2 Mannjahren abgevespert werden.

Gerd schrieb:
> Zeige mal ein Lernprojekt, welches einen Studenten von heute überzeugen
> könnte.
Wovon müsste man den überzeugen?

Im Zweifelsfall verlangt man einfach von ihm, er solle 30 unabhängig 
konfigurierbare PWM-Kanäle realisieren...

von Dussel (Gast)


Lesenswert?

Gerd schrieb:
> Jochen der Rochen (Gast)
>>Ja, Lehr-/Lernprojekte gibt es massenweise.
>
> Na dann zeig doch mal eines, was mehr macht als eine LED blinkt und man
> wirklich ein FPGA braucht statt eines Mikrocontrollers.
Eine ALU schreiben. Falls das nicht genehm ist, bin ich auf den 
Vorschlag gespannt, wie man eine neue ALU in einen Mikrocontroller 
bekommt.

Aber die Diskussion ist schon richtig. Ohmsches Gesetz und 
Kondensatorladekurve habe ich in meiner beruflichen Laufbahn nie 
gebraucht und von Maxwellschen Gleichungen kann man Studenten auch nicht 
überzeugen, weil sie von Studenten (und vielen Profis) nur für 
unrealistische Spezialfälle lösbar sind. Das sollte alles nicht mehr 
unterrichtet werden.

von Fitzebutze (Gast)


Lesenswert?

Meine Kunden suchen haenderingend Leute, die Digitalelektronik und 
FPGA-Architekturen richtig verstehen, und nicht einfach die VHDL-Kurse 
an der FH mit Bestnote kassiert haben. Ergo: Ja, die Vermittlung in der 
jetzigen Form macht kaum Sinn. Aus dem Grund haben wir auch eigene Kurse 
entworfen und sehen von VHDL-Murks erst mal ab. Und nein, das alles ist 
nicht mehr oeffentlich und gratis.

Gerd schrieb:
> Mir viel keines ein. In meiner beruflichen Laufbahn bin ich immer ohne
> den Einsatz von FPGAs ausgekommen. Insbesondere da es heute sehr
> schnelle Mikrocontroller gibt (bsp. die H7 Serie von ST) kann man immer
> mehr auf FPGAs verzichten.

Nein, kann man nicht.
NB: fiel. Nicht viel.

von Skyper (Gast)


Lesenswert?

Gerd schrieb:
> Na dann zeig doch mal eines, was mehr macht als eine LED blinkt und man
> wirklich ein FPGA braucht statt eines Mikrocontrollers. Zeige mal ein
> Lernprojekt, welches einen Studenten von heute überzeugen könnte.

Digitale Filter... wir haben damals im Studium, ist bestimmt schon 15 
Jahre her, auf einem Virtex-II Pro Board gebaut. Zwei Takte für die 
Berechnung mit über 100 Filterkoeffizienten ... Takfrequenz lag bei 
1GHz. Das hätte kein Mikroprozessor geschafft...

"Unsere Institutsnachbarn" DESY / XFEL nutzen FPGAs für ihre Detektoren, 
bzw. zur schnellen Datenerfassung und Reduzierung. Auch das CERN setzt 
sie bei Ihren großen Detektoren ein... ohne die Datenreduzierung durch 
FPGAs würden sie die Daten nicht speichern könnnen.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Gerd schrieb:
> Na dann zeig doch mal eines, was mehr macht als eine LED blinkt und man
> wirklich ein FPGA braucht statt eines Mikrocontrollers.

Um eine LED blinken zu lassen, benötigt man nicht einmal einen 
Mikrocontroller, sondern nur zwei Transistoren oder einen 555. Es gibt 
sogar selbstblinkende LED.

Also kann man schon allgemeingültig feststellen, dass heutzutage niemand 
mehr einen Microcontroller und erst recht kein FPGA benötigt.

> Zeige mal ein
> Lernprojekt, welches einen Studenten von heute überzeugen könnte.

Eine Videoausgabe per FPGA. Mit VGA o.ä. war das noch sehr einfach, mit 
aktuellen Digitalschnittstelle (DVI, HDMI, DP) schon deutlich schwieger, 
aber mit gewissem Einarbeitungsaufwand noch machbar. Natürlich sollen 
die Studenten dann nicht einfach nur einen fertigen Funktionsblock 
instantiieren, sondern diesen natürlich selbst schreiben.

von Jochen der Rochen (Gast)


Lesenswert?

Gerd schrieb:
> Jochen der Rochen (Gast)
>>Ja, Lehr-/Lernprojekte gibt es massenweise.
>
> Na dann zeig doch mal eines, was mehr macht als eine LED blinkt und man
> wirklich ein FPGA braucht statt eines Mikrocontrollers. Zeige mal ein
> Lernprojekt, welches einen Studenten von heute überzeugen könnte.

Bei mir war es damals im Studium ein Convolutional Neural Network zur 
Bilderkennung. Wer einfacher anfangen möchte soll halt einfach eine 
Kommunikationsschnittstelle programmieren, denn die sind im 
Mikrocontroller auch in Hardware umgesetzt. Oder noch simpler, einfach 
eine Aufnahme vieler Daten parallel mit verschiedenen Bitraten etc. Das 
kann auf einem Controller schon schnell komplex werden, im FPGA ist es 
sehr simpel.

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


Lesenswert?

Fitzebutze schrieb:
> Aus dem Grund haben wir auch eigene Kurse entworfen und sehen von
> VHDL-Murks erst mal ab.
So halte ich das auch, man muss die 
Praktikanten/Bacheloranden/Masteranden dort abholen, wo sie stehen. 
Manche überschätzen sich da ziemlich.

Jochen der Rochen schrieb:
> einfach eine Kommunikationsschnittstelle programmieren, denn die sind im
> Mikrocontroller auch in Hardware umgesetzt.
Lustigerweise lernt der Delinquent dann am Meisten, wen er die 
Blockschaltbilder eines Timers oder einer SIO aus dem Datenblatt des µC 
mal in eine VHDL-Beschreibung umsetzen muss. Und hinterher schaut er 
solche Blockschaltbilder wesentlich "hardwarenäher" an.

von Martin U. (Gast)


Lesenswert?

Gerd schrieb:
> kann man immer mehr auf FPGAs verzichten.
Richtig! Auf dem zurückliegenden FPGA-Kongress wurde auch das Ende der 
FPGAs zum 31.12.2024 verkündet. Bis dahin werden alle Lagerbestände 
geleert und kräftig abverkauft.

Grund: Intel schließt Altera, um mehr Prozessoren zu verkaufen und AMD 
schließt Xilinx, um mehr Prozessoren zu verkaufen

außerdem gehen die Rohstoffe aus, weil die Russen nur noch an die 
Chinesen liefern und sich dort ihre Chips bauen lassen.

von Martin U. (Gast)


Lesenswert?

Lothar M. schrieb:
> Und der absolute Extremfall: wir haben hier ein uraltes Design mit einem
> Z80 samt Peripheriebausteinen von einem 30x30cm² großen Brett per FPGA
> auf eine Platine mit 10x15cm² reduziert und können ein 35 Jahre altes
> Binärfile unverändert darauf fahren und die alte Hardware drumrum weiter
> nutzen. Die "Alternative" wäre ein komplettes Redesign des Rechners mit
> neuem Prozessor und komplett neuem Code gewesen. Weil dafür kein Knowhow
> mehr in der Firma war (Kündigung, Rente...) wäre das eine komplette
> Neuentwicklung mit locker 10 Mannjahren geworden. Mit der Portierung
> konnte das alles in 2 Mannjahren abgevespert werden.

Ja so machen das die Schwaben!

Schlaue Leute investieren sicher keine 2 Mannjahre, sondern nur 3 
Mannmonate:

Das, was in einen 35 Jahre alten Prozessor Z80 passt (ich kenne das 
Ding!) ist nicht so umfangreich, als dass man es nicht nachprogrammieren 
kann. Tut man das in modernem C, kriegt man dasselbe Tempo mit einen 
billigen Arduino, PIC oder einem anderen Billig-PCB hin.

Dann kann man auch (muss aber nicht) "die alte Hardware" nutzen und hat 
die Option in 2,5V zu bauen, auf Kühlung zu verzichten etc.

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


Lesenswert?

Martin U. schrieb:
> Schlaue Leute investieren sicher keine 2 Mannjahre, sondern nur 3
> Mannmonate
An den Schätzungen waren 6 Abteilungen beteiligt und die 
Softwareabetilung machte den maßgeblichen Anteil an den 10 Mannjahren 
aus.

> sondern nur 3 Mannmonate
Genau solche übers Knie gebrochene Projekte dauern dann regelmäßig 
unverhofft wesentlich länger.

> Tut man das in modernem C, kriegt man dasselbe Tempo mit einen billigen
> Arduino, PIC oder einem anderen Billig-PCB hin.
Es geht nicht nur um Geschwindigkeit, sondern grade in der Industrie 
auch um Funktion. Was bringt es, wenn der hippe Prozessor dann an 
beliebiger Stelle zu schnell ist? Wegen fehlendem KnowHow (hatte ich das 
erwähnt?) zur Technik (die Steuerung steuert eben eine Maschine mit all 
ihren Eigenheiten) muss man dann auf einmal wieder ganz vorne anfangen.

von Fitzebutze (Gast)


Lesenswert?

Martin U. schrieb:
> Das, was in einen 35 Jahre alten Prozessor Z80 passt (ich kenne das
> Ding!) ist nicht so umfangreich, als dass man es nicht nachprogrammieren
> kann. Tut man das in modernem C, kriegt man dasselbe Tempo mit einen
> billigen Arduino, PIC oder einem anderen Billig-PCB hin.

Rechne nochmal, was das kostet, wenn man den Code nachzertifizieren 
muss.
Ich kenne noch mindestens zwei solcher Mimik-Projekte, die 24/7 in 
Gaswarngeraeten bzw. PLC-Nachbildung in Fabriken ihren Dienst tun 
muessen.
Das einzige was da ersetzt wurden durfte, ist der In-Circuit-Emulator.

Und dein Kommentar oben zum FPGA-Angebot fasse ich mal als schalen 
Scherz auf.
Eigentlich hoere ich schon auf zu lesen, wenn einer mit 'Mit Arduino 
geht das billiger' kommt.

von Duke Scarring (Gast)


Lesenswert?

Fitzebutze schrieb:
> Eigentlich hoere ich schon auf zu lesen, wenn einer mit 'Mit Arduino
> geht das billiger' kommt.
Immerhin: In der Anschaffung ist der Arduino schon billiger. Und der 
Entwickler, der nur noch die 'richtigen' Libs finden muß auch...

von M.A. S. (mse2)


Lesenswert?

Gerd schrieb:
> In meiner beruflichen Laufbahn bin ich immer ohne
> den Einsatz von FPGAs ausgekommen.
Das ist doch wirklich das ultimative Freitagsthema.

Ich bin auch immer ohne FPGA ausgekommen. Finde ich sie deswegen 
sinnlos? Nein!
Ich weiß, die Welt ist größer als mein Horizont und es wird Probleme 
geben, die ich nicht habe.

: Bearbeitet durch User
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

M.A. S. schrieb:
> Ich weiß, die Welt ist größer als mein Horizont und es wird Probleme
> geben, die ich nicht habe.

Mit solch einer Einstellung gewinnst Du aber niemals den renommierten 
Troll-Award! :-) Heutzutage gehört es doch zum guten Ton, jeden, der 
nicht exakt die gleiche Sichtweise wie man selbst hat, zu beschimpfen 
oder ihm irgendwelchen politischen Extremismus zu unterstellen. Oder ihn 
zumindest als alten, weißen Cis-Mann zu titulieren.

von M.A. S. (mse2)


Lesenswert?

Andreas S. schrieb:
> Mit solch einer Einstellung gewinnst Du aber niemals den renommierten
> Troll-Award! :-)
Mist! Ich werde meine Einstellung über das Wochenende überdenken.
:)

von Falk B. (falk)


Lesenswert?

Gerd schrieb:
> Mir viel keines ein. In meiner beruflichen Laufbahn bin ich immer ohne
> den Einsatz von FPGAs ausgekommen. Insbesondere da es heute sehr
> schnelle Mikrocontroller gibt (bsp. die H7 Serie von ST) kann man immer
> mehr auf FPGAs verzichten.

Schöner Trollversuch. Es ist Freitag ;-)

von raX (Gast)


Lesenswert?

Gerd schrieb:
> Insbesondere da es heute sehr
> schnelle Mikrocontroller gibt (bsp. die H7 Serie von ST) kann man immer
> mehr auf FPGAs verzichten.

Eieiei, Du weist schon was ein Mikrocontroller macht und was man mit 
einem FPGA machen kann?

von Gerhard H. (ghf)


Lesenswert?

Lothar M. schrieb:
> Martin U. schrieb:
>> Schlaue Leute investieren sicher keine 2 Mannjahre, sondern nur 3
>> Mannmonate
> An den Schätzungen waren 6 Abteilungen beteiligt und die
> Softwareabetilung machte den maßgeblichen Anteil an den 10 Mannjahren
> aus.
>
>> sondern nur 3 Mannmonate
> Genau solche übers Knie gebrochene Projekte dauern dann regelmäßig
> unverhofft wesentlich länger.

Frederico Faggin und Matoshi Shima haben für den Z80 6 Monate
gebraucht, inclusive Handlayout auf Rubylith. 7500 Transistoren.
Das war wohl so weil keine Software-Abteilung involviert war.

Wir haben $(DAMALS) an der TUB eine 16 Bit Stackmaschine in
HP's dynamischen NMOS-Prozess gemacht, lose angelehnt an
Tanenbaum's EM p-code machine. Das war für das halbe Dutzend
Studenten jeweils 6 Semesterwochenstunden wert. OK, der
Aufwand war schon größer. Und die Nachbarn auf dem Multiprojekt-
Wafer haben uns einen Metallbalken quer über den ganzen Chip
geschenkt den der Design rule checker nicht bemerkt hat weil
der die Chips nur einzeln betrachtet hat. :-(

von DoS (Gast)


Lesenswert?

Macht doch einen FPGA-Core mit 30 SPI-Slaves, der von 30 SPI-Mastern 
asynchron Daten empfängt und diese dann in einem Log (Timestamp Quelle) 
weg schreibt. Das demonstriert die Gleichzeitigkeit, die Skalierbarkeit 
und die IO-Kapazität von FPGAS.

von DoS (Gast)


Lesenswert?

Ich hatte unlängst ein entsprechendes Projekt mit einem Raspi und vielen 
Arduinos und keiner wollte SPI-Slave sein. Nun für ein FPGA war das kein 
Problem.

von dfIas (Gast)


Lesenswert?

Gerd schrieb:
> ... Insbesondere da es heute sehr
> schnelle Mikrocontroller gibt (bsp. die H7 Serie von ST) kann man immer
> mehr auf FPGAs verzichten.
Hier mal schauen:
https://www.microchip.com/en-us/products/fpgas-and-plds/radiation-tolerant-fpgas/rtg4-radiation-tolerant-fpgas
https://www.microchip.com/en-us/product/rtax4000s
Bei den aktuellen Space-Projekten verzichten wir damit auf µCs/CPUs!

von Murkser (Gast)


Lesenswert?

Lothar M. schrieb:
> Wegen fehlendem KnowHow (hatte ich das
> erwähnt?)
Ja, hattest du.

> muss man dann auf einmal wieder ganz vorne anfangen.
nur, wann die "Macher" von damals keinen Softwareplan erstellt haben und 
irgendwas zusammengehackt haben, was damals schon zu lange gedauert hat, 
weil zuviele Iterationen stattgefunden haben, womit die Angstschätzung 
10 Mannjahre plausibel wird.

Das muss aber nicht so sein. Es ist allemal besser, alten 
undokumentierten Kram zu ersetzen zumal man in der Regel ohnehin 
formelle Anforderungen hat, die es zu erfüllen gilt. So ein 
Bastelgefrickel irgendwas blind wieder wo reinwerfen, kann man sich nur 
in bestimmten Industriezweigen erlauben.

In der Militär, der Luftfahrt, der Autotechnik und der Medizin ist
a) die Einhaltung formeller Prozesse gefordert
b) ein Softwaretest von Nöten, mit u.U. 4-Augen-Screening

Beides kann man nicht, wenn man die SW nicht genau mit Anforderungen 
unterlegt und deren Antworten definiert, sowie mit Code-Analysen belegt 
hat. Das heisst:

In praktisch allen relevanten Branchen, müsste diese alte Software erst 
einmal qualifiziert und analysiert werden, ein Testplan nachgereicht und 
ein Integrationstest gemacht werden. Dazu muss die Software entweder 
reengineered oder neu entwickelt werden und als Vorstufe braucht man die 
Requirements die sich aus den

- Betriebszuständen der Maschine
- Eingaben vom Bediener
- Einflüsse der Umwelt (Fehler)
- Operattionsmodi

ableiten. Dann und nur dann kann man einen Testplan machen und einiges 
davon im SW-Unit-Test und anderes im Integrationstest mit der HW 
nachweisen.

So, durch alleiniges Nutzen der alten und nichtverifizierten Software 
übernehmt ihr alle versteckten bugs, Mängel, unzureichende Rundungen und 
mögliche Probleme.

Aus formellen wie aus praktischen Gründen darf so eine Software gar 
nicht mehr eingesetzt werden - außer eben von Frickelbuden, denen die 
Kunden die Aufgabe weitergetreten haben, um genau die beschriebenen 
Probleme sauber zu umgehen, nachdem sie ihren Liferanten auditiert 
haben.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

Ich kenne ein FPGA-Beispiel, das in der Lehre verwendet wurde: ein 
Fahrradcomputer.
Eingänge waren Clock und der Reed-Kontakt, Ausgänge waren die 
Segmentausgänge für eine 2-stellige 7-Segmentanzeige für km/h. Der 
Radumfang in cm war glaube ich fix vorgegeben.
Zusätzliche Vorgabe war, dass die Division von Hand mit Schieberegistern 
gebaut wird.

Aber einen FPGA braucht man dafür natürlich nicht. Und dass der Code 
danach mit dreistellig MHz laufen könnte, statt den vorgegebenen paar 
kHz, ist herzlich nutzlos.

Lothar M. schrieb:
> Jochen der Rochen schrieb:
>> einfach eine Kommunikationsschnittstelle programmieren, denn die sind im
>> Mikrocontroller auch in Hardware umgesetzt.
> Lustigerweise lernt der Delinquent dann am Meisten, wen er die
> Blockschaltbilder eines Timers oder einer SIO aus dem Datenblatt des µC
> mal in eine VHDL-Beschreibung umsetzen muss. Und hinterher schaut er
> solche Blockschaltbilder wesentlich "hardwarenäher" an.

Kann sein. Das selbstgeschriebene Lehrmaterial, mit dem man uns VHDL 
erklären wollte, kam damals vermutlich von jemandem, der Hardware gut, 
VHDL eher schlecht konnte. Da wurden dann Beispiel-Logikschaltungen 
"wörtlich", Gatter für Gatter in VHDL übersetzt. Der Code war wenig 
idiomatisch, das hätte man bei gleicher Funktion deutlich einfacher und 
verständlicher schreiben können.

von Bierbaron (Gast)


Lesenswert?

Duke Scarring schrieb:
> Gerd schrieb:
>> ob die Vermittlung der
>> Grundlagen von FPGAs in der Lehre an der Hochschule noch Sinn macht.
> Das hängt vermutlich vom Studienfach ab. Bei Zahnmedizin und BWL sollte
> man sich vielleicht auf andere Themen konzentrieren, aber wenn da
> irgendwo digitale Logik in's Spiel kommt, ist FPGA aktueller denn je...

komisch, dass es kaum jobs gibt in dem bereich ;)
Wenn ich in den Jobbörsen Hardware oder FPGA eingebe kriegste nur paar 
Stellen für langjäährige Berufserfahrung (Raum BW). So groß kann der 
Bedarf nicht sein.

von Murkser (Gast)


Lesenswert?

Bierbaron schrieb:
> für langjäährige Berufserfahrung (Raum BW). So groß kann der
> Bedarf nicht sein.
Das liegt darin, dass es eben nur für sehr wenige spezielle Vertiefungen 
wirklich Bedarf gibt. Feld-, Wald- und Wiesenschaltungen kann ja jeder 
bauen. Praktisch jeder Student kann das, spätestens mit etwas lernen. 
Das bischen Verschaltung ist dasselbe, wie bei einem Altium-Design: 
Blöckchen malen und verbinden.

Der Sachverhalt bei FPGAs ist der, daß das meiste Zeug mit AXI und 
Prozessoren zusammengesteckt wird, damit billig programmiert werden 
kann. Das geht, weil die FPGAs so billig und so schnell sind. Wenn mit 
AXI und somit zeitlicher Entkoppelung der Module gearbeitet wird, muss 
kein kompliziertes Zeitverhalten eingehalten werden, weil sich das von 
selber regelt. Das ist zwar ineffektiver, geht aber 
kostenrechnungstechnisch trotzdem auf. Die Schaltungsschicht der 
mittelkomplexen Ebene erledigen Mathlab und andere mit automatischer 
Code-Erzeugung oder es wird Python eingesetzt.

FPGA-Entwicklung ist heute nicht mehr das, was es einst war. Es ist mehr 
so etwas wie "Kleincomputer zusammenkonfigurieren", Bios bauen lassen 
und draufladen. Ab dann hast du einen Mini-PC, der eingesetzt werden 
kann, wie ein Raspi. Das sieht man auch an den Stellenanzeigen: Die 
nennen sich "FPGA-Entwickler gesucht" fordern aber viel C++, Python und 
so. VHDL oft nicht mal mehr erwähnt, Elektronikkenntnisse so gut wie gar 
nicht. Die Plattformen werden oft genug auch fremdbeauftragt.

Für die richtig komplexen Projekte gibt es FPGA-Design-Service-Firmen 
und Freelancer genug. Die Design-Service-Firmen nimmt man, wenn es hohe 
Termintreue braucht und Tempo gefordert ist, weil da mehrere Leute 
rankönnen und das Projektrisiko verlagert werden kann. Die freelancer 
kommen rein, wenn man den Wasserkopf und die Gewinne dieser Firmen nicht 
mitbezahlen möchte und das Projekt auf maximal 2-3 solcher Leute 
verteilbar ist.

FPGA-Entwicklung auf der unteren Ebene macht heute jeder, daher sind 
auch die Gehälter stark gesunken: Wo es vor 10 Jahren noch locker 80.000 
für einen Entwickler mit 3 Jahren Erfahrung gab, sind heute für 
Spezialisten kaum mehr drin - trotz Teuerungsrate. Kannst ja hier mal 
fragen, ob sie 100.000 rausrücken. Mir haben sie direkt abgesagt:
https://www.mikrocontroller.net/jobs/senior-firmware-entwickler-new-tec

Auch im Ländle wird nicht mehr so gut bezahlt, weil auch diese Firmen in 
starker Konkurrenz stehen. Spricht ohnehin nicht unbedingt für ein zu 
erwartendes Spitzengehalt, wenn eine Firma hier im Forum sucht, wie ich 
auch in anderen Fällen erfahren musste.

von MATLAB-user (Gast)


Lesenswert?

Tilo R. schrieb:
> Kann sein. Das selbstgeschriebene Lehrmaterial, mit dem man uns VHDL
> erklären wollte, kam damals vermutlich von jemandem, der Hardware gut,
> VHDL eher schlecht konnte. Da wurden dann Beispiel-Logikschaltungen
> "wörtlich", Gatter für Gatter in VHDL übersetzt.

Was aber eigentlich so falsch nicht ist, weil das am Ende mit jeder 
Schaltung gemacht werden muss, um sie in ein Netzlistenformat zu 
überführen. Die Frage ist nur, ob der Ersteller das alles tun muss.

Vom dem Ansatzpunkt einer Lehre sollte man durchaus dort beginnen, dass 
jemand zunächst bei sehr einfachen Schaltungen die Strukturen und 
Formulierungen lernt, bevor er zu Größerem übergeht. Das wird aber 
übersprungen. Was hier an Jungvolk mit FPGA-Kenntnissen umherschleicht, 
hat auf der Hochschule zwar etliche SoCs zusammengeklickt und Cores in 
rauhen Mengen hineingeworfen, aber die Eigenleistung (Suchen, Klicken, 
Platzieren, Rücken, Linien dranmalen) war oft minimal. Vor allem war die 
Qualität der Eigenleistung gering: Es wurde einfach nur zusammengesteckt 
und akzeptiert, was herausgekommen ist, ohne eine Untersuchung von 
Alternativen und Effizienz. Einen hohen Anspruch hat das nicht. Den 
jungen Leuten wird damit die Tool-Bedienung beigebracht und weniger die 
Inhalte. Das sind dann aber alles Entwicklungen auf Prototypen-Niveau, 
die erst überarbeitet werden müssen, bevor sie produktionsfähig werden, 
weil sie so viel zu teuer und zu schlecht sind.

Der Witz in meinem Fall ist, dass ich mit meinem Studium und Werdegang 
mehr Wissen in Digitaltechnik habe, als die und damit in der Lage bin, 
in Simulink oft den ganzen FPGA hinzumalen, dass er effektiv 
funktioniert. Auch den MATLAB-Protytypen-Code kann ich selbst oft noch 
besser überarbeiten, als meine Nachfolger.

Wer aber soll diese Schaltungen einmal effizient machen, wenn die 
Anfänger nur auf Klick-Ebene arbeiten und das niemals lernen? Womit soll 
sich beispielsweise eine Firma differenzieren, wenn alle so arbeiten und 
sie genau dasselbe anbietet, wie die anderen Firmen auch, welche 
Anfänger ohne gutes Elektronikwissen beschäftigen?

Murkser schrieb:
> Auch im Ländle wird nicht mehr so gut bezahlt, weil auch diese Firmen in
> starker Konkurrenz stehen.
Es gibt mittlerweile so viele Anbieter von 
FPGA-Entwicklungsdienstleistung, dass die sich gegenseitig das Heu 
wegfressen und die Auftraggeber brutal über den Preis gehen und an den 
Günstigsten vergeben. Also arbeiten diese Firmen alle mit den Margen, 
die sich bei den Kosten für Gehalt, Infrastruktur und Sozialabgaben 
gerade so noch rechnen und diese Schere geht immer weiter zusammen.

Entsprechend hart müssen sie verhandeln, ihre Mitarbeiter knapp halten 
und sogar versuchen, ihre Auftraggeber über den Tisch zu ziehen, indem 
sie sich toll präsentieren, Risiken durch Verträge geschickt umgehen, 
die Rosinen herauspicken, diese als umständlich und schwierig hinstellen 
und dann im Hinterzimmer mit möglichst billigen Fachkräften oder 
Studenten wuseln, um dann zu behaupten, sie hätten alle Designprozesse 
eingehalten.

Bierbaron schrieb:
> komisch, dass es kaum jobs gibt in dem bereich ;)
Das wundert mich kein bisschen. Da viele dieser Fachkräfte immer mehr 
aus dem Ausland kommen und in großer Zahl in den Markt drängen, drücken 
sie die Gehälter nach unten, was dazu führt, dass derjenige am 
billigsten anbieten kann, der die meisten billigen Mitarbeiter 
beschäftigt.

Eigentlich sollte jeder schauen, dass er sich so schnell wie möglich aus 
dem Feld FPGA verabschiedet oder eine Nische sucht, die noch unbesetzt 
ist. Frag mich aber bitte keiner, welche das sein könnte. Ach ja: MATLAB 
macht heute auch jeder :-)

von Bierbaron (Gast)


Lesenswert?

MATLAB-user schrieb:
> Eigentlich sollte jeder schauen, dass er sich so schnell wie möglich aus
> dem Feld FPGA verabschiedet oder eine Nische sucht, die noch unbesetzt
> ist. Frag mich aber bitte keiner, welche das sein könnte. Ach ja: MATLAB
> macht heute auch jeder :-)

Es gibt keine Nischen mehr. Die Leute kloppen sich mit Studium 
mittlerweile um Stellen die von Ausgebildeten besetzt werden. Was im 
Moment gut geht ist IT und Software. Aber Hardware kannst du als 
Absolvent völlig in die Tonne kloppen. Da gibt es ca. 0 Jobs, nur für 
Experten (Berufserfahrene) geht da was. ICs nach Application Notes 
zusammenfummeln kann halt wirklich so gut wie jeder. Nach einem Udemy 
Kurs kannst du auch DDR-RAM layouten... Oder du lässt es vom billig 
Inder machen. Entwicklung wird immer weniger hier :)

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


Lesenswert?

Murkser schrieb:
> nur, wann die "Macher" von damals keinen Softwareplan erstellt haben und
> irgendwas zusammengehackt haben
Ja, genau das ist das wahre Leben. Du träumst von einem "Softwareplan" 
bei einem Projektbeginn vor über 40 Jahren. Viele von diesen heute 
normalen Softwareentwicklungs- und - verwaltungsmodellen waren 
damals(tm) noch gar nicht erfunden.

Die Sprache war irgendein HP spezifisches Pascal-Derivat und die 
Entwicklungsrechner kommodengroße Monster mit 8"-Floppys.

Glaub mir: das Beibehalten der Software und die Integration der Hardware 
in ein FPGA es war eine kluge Entscheidung. Sie hätte evtl. anders 
ausgesehen, wenn du in der Runde gesessen hättest und schon bei 
vorausgegangenen Projekten nachweislich gute Bedarfsschätzungen 
hingelegt hättest.

MATLAB-user schrieb:
> Frag mich aber bitte keiner, welche das sein könnte.
Ich empfehle, Entwickler bei einem Maschinenbauer zu werden. Man sollte 
natürlich ein wenig was draufhauen.

Tilo R. schrieb:
> Da wurden dann Beispiel-Logikschaltungen "wörtlich", Gatter für Gatter
> in VHDL übersetzt
Ja, das ist dann auch tragisch, wenn der Student erst mal eine 
Komponente "Inverter" baut und genauso ein einzelnes "D-FF" und die dann 
händisch im Top-Modul instantiiert und zu einfachsten Funktionen 
zusammenpappt, statt diese Aufgabe in 1 Zeile VHDL zu erledigen.

: Bearbeitet durch Moderator
von Falk B. (falk)


Lesenswert?

MATLAB-user schrieb:
> Tilo R. schrieb:
>> Kann sein. Das selbstgeschriebene Lehrmaterial, mit dem man uns VHDL
>> erklären wollte, kam damals vermutlich von jemandem, der Hardware gut,
>> VHDL eher schlecht konnte. Da wurden dann Beispiel-Logikschaltungen
>> "wörtlich", Gatter für Gatter in VHDL übersetzt.
>
> Was aber eigentlich so falsch nicht ist,

Doch, ist es. Wenn gleich VHDL sicher keine Hochsprache ist, so hat es 
doch eine gewisse Abstraktionsebene (RTL, Register Transfer Level), das 
man auch nutzen sollen. Man beschreibt FUNKTION, nicht UMSETZUNG.

> weil das am Ende mit jeder
> Schaltung gemacht werden muss, um sie in ein Netzlistenformat zu
> überführen. Die Frage ist nur, ob der Ersteller das alles tun muss.

EBEN! Schau dir mal als abschreckendes Beispiel den BO8 an!

https://www.mikrocontroller.net/articles/8bit-CPU:_bo8

> Vom dem Ansatzpunkt einer Lehre sollte man durchaus dort beginnen, dass
> jemand zunächst bei sehr einfachen Schaltungen die Strukturen und
> Formulierungen lernt, bevor er zu Größerem übergeht.

Jain. Aber nur Kurz, umd das Prinzip zu zeigen.

> Das wird aber
> übersprungen. Was hier an Jungvolk mit FPGA-Kenntnissen umherschleicht,
> hat auf der Hochschule zwar etliche SoCs zusammengeklickt und Cores in
> rauhen Mengen hineingeworfen, aber die Eigenleistung (Suchen, Klicken,
> Platzieren, Rücken, Linien dranmalen) war oft minimal. Vor allem war die
> Qualität der Eigenleistung gering: Es wurde einfach nur zusammengesteckt
> und akzeptiert, was herausgekommen ist, ohne eine Untersuchung von
> Alternativen und Effizienz. Einen hohen Anspruch hat das nicht.

Ist nicht viel anders als in der Software, wo mit massiv überladenen 
Frameworks und sonstwie Tools jeder Spatz mit einer IT-Atombombe 
erschlagen wird.

> Den
> jungen Leuten wird damit die Tool-Bedienung beigebracht und weniger die
> Inhalte. Das sind dann aber alles Entwicklungen auf Prototypen-Niveau,
> die erst überarbeitet werden müssen, bevor sie produktionsfähig werden,
> weil sie so viel zu teuer und zu schlecht sind.

Hehe ;-)

> Der Witz in meinem Fall ist, dass ich mit meinem Studium und Werdegang
> mehr Wissen in Digitaltechnik habe, als die und damit in der Lage bin,
> in Simulink oft den ganzen FPGA hinzumalen, dass er effektiv
> funktioniert. Auch den MATLAB-Protytypen-Code kann ich selbst oft noch
> besser überarbeiten, als meine Nachfolger.

Wird es dir gedankt? Schläcgt sich das in deinem (ökonomischen) Erfolg 
nieder?

> Wer aber soll diese Schaltungen einmal effizient machen, wenn die
> Anfänger nur auf Klick-Ebene arbeiten und das niemals lernen?

Bei fallenden Preisen interessiert das immer weniger. Nur dort, wo es 
WIRKLICH an die Leistungsgrenzen geht, müssen die echten, old school 
Profis ran. Das sind aber Nischen.

> Murkser schrieb:
>> Auch im Ländle wird nicht mehr so gut bezahlt, weil auch diese Firmen in
>> starker Konkurrenz stehen.
> Es gibt mittlerweile so viele Anbieter von
> FPGA-Entwicklungsdienstleistung, dass die sich gegenseitig das Heu
> wegfressen und die Auftraggeber brutal über den Preis gehen und an den
> Günstigsten vergeben. Also arbeiten diese Firmen alle mit den Margen,
> die sich bei den Kosten für Gehalt, Infrastruktur und Sozialabgaben
> gerade so noch rechnen und diese Schere geht immer weiter zusammen.

Nennt sich Markt. Ein Überangebot läßt die Preise sinken. Gut für 
Einkäufer, schlecht für Anbieter.

> Eigentlich sollte jeder schauen, dass er sich so schnell wie möglich aus
> dem Feld FPGA verabschiedet oder eine Nische sucht, die noch unbesetzt
> ist. Frag mich aber bitte keiner, welche das sein könnte. Ach ja: MATLAB
> macht heute auch jeder :-)

Gibt keine wirklichen Nischen mehr. Und es kann ja nicht die Masse in 
der Nische landen. Ich hab FPGA vor 20 Jahren gemacht (ohje, so lange 
schon her?!?) War cool! Bin dann aber, ungesteuert, woanders hin 
gedriftet.

von PittyJ (Gast)


Lesenswert?

Wir haben auf fast allen neueren Platinen ein FPGA drauf. Zusätzlich zum 
Linux oder STMH7. Die FPGAs werden benutzt um ein genaues Zeitverhalten 
von Steuersignalen zu erzeugen, das ein Prozessor niemals machen könnte.

Da reicht oft schon ein kleines FPGA von Lattice. Aber es ist vorhanden, 
und muss auch programmiert werden.

von vancouver (Gast)


Lesenswert?

Ich kann nur den Kopf schütteln, wenn ich sehe, wie sich einige 
Abteilungen bei uns einen abbrechen mit ihren Multicore Multitasking 
Realtime OS Highend ARM Controllern für ein Problem, das man mit einem 
30-Euro-FPGA bei 100Mhz erschlagen könnte.
Wir haben schon vor Jahren damit begonnen, die meisten DSPs durch FPGA 
zu ersetzen. Bei einigen Designs verwenden wir sogar einen 
Softcore-Prozessor im FPGA (Microblaze oder RISC-V), der die Steuerung 
und das Housekeeping übernimmt, statt einen externen MCU zu spendieren. 
Zwar sind die reinen MCUs nur Pfenningskram, aber wenn man die 
zusätzliche PCB-Fläche, den Speicher, das Interfacing an den FPGA, evtl 
zusätzliche Spannungsregler und nicht zuletzt die Abhängigkeit von einem 
weiteren Hersteller berücksichtigt, ist ein größerer FPGA unterm Strich 
billiger. Nicht immer, aber oft.

Leider haben in den letzten 20 Jahren viele Hochschulen die selbe 
Einstellung wie der TO verfolgt. Reinrassige Vorlesungen über 
Chipdesign, Architekturentwurf, RTL-Modellierung, wie ich sie in den 90 
gehört habe, sind selten geworden. Sogar die "Bayrische 
Exzellenz-Universität" die wir hier vor der Haustür haben, bieten nichts 
mehr an außer einen Kurs "VHDL-Programmierung", an dessen Ende die 
funktionale Simulation einer Ampel- oder einer Aufzugsteuerung steht. 
Also richtige Männerthemen, sozusagen "die bleeding edge" des 
Digitaldesigns. Begründung für den Wegfall der Vorlesungen: "Die 
Amerikaner und Chinesen sind uns da so weit voraus, das holen wir nie 
ein, wir müssen uns auf unsere Kernkompetenzen besinnen, mimimimi."

Eigentlich müssen wir Trumputin dankbar sein, dass sie mal ein bisschen 
Leben in die Bude gebracht haben.  Die EU legt jedenfalls jetzt 40 
Milliarden Bucks auf den Tisch, um das Chipdesign auf Vordermann zu 
bringen, und schon geht, wie sagt man so schön, an den Unis ein Rauschen 
durch den Blätterwald...

von Falk B. (falk)


Lesenswert?

vancouver schrieb:
> Eigentlich müssen wir Trumputin dankbar sein, dass sie mal ein bisschen
> Leben in die Bude gebracht haben.  Die EU legt jedenfalls jetzt 40
> Milliarden Bucks auf den Tisch, um das Chipdesign auf Vordermann zu
> bringen,

Geld allein löst keine Probleme, es braucht allem die richtige 
Einstellung bzw. Geisteshaltung. Da sehe ich beim dekadenten, 
wohlstandsverwahlosten Westen eher keine Verbesserung. Warum auch? Der 
Ladenläuft doch (noch)!

> und schon geht, wie sagt man so schön, an den Unis ein Rauschen
> durch den Blätterwald...

Die suchen vor allem Drittmittel und ABM für ihre Belegschaft . . .

von Mcn (Gast)


Lesenswert?

Falk B. schrieb:

>> Eigentlich sollte jeder schauen, dass er sich so schnell wie möglich aus
>> dem Feld FPGA verabschiedet oder eine Nische sucht, die noch unbesetzt
>> ist. Frag mich aber bitte keiner, welche das sein könnte.
>
> Gibt keine wirklichen Nischen mehr.
20 Jahre im Beruf und immer noch nicht in der Lage das Füllwort "Nische" 
mit Inhalt wie Branchenbegriffe zu füllen" ?!

Es gibt drei Hauptanwendungen für Programmierbare Logic:
-Prototypen/test
-parallele Echtzeitlogic (Klein serie)
-Glue Logic im weitgefassten rahmen 
(https://de.wikipedia.org/wiki/Glue_Logic)

In Branchen wäre das:
-Automatisierungstechnik, insbesonders optische Inspektion und 
Ultraschall (SICK AG, National Instruments, Baumer Group, general 
electric, vector informatik)
-Telekommunikations-Infratechnik (Rohde&Schwarz, Huawei, Ericsson)
-medizintechnik bildgebende Verfahren ( Philips, Siemens (Forchheim, 
Erlangen)
-Messtechnik (Rohde&Schwarz, teradyne, Bruker Corporation, DLR & OHB 
(wenn man space als Messtechnik verstehen will)
-Halbleiter-design (FPGA sind eben wie die Name sagt eine realisierung 
von Digitalschaltunegen) (Apple, Infineon, Fujitsu, ARM)
-Avionik/Defense (Hensoldt, Thales, ESG)

Und parallel zu den Branchen könnte man Lasertechnik nennen, deren 
Galvanometersteuerung muss oft so schnell sein, das µC zu variabel in 
der response time sind , sind (Jenoptik, Scanlab, Thorlabs).

Und natürlich gibt es auch die Exoten wie Crypto-Miner, realtime 
trading, Retro-Obsoloscence-Ausgleicher, ... .

Und da spielen auch einige der klassischen freiberufler/Ingenieursbüros 
mit, weil es eben eher kleine Stückzahlen und Sonderanfertigungen sind, 
bei deren realisierung man gern zu FPGA greift, weil man da mehr 
designfreiheiten hat als bei einen auf Mainstrean-App optimierte 
mikrocontroller.

Wobei es eben ausser Berufsstart wenig Einstigpunkte für FPGA-Entwickler 
gibt, der Quereinstieg, nach 20 Jahren SAP-Büroinformatik in die 
VHDL-Programmierung einzusteigen, ist eher ein Wunschtreum 
wegrationalisierte Codierschweine als Realität. Vielleicht weil man eben 
gerade in der "Nische FPGA" den breiten Überblick über die 
Systemarchitektur braucht. Weil man eben ganze Maschinen/smart sensors 
baut und nicht nur Bibliotheken einbindet und Testreports nach 
Vorschrift generiert.

von Bierbaron (Gast)


Lesenswert?

Mcn schrieb:
> Und natürlich gibt es auch die Exoten wie Crypto-Miner, realtime
> trading, Retro-Obsoloscence-Ausgleicher, ... .

das gibts mittlerweile ASICs für

von vancouver (Gast)


Lesenswert?

Falk B. schrieb:
> Geld allein löst keine Probleme, es braucht allem die richtige
> Einstellung bzw. Geisteshaltung.

Das ist richtig, aber zum Erlangen der richigen Einstellung ist Geld 
manchmal sehr förderlich.

Falk B. schrieb:
> Da sehe ich beim dekadenten,
> wohlstandsverwahlosten Westen eher keine Verbesserung.

Noch nicht. Die meisten würden weiterhin lieber den Billigcontroller vom 
Chinesen verwenden als den 50 Cent teureren aus Europa (wenn es ihn denn 
mal gibt). Aber wenn die Chinesen mal Taiwan überfallen (und ich bin 
relativ sicher, dass sie das tun werden, auch wenn ihnen das 
Ukraine-Desaster der Russen einen mächtigen Schrecken eingejagt hat) und 
TSMC dicht macht, dann wird sich das relativ schnell ändern. Vielleicht 
macht TSMC auch schon vorher dicht, weil niemand mehr im Vorhof zur 
Hölle arbeiten will.

Falk B. schrieb:
> Die suchen vor allem Drittmittel

Die EU-Gelder sind Drittmittel.

> und ABM für ihre Belegschaft . . .

Oh, Uni-Bashing. Daher weht der Wind.

von Mcn (Gast)


Lesenswert?

Bierbaron schrieb:
> Mcn schrieb:
>> Und natürlich gibt es auch die Exoten wie Crypto-Miner, realtime
>> trading, Retro-Obsoloscence-Ausgleicher, ... .
>
> das gibts mittlerweile ASICs für

Wer halt zu spät kommt, denn bestraft das Leben. Es sei denn, er sucht 
sich eine neues Betätigungsfeld für seine Vorreiterfähigkeiten, bspw.: 
https://chime-experiment.ca/en.

Die Umsätze der FPGA-Firmen klettern seit Jahrzehnten stetig, da ist 
eine baldige Ablöse unwahrscheinlich: 
https://www.golem.de/news/fpgas-xilinx-macht-ein-drittel-mehr-umsatz-und-kauft-solarflare-1904-140873.html

von Falk B. (falk)


Lesenswert?

vancouver schrieb:
>> und ABM für ihre Belegschaft . . .
>
> Oh, Uni-Bashing. Daher weht der Wind.

Jaja, es leben die Extreme. Ich will nicht behaupten, daß ALLE 
Uni-Angestellten in der Ecke zu finden sind. Leider mußte ich in den 
letzten ~20 Jahren feststellen, daß überwiegend diese mir über den Weg 
gelaufen sind. Mal überlegen. Hmmm. Bei den drei bis vier Projekten, bei 
denen ich mehr oder minder Einblick hatte oder gar beteiligt war, ist 
nicht viel rausgekommen. Und das lag oft an den Leuten, nicht am 
Projektinhalt. Mir ist der Unterschied zwischen Forschung und 
Entwicklung schon klar. Bei Forschung weiß man an Anfang nicht was 
rauskommt, bei Entwicklung schon. Trotzdem ist es eine Frage, wie man 
die Sache angeht. Ich schweife ab.

: Bearbeitet durch User
Beitrag #7236002 wurde von einem Moderator gelöscht.
Beitrag #7236014 wurde von einem Moderator gelöscht.
von Wühlhase (Gast)


Lesenswert?

vancouver schrieb:
> Aber wenn die Chinesen mal Taiwan überfallen (und ich bin
> relativ sicher, dass sie das tun werden, auch wenn ihnen das
> Ukraine-Desaster der Russen einen mächtigen Schrecken eingejagt hat) und
> TSMC dicht macht, dann wird sich das relativ schnell ändern.

Ich glaube nicht daß sich da was ändern wird. Dafür ist die 
Geisteshaltung, die der TS hier vermittelt, viel zu weit verbreitet und 
zu tief verwurzelt. Der zieht jetzt gerade die zweite oder dritte 
Wohlstandskükengeneration hoch.

Die, die die besagten Veränderungen noch herbeiführen könnten bzw. die 
entsprechende Einstellung vermitteln könnten, stehen kurz vor der Rente 
und genießen aktuell ein recht klägliches Ansehen. Die wird man erst 
dann - wenn überhaupt - vermissen, wenn sie nicht mehr da sind, aber das 
ist dann zu spät.

Ich meine, das muß man sich mal reinziehen: Da will jemand an einer 
Hochschule lehren und muß hier ernsthaft fragen, ob FPGAs noch Sinn 
haben. Hoffen wir mal, daß es nur ein Troll war, aber ich halte solche 
Dozenten leider tatsächlich für realistisch.

von Mcn (Gast)


Lesenswert?

Wühlhase schrieb:

> Ich meine, das muß man sich mal reinziehen: Da will jemand an einer
> Hochschule lehren und muß hier ernsthaft fragen, ob FPGAs noch Sinn
> haben. Hoffen wir mal, daß es nur ein Troll war, aber ich halte solche
> Dozenten leider tatsächlich für realistisch.

Ja, das mag erschreckend sein, aber "einige Dozenten" sind nicht gleich 
"100% des Bildungssystems" und viel vom Fortschritt wurde von jungen 
Studenten und Uniabbrechern auf Eigeninitiative entwickelt.

Beispielsweise Linus Torvalds, der hat Linux 0.1 wegen Sex-Mangel allein 
in seine Studentenbude geschrieben und viel von einem Professer gelernt, 
der Linus Architektur als 'obsolete' (veraltet) verunglimpfte.

Oder in Sachen Hardware wären die beiden Steves (Wozniak und Jobs) und 
Bil Herd zu nennen. Letzterer hatte gar keine Ausbildung, aber dafür ein 
Alkohol- und ein Arroganzproblem. Hat trotzdem einen bemerkenswerten 2 
CPU Computer in Rekordzeit aus dem Boden gestampft - typisch 
amerikanisch: formale Ausbildung ist weniger wichtig, entscheidend ist, 
ob man das aus Leidenschaft macht und bereit ist, sich den Arsch 
abzuarbeiten.

Und die Geschichte hat gezeigt, das Einzelne 'Genies' reichen um einen 
Tross von Arbeitsdrohnen mitzureissen und Bemerkenswertes zu schaffen.

Und 'Genie' heisst nicht "1.0 Streber", siehe Tobias Lütke ( 
https://www.spiegel.de/karriere/tobias-luetke-shopify-gruender-wird-vom-schlechten-schueler-zum-milliardaer-a-1180974.html 
) .

Ein Össi aus dem Muskelaufbaubusiness brachte die Grundeinstellung 
"Eigeninitiative"  auf folgende Punkte:
1
 #  Hab Selbstvertrauen                    - Trust Yourself.
2
 #  Spreng das Korsett aus Regeln          - Break The Rules.
3
 #  Keine Angst auf die Schnauze zu fallen - Don´t Be Afraid To Fail.
4
 #  Ignorier die Pessimisten               - Don´t Listen To The Nay-Sayers.
5
 #  Reiss Dir den Arsch auf                - Work Your Butt Off!
6
 #  zeige Dankbarkeit  den Unterstützern   - Give Back.



https://www.c64-wiki.de/wiki/Bil_Herd
https://de.wikipedia.org/wiki/Tobias_L%C3%BCtke

von J. S. (engineer) Benutzerseite


Lesenswert?

vancouver schrieb:
> aber wenn man die
> zusätzliche PCB-Fläche, den Speicher, das Interfacing an den FPGA, evtl
> zusätzliche Spannungsregler und nicht zuletzt die Abhängigkeit von einem
> weiteren Hersteller berücksichtigt, ist ein größerer FPGA unterm Strich
> billiger. Nicht immer, aber oft.
Absolut. Es gibt natürlichen immer einen Punkt, ab dem der externe Chip 
die bessere Lösung ist und dies aus den unterschiedlichsten Gründen. 
Solange der "CPU-Anteil" im Design klein genug, lohnt umgekehrt auch 
einfach Soft-Core. Man muss diese Grenzen eben kennen und immer mal neu 
ausloten.

vancouver schrieb:
> "Die Amerikaner und Chinesen sind uns da so weit voraus, das holen
> wir nie ein
Dem kann ich nicht folgen. Es geht bei der Ausbildung der Personen ja um 
deren Knowhow und nicht darum, wo die Chipfirma steht. Oft genug 
unterhalten amerikanische Firmen hier in Deutschland 
Entwicklungsabteilungen für komplette Geräte, für die auch ASICs 
entwickelt werden müssen, was meist inhouse passiert. Dafür braucht man 
auch Leute, die man dann irgendwo her einfliegen muss. Zudem machen 
manche Firmen gezielt in Europa eine solche Abteilung auf. Ein Kunde von 
mir hat jüngst in Polen eine Abteilung hochgezogen, weil es dort die 
passend ausgebildeten Leute gab. Wenn die deutschen Unis das nicht mehr 
anbieten, ist das fatal!

von J. S. (engineer) Benutzerseite


Lesenswert?

Mcn schrieb:
> Und die Geschichte hat gezeigt, das Einzelne 'Genies' reichen

Die Geschichte hat aber auch gezeigt, dass es unter 10 Mio Leuten, die 
ohne Ausbildung etwas probieren, maximal einer dabei ist, der so einen 
Erfolg hat, weil nur einer soviel Glück, Geschick hat. Egal was einer 
tut oder was andere tun: Es kann immer nur einer aus einer größeren 
Gruppe reich werden.

Es sind auch immer die kaufmännischen Bereiche, wo das geht - oft genug, 
indem man etwas verkauft, was keiner braucht, aber Hip genug ist, wie 
Klingeltöne oder Jeans. In den technischen Bereichen braucht es immer 
besonderes Wissen - oder jemanden in der Nähe der es hat. Im Übrigen hat 
Bill Gates ja sein erstes OS auch nicht geschrieben, sondern gekauft :-)

Und: Ohne viele gut ausgebildete Menschen im Land, die gutes Geld 
verdienen, steht gar keine Geldmenge zur Verfügung, um mit Luxus oder 
Shops reich werden zu können.

Im Übrigen geht es hier um ein ganz konkretes Thema der Technik und es 
soll  ja auch Leute geben, denen DAS Spass macht und nicht Shops zu 
betreiben.

von J. S. (engineer) Benutzerseite


Lesenswert?

Falk B. schrieb:
> Leider mußte ich in den
> letzten ~20 Jahren feststellen,
Inhalte und Qualität der Lehre haben sich stark verändert, wie mir 
scheint. Auch ich bekomme das mit. Den fertigen Studenten fehlt es an 
Fokus und gleichzeitig an Breite. Da wird meines Erachtens zu schnell zu 
viel gewollt und nicht mehr in die Grundlagen investiert. Es wird auf 
Tempo gemacht und die Studenten haben kaum noch Zeit, sich während des 
Studiums auch mal in die Breite zu entwickeln und Vorlesungen zu 
besuchen, die nicht im abgespeckten Lehrplan stehen, geschweige denn, 
sich noch privat mit Elektronik zu befassen.

"Wir" sind in einer Zeit groß geworden, wo man schon mit 10-12 mit 
Hobbyelektronik angefangen und gebastelt hat und später mit seinem 
Wissen den Physiklehrer in die Tasche stecken konnte, wenn er etwas zu 
Transistoren und LEDs erzählte. Wir sind an die Uni gekommen, wo viel 
Lehrstoff auf fruchtbaren Boden fiel. Heute müssen die Profs erst einmal 
den Acker bestellen und Saat ausbringen - und das bei weniger Zeit.

Du findest heute kaum noch Studenten mit diesem Vorwissen und einem 
ausgeprägten Engagement neben dem Studium. In den letzten 20 Jahren kann 
ich mich gerade an einen erinnern, der so richtig fit war, mit dem was 
er macht: Das war vor Kurzem bei meinem damaligen Kunden: Der werkelt 
privat mit Messtechnik und Hochfrequenztechnik und repariert sogar 
Analog-Oszilloskope - ist aber gerade erst mit dem Studium fertig 
geworden. Ich würde schätzen, dass der 90% seines Praxis- und 
Spezialwissens über die Jahre hinweg selber zusammengetragen hat.

Gleichwohl ist es nötig, im Studium die Grundlagen zu haben. Ich habe 
z.B. während des Studiums gearbeitet, aber nichts mit FPGAs zu tun 
gehabt. Auch direkt nach dem Studium ging es erst mit Hardware und 
Software los - z.T. sogar Windows. Erst 6 Jahre nach meinem letzten 
Projekt mit programmierbarer Logik in der Uni bin ich da vollzeitmäßig 
wieder drangegangen. Davor war nur nebenher gebastelt worden. Das wäre 
aber sicher nie passiert und geglückt, wenn ich nicht die ganze Palette 
Digitaltechnik aufgetischt bekommen hätte.

Wir hatten alles, von der Schrödingergleichung über 
Halbleitermaterialien, Herstellungsprozesse, Funktion von Halbleitern, 
dann die Schaltungen in ASICs und OPs, Transistoraufbau und -Funktion, 
Logik, dann weiter zu Mikroprozessoren und Treibern in Software, bis hin 
zum Unix und pipelines. Obendrauf kam dann die Nachrichtentechnik. Damit 
kann man praktisch an alles andocken, was es in der Industrie so gibt.

von Mcn (Gast)


Lesenswert?

Jürgen S. schrieb:
> Mcn schrieb:
>> Und die Geschichte hat gezeigt, das Einzelne 'Genies' reichen
>
> Die Geschichte hat aber auch gezeigt, dass es unter 10 Mio Leuten, die
> ohne Ausbildung etwas probieren, maximal einer dabei ist, der so einen
> Erfolg hat, weil nur einer soviel Glück, Geschick hat. Egal was einer
> tut oder was andere tun: Es kann immer nur einer aus einer größeren
> Gruppe reich werden.

Njein! Auf das Verhältnis 1:10 000 000 und für die (implizite) Ansage, 
das bis auf einen alle anderen arm bleiben.

Die nazahl der durch Eigeninitiative erfolgreichen Personen in der 
Informationstechnik könnte man (unter Ausklammerung der 
Konzernführungskrafte) mit der Zahl der Freiberufler im Ingenieurssektor 
gleichsetzen. Also etwa 200 000 für Deutschland. 
https://de.statista.com/statistik/daten/studie/158667/umfrage/freie-berufe-selbststaendige-2010/

Da passt dann eher eine Quote von 1:100 (ja, ich weiss Ingenieur ist so 
ziemlich das Gegenteil von Ungelernt).

Und über die Umverteilung der Einkommenssteuer partizipieren auch die 
unteren gehaltsgruppen, so dass die einzelnen genies tatsächlich den 
gesellschaftlichen Reichtun mehren.

Das die staatlich gewollte Abschaffung einer Einkommensschere der 
Wettbewerbsfähigkeit nicht zuträglich ist, hat die DDR-Wirtschaft 
bewiesen.
Da wurden die früheren Ingenieur-Wirtschaftslenker gnadenlos vertrieben:
( https://de.wikipedia.org/wiki/Martin_Mende ) oder politisch gegängelt 
(https://de.wikipedia.org/wiki/Werner_Hartmann_(Physiker)#1974%E2%80%931988:_die_Zeit_der_Repressionen 
).

Eine gewisse "Einkommensspreizung" ist nötig, will man nicht ein Volk 
von "gelernten Almosenempfängern" grossziehen. Das ist jedenfalls meine 
Meinung, "Arbeit/Leistung muß sich wieder lohnen".

von Falk B. (falk)


Lesenswert?

Mcn schrieb:
> Beispielsweise Linus Torvalds, der hat Linux 0.1 wegen Sex-Mangel allein
> in seine Studentenbude geschrieben

Code statt Koitus! Das ist doch mal ein Motto! ;-)

von Mcn (Gast)


Lesenswert?

Falk B. schrieb:

> Code statt Koitus! Das ist doch mal ein Motto! ;-)

Ja, der Linus, der sagte auch “Software ist wie Sex: Sie ist besser, 
wenn sie frei ist.”  ;-)

Und eben in seiner Autobiographie schreibt er:
1
"Das war mein Leben: Ich aß. Ich schlief. Vielleicht ging ich zur Uni. Ich programmierte. Ich las viele Emails. Mir war klar, dass meine Freunde mehr Sex hatten, aber das war okay. Offen gesagt, die meisten meiner Freunde waren auch Loser"
(Ehrlich, hinter dieser Schilderung könnt auch mein Klarname stehen ;-), 
beim Reset der Linus-Geschichte aber eher nicht :-( )

https://www.hna.de/netzwelt/multimedia/freak-statt-karrierist-zr-813563.html

Beitrag #7236243 wurde von einem Moderator gelöscht.
von Homo Färber (Gast)


Lesenswert?

Wühlhase schrieb:
> Da will jemand an einer
> Hochschule lehren und muß hier ernsthaft fragen, ob FPGAs noch Sinn
> haben. Hoffen wir mal, daß es nur ein Troll war, aber ich halte solche
> Dozenten leider tatsächlich für realistisch.
Wenn man sich anschaut, wieviel Wissen manche Dozenten über reale 
Strukturen in Firmen und Bedarfe der Industrie haben, darf man sich 
nicht wundern.

Vor Kurzem wurde ich auf eine duale Hochschule aufmerksam, wo ein 
29-jähriger Dozent mit 3 Jahren Berufserfahrung arbeitet. Zuvor hat er 
selber an der Dualen Hochschule gelernt, dann dort promoviert und seine 
3 Pflichtjahre bei einem spin off von Fraunhofer abgesessen.

Er gilt trotz fehlender Habilitation allein wegen des Dr.-Titels als 
lehrbefähigt und darf dort als Dozent arbeiten. Er wirbt sogar mit 
seinen Führungsqualitäten und das, obwohl man weis, dass er dort nur 
Jungspunte ohne viel Wissen um sich herum hatte und die alle genau so 
hemdsärmelig gearbeitet haben - von wegen "Projektleitung" und so.

Der hat nie in einer einzigen Firma richtig normal gearbeitet und kann 
einschätzen, wie ein Entwicklungsprozess läuft und wie in einem Team aus 
unterschiedlichen Disziplinen gearbeitet werden muss, weil er beim 
Fraunhofer nur mit seinesgleichen, also Leuten im gleichen Alter und vom 
gleichen Fach zusammen war. Diese Leitenden haben meistens Probleme mit 
Älteren und Erfahrenen und lassen sich nichts sagen - von wegen 
"Führung".

von Georg A. (georga)


Lesenswert?

Mcn schrieb:
> In Branchen wäre das:

Man sollte auch den Audio&Video-Bereich nicht vergessen. zB. Lawo, dhd, 
Riedel kennt zwar kaum einer, aber das Zeug ist bei jedem verbaut, der 
irgendwie Radio oder Fernsehen macht. Und da sind viele FPGAs begraben.

Aber es ist irgendwie lustig. So 1999 rum habe ich mich noch mit einem 
älteren Deppenprof (könnte Uni Dortmund oder Köln gewesen sein) 
rumgestritten, der der felsenfesten Meinung war, dass das mit FPGAs 
nichts wird und nur ASICs der Markt sind. Aber was soll man gegen 
Facharroganz schon ausrichten...

von Ralf (Gast)


Lesenswert?

Georg A. schrieb:
> (könnte Uni Dortmund oder Köln gewesen sein)
Tja, NRW, die Talentschmiede Deutschlands. Verwundern darf einen das 
nicht.

In Dortmund kennen sie scheinens nur das schwarze Zeug, dass sie aus den 
Gruben buddeln und haben eingesehen, dass man aus Kohlestaub keine Chips 
backen kann.

Bei Köln wundert mich gar nichts mehr. Die haben ausser Feiern und 
Karneval nix im Sinn. Bier können sie nicht, Fussball nur sehr begrenzt, 
Stadtarchive umbauen endet im Fiasko und erst im Jahr 2020 haben die 
gemerkt, dass man Halbleiter überhaupt programmierbar machen kann:
https://www.colognechip.com/

von Gerhard H. (ghf)


Angehängte Dateien:

Lesenswert?

Georg A. schrieb:

> Aber es ist irgendwie lustig. So 1999 rum habe ich mich noch mit einem
> älteren Deppenprof (könnte Uni Dortmund oder Köln gewesen sein)
> rumgestritten, der der felsenfesten Meinung war, dass das mit FPGAs
> nichts wird und nur ASICs der Markt sind. Aber was soll man gegen
> Facharroganz schon ausrichten...

Kennst Du den auch? Naja, andere Uni und kein Deppenprof.
Aber Tunnelblick auf Fujitsu ASICs und Telefunken B1000, was man
halt bisher als Standardlösung hatte.

Und er hat mir haarklein vorgerechnet, dass man garniemals nie
eine Fehlersimulation für einen FPGA-Chip auf einem PC-AT rechnen
könnte. Aaarghh, danke, das hat XILINX schon für mich getan und
der Chip ist getestet auf stuck-at-0 usw. Ich muss keine
Fehlersimulation machen bevor ich ein RAM beschreibe. Der Chip
ist FERTIG.

Ich habe damals sowas gebaut, die Platine hat einen ganzen
6HE-19"-Einschub ersetzt: Signal-Averager, der einen 200MHz-ADC
in Echtzeit wegrechnet. Ja, damals konnten wir noch Prüftechnik
an KKWs.

Schöne Winterzeit!

Gerhard

(Die DCF77-Uhr im Treppenhaus hat mich geweckt, sie hat 2 Minuten
gebraucht um ihre Zeiger zu ordnen, und das klang wie wenn irgendwo
Wasser läuft. Und das, wo ich heute einen Boiler tauschen musste.)

von Gerhard H. (ghf)


Lesenswert?

Ralf schrieb:
> Georg A. schrieb:

> Bei Köln wundert mich gar nichts mehr. Die haben ausser Feiern und
> Karneval nix im Sinn. Bier können sie nicht, Fussball nur sehr begrenzt,
> Stadtarchive umbauen endet im Fiasko und erst im Jahr 2020 haben die
> gemerkt, dass man Halbleiter überhaupt programmierbar machen kann:
> https://www.colognechip.com/

Ja, der Kölner gibt sich aber im Rahmen seiner Möglichkeiten
alle Mühe. Siehe Bier, Fußball oder Humor!

Gerhard

von Falk B. (falk)


Lesenswert?

Georg A. schrieb:
> Aber es ist irgendwie lustig. So 1999 rum habe ich mich noch mit einem
> älteren Deppenprof (könnte Uni Dortmund oder Köln gewesen sein)
> rumgestritten, der der felsenfesten Meinung war, dass das mit FPGAs
> nichts wird und nur ASICs der Markt sind.

Den selben Spruch gab's zur gleichen Zeit auch in de.sci.electronics von 
MaWin. Und heute immer noch. "Wird sich nicht durchsetzen", alles Mist.

> Aber was soll man gegen
> Facharroganz schon ausrichten...

Gar nix. Ignoranz ist ein Menschenrecht, bei allen Themen . . .

von Mcn (Gast)


Angehängte Dateien:

Lesenswert?

Falk B. schrieb:
> Georg A. schrieb:
>> Aber es ist irgendwie lustig. So 1999 rum habe ich mich noch mit einem
>> älteren Deppenprof (könnte Uni Dortmund oder Köln gewesen sein)
>> rumgestritten, der der felsenfesten Meinung war, dass das mit FPGAs
>> nichts wird und nur ASICs der Markt sind.
>
> Den selben Spruch gab's zur gleichen Zeit auch in de.sci.electronics von
> MaWin. Und heute immer noch. "Wird sich nicht durchsetzen", alles Mist.

2001 war ich mal bei mehreren ASIC-Fertigern (AMI, ZMD, X-FAB) die 
sofort einräumten, das deren Chips langsamer sind als die schnellen FPGA 
am Markt, weil die FPGA zu diesem Zeitpunkt auf Anlagen mitgeringerer 
Strukturbreite gefertigt worden als die ASICS. Also etwa 110 nm 
Spartan-2 und die ASIC-Buden lagen bei 200 nm. Und eben die enorm 
NRE-Kosten bei ASIC, da legste schon 1 Mio auf den Tisch während manfür 
ein Standard-FPGA Modul schon für 10k vom Ingenieurbüro ein 
minimaldesign bekommt. Und Mikrocontroller/DSP fehlte die Ansteuerlogik 
(Peripheralcontrol) die man grad brauchte und bit-banging ist zu 
langsam, also hat man einen PLD an den Bus genagelt und darüber die 
Periphery (Display, Festplatte, Audio-DAC) abgehandelt.

Heutzutage sieht es beim Preis ähnlich aus, ASIC sind bei 
kleinen/mittleren Stückzahlen zu teuer um die funktionalen Lücken zu 
schliessen, die mikrocontroller immer noch lassen. Deshalb formulierte 
der FPGA-Hersteller XILINX damals: "Make it your asic".

Das erklärt auch, warum Personen die Null Ahnung vom ASIC-Design haben, 
ASIC gegenüber FPGA preferieren - eben Dunning-Kruger Effekt: nie was 
Relevantes mit FPGA gemacht, aber voll überzeugt das der nichts taugt.

von Falk B. (falk)


Lesenswert?

Mcn schrieb:
> Heutzutage sieht es beim Preis ähnlich aus, ASIC sind bei
> kleinen/mittleren Stückzahlen zu teuer um die funktionalen Lücken zu
> schliessen, die mikrocontroller immer noch lassen. Deshalb formulierte
> der FPGA-Hersteller XILINX damals: "Make it your asic".

Ja logisch! Daran hat sich im Prinzip nix geändert, wenn gleich sich 
ggf. die Punkte verschoben haben, wo ein ASIC besser ist. Aber soweit 
ich das mitbekommen habe, haben sich eher die FPGAs ein größeres Stück 
vom Kuchen erkämpft als anders herum. Und es wird immer Anwendungen 
geben wo nur ein ASIC sinnvoll ist, ebenso wie ein FPGA! Stückzahl, NRE, 
Funktionalität, Geschwindigkeit, eine mehrdimensionale 
Optimierungsfunktion. FPGAs stehen auch nur begrenzt in Konkurrenz zu 
Mikrocontrollern oder DSPs. Denn was letztere direkt können, (SPI, I2S, 
Displays etc.), wird man ohne FPGA machen, logisch. Aber sobald die 
Standardschnittstellen nicht ohne Krampf oder Leistungsverlust bedient 
werden können, ist das FPGA am Zug. Und bei DEN Einstiegspreisen in die 
FPGA-Welt ein Genuss! Auch in 1000er Stückzahlen und darüber!

Ach ja, lang ist's her, war schön mit den FPGAs seufz

von Gerd (Gast)


Lesenswert?

Falk B. (falk)
>Aber sobald die
>Standardschnittstellen nicht ohne Krampf oder Leistungsverlust bedient
>werden können, ist das FPGA am Zug. Und bei DEN Einstiegspreisen in die
>FPGA-Welt ein Genuss! Auch in 1000er Stückzahlen und darüber!

Allerdings ist die Programmierung von FPGAs so viel umständlicher und 
braucht so viel mehr Zeit (ich nehme Faktor 5 als Richtwert) als die 
Programmierung von Mikrocontrollern, dass die meisten Firmen versuchen, 
alles ohne FPGAs zu machen.
Außerdem ist viel zu viel Know-How notwendig, welches in den meisten 
Firmen nicht vorhanden ist. Wie schon oben erwähnt wurde, ist es daher 
üblich, für die Entwicklungsaufgabe dann externe Dienstleister zu 
beauftragen.

BTW: wer einmal in Youtube nach FPGA Schulungsvideos sucht, wird 
vorwiegend auf indischen Kanälen fündig.

von Wühlhase (Gast)


Lesenswert?

Gerd schrieb:
> Außerdem ist viel zu viel Know-How notwendig, welches in den meisten
> Firmen nicht vorhanden ist. Wie schon oben erwähnt wurde, ist es daher
> üblich, für die Entwicklungsaufgabe dann externe Dienstleister zu
> beauftragen.

Dafür kann aber kein FPGA irgend etwas. Das liegt eher an Dozenten wie 
dem TS.

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


Lesenswert?

Gerd schrieb:
> Allerdings ist die Programmierung von FPGAs so viel umständlicher und
> braucht so viel mehr Zeit (ich nehme Faktor 5 als Richtwert) als die
> Programmierung von Mikrocontrollern
Immer ausgehend von ersten Schätzungen und ohne Betrachtung der 
Folgekosten. Denn nicht allzu selten gibt es bei solchen ausgereizten uC 
hinterher bei einer Softwareänderung an anderer Stelle seltsame 
Nebeneffekte, wo dann so ein Softwaredesign ungeplant die eingesparten 
4/5 locker aufholt.

> dass die meisten Firmen versuchen, alles ohne FPGAs zu machen.
Das übliche Henne-Ei-Problem. Sie versuchen es einfach deshalb nicht, 
weil sie keinen haben, der es macht.

Gerd schrieb:
> wer einmal in Youtube nach FPGA Schulungsvideos sucht, wird vorwiegend
> auf indischen Kanälen fündig.
Von dort schlagen dann hier im englischsprachigen Forum seltsame Fragen 
auf, wo ein offensichtlich blutiger Anfänger ohne Kenntnisse von 
Digitaltechnik irgendwelche High-End-Geschichten machen will bzw. soll.
Aber allein durch die Anzahl von Indern (immerhin mit den Chinesen 
gleichauf) gibt es natürlich auch einige Schlaue, die es draufhaben.

von Mcn (Gast)


Lesenswert?

Gerd schrieb:
> Falk B. (falk)
>>Aber sobald die
>>Standardschnittstellen nicht ohne Krampf oder Leistungsverlust bedient
>>werden können, ist das FPGA am Zug. Und bei DEN Einstiegspreisen in die
>>FPGA-Welt ein Genuss! Auch in 1000er Stückzahlen und darüber!
>
> Allerdings ist die Programmierung von FPGAs so viel umständlicher und
> braucht so viel mehr Zeit (ich nehme Faktor 5 als Richtwert) als die
> Programmierung von Mikrocontrollern, dass die meisten Firmen versuchen,
> alles ohne FPGAs zu machen.

Ja stimmt schon, die meisten Mikrocontrollerprogrammier sind zu 
blöd/bequem um einen FPGA effizient zu programmieren. Weil eben viele 
Mikrocontrollerprogrammierer nach dem Prinzip "Malen nach Zahlen" 
verfahren. Damit kann man auch als totale Kunstbanause Kunstwerke 
nachäffen. Was Eigenes kommt da nicht raus.

> BTW: wer einmal in Youtube nach FPGA Schulungsvideos sucht, wird
> vorwiegend auf indischen Kanälen fündig.

Eben, der Fehler ist es, nach Schulungsvideos Ausschau zu halten, statt 
die FPGA-Herstellerdok durchzuarbeiten. Oder die Tutorials der 
FPGA-Evalboardhersteller.
Video schauen und StepbyStep Anleitungen runterkloppen macht nicht 
schlau - höchstens als Selbsttäuschung.
Selbstständiges Arbeiten und Durchhaltewille bei Fruststrecken dagegen 
schon. Das schaffen auch 25 jährige Mädchen ohne Hochschulstudium:
https://youtu.be/nB3j911ldY0?t=569

von J. S. (engineer) Benutzerseite


Lesenswert?

Mcn schrieb:
> Njein! Auf das Verhältnis 1:10 000 000 und für die (implizite) Ansage,
> das bis auf einen alle anderen arm bleiben.
Zuviel geschlussfolgert. Dass einer unter 10 Mio zum Milliardär wird, 
heißt nicht, dass alle anderen arm sind :-) sondern nur, dass er aus der 
breiten Masse der vlt. 1000 Reichen herausragt, während diese wiederum 
aus den 1 Mio Wohhabenden herausragen.

PittyJ schrieb:
> Wir haben auf fast allen neueren Platinen ein FPGA drauf. Zusätzlich zum
> Linux oder STMH7. Die FPGAs werden benutzt um ein genaues Zeitverhalten
> von Steuersignalen zu erzeugen, das ein Prozessor niemals machen könnte.
Sehe ich auch so. Es gibt praktisch bei allen Elektroniken entsprechende 
Anforderungen an Geschwindigkeit. Digitales = FPGA braucht es fast 
überall. Die Frage ist, wie komplex das ist. Da gibt es schon sehr große 
Unterschiede

> Da reicht oft schon ein kleines FPGA von Lattice.
Ja die kleinen FPGAs von Lattice. Da fällt mir gerade was zu ein.

> und muss auch programmiert werden.
Ja, so klein der FPGA auch ist, er muss auch erstmal mit Inhalt gefüllt 
werden und wie ich jüngst wieder feststellen musste, wird der Aufwand 
dafür regelmäßig stark unterschätzt - besonders, wenn man 
Signalverarbeitung in sehr kleine resourcenbeschränkte FPGAs einbauen 
möchte und sich allerlei Tricks bedienen muss, was den 
Entwicklungsaufwand vergrößert.

Hier wäre ein solches Beispiel, das einst für meinen Synth entwickelt 
wurde und auch als Core in einem MAX10 eines Kunden läuft:
Beitrag "Effizienz von MATLAB und HLS bei VHDL"

Ohne ein präzises Verständnis für pipelining, data interleave und 
mehrdimensionales Prozessieren ist das nicht zu bauen. Vieles davon ist 
die Folge der Ausbildung - auch gerade bei den Grundlagen der 
Digitaltechnik. Ich sehe solche Grundschaltungen für die Handhabung von 
Daten und die Datenflüsse als absolut wichtig und nötig an.

Und das Ganze  drum herum kann man auch immer wieder einfließen lassen:
Die Daten, die mein Kunde mit den Filtern prozessiert, sind auch nicht 
irgendwelche Messdaten, sondern sie repräsentieren physikalische 
Effekte, für die ich ebenfalls Wissen aus dem Studium hatte und in die 
Parametrierung  der Filter habe einfließen lassen können.

von J. S. (engineer) Benutzerseite


Lesenswert?

Gerhard H. schrieb:
> Georg A. schrieb:
>> So 1999 rum habe ich mich noch mit einem
>> älteren Deppenprof (könnte Uni Dortmund oder Köln gewesen sein)
>> rumgestritten, der der felsenfesten Meinung war, dass das mit FPGAs
>> nichts wird und nur ASICs der Markt sind.
> Aber Tunnelblick auf Fujitsu ASICs und Telefunken B1000, was man
> halt bisher als Standardlösung hatte.
Schon seltsam was man so lesen muss! Ich kann nur für meine Uni und 
meine Profs sprechen und diesbezüglich waren die sehr fortschrittlich. 
Wir waren damals die einzige Uni, wo man außer in Berlin so vertieft 
Halbleiterelektronik studieren konnte und sogar Aachen und Darmstadt 
voraus.

Was FPGAs angeht, haben wir Anfang der 1990er im 3. Semester GALs 
programmiert und einen 3020 von Xilinx in einem Testboard. Der 
Laborbetreuer damals sagte klipp und klar "Das ist die Zukunft, GALs 
wird es bald keine mehr geben". Ich weis noch genau, wer es war und wie 
er hieß. Einige Jahre später war dann ein Lattice 1016 in meiner 
Diplomarbeit.

Offenbar macht es doch einen Unterschied, an welcher Uni man war. Einige 
Studenten scheinen da auf Irrwege geschickt zu werden.

P.S. Besagter Betreuer hat, wie ich gerade recherchiert habe, eine Firma 
in Siegen, die Elektronik entwickelt produziert.  Siehe da!

von Falk B. (falk)


Lesenswert?

Gerd schrieb:
> Falk B. (falk)
>>Aber sobald die
>>Standardschnittstellen nicht ohne Krampf oder Leistungsverlust bedient
>>werden können, ist das FPGA am Zug. Und bei DEN Einstiegspreisen in die
>>FPGA-Welt ein Genuss! Auch in 1000er Stückzahlen und darüber!
>
> Allerdings ist die Programmierung von FPGAs so viel umständlicher und
> braucht so viel mehr Zeit (ich nehme Faktor 5 als Richtwert) als die
> Programmierung von Mikrocontrollern, dass die meisten Firmen versuchen,
> alles ohne FPGAs zu machen.

Komletter Unfug! Nur weil ein paar Linux-Kids und andere Softies keine 
Ahnung und keinen Bock auf FPGAs haben.

> Außerdem ist viel zu viel Know-How notwendig, welches in den meisten
> Firmen nicht vorhanden ist.

Siehe oben!

> Wie schon oben erwähnt wurde, ist es daher
> üblich, für die Entwicklungsaufgabe dann externe Dienstleister zu
> beauftragen.

Kann man machen. Kann man aber auch selber machen.

> BTW: wer einmal in Youtube nach FPGA Schulungsvideos sucht, wird
> vorwiegend auf indischen Kanälen fündig.

So what! Stell dir vor, ich und tausende Andere haben vor über 20 Jahren 
ohne indische Youtube-Videos FPGAs nutzen und schätzen gelernt! Heute 
unvorstellbar! Und indische Youtube-Video, auch zu technischen Themen. 
Naja. Da nervt nicht nur der Akzent . . .

Außerdem ist Video das falsche Medium, um FPGAs zu lernen. Da sind 
Texte, Quelltexte und ähnliches DEUTLICH besser. Das hatten wir hier 
auch schon mehrfach diskutiert.

: Bearbeitet durch User
von Gerd (Gast)


Lesenswert?

Falk B. (falk)
>> BTW: wer einmal in Youtube nach FPGA Schulungsvideos sucht, wird
>> vorwiegend auf indischen Kanälen fündig.

>So what!

"So what" ganz einfach: Ich habe mir vor Corona erlaubt, bei einem der 
FPGA Dienstleister persönlich vorbei zu gehen und mich mit denen 
intensiv zu unterhalten und um mal die Lage ein wenig besser einschätzen 
zu können. Und siehe da: Nicht wenige Inder haben sich dort in den 
Räumen aufgehalten. Fazit: FPGA ist zu teuer und zeitintensiv und der 
Trend geht zu kostengünstigen Indern. Das dürfte auch der Grund für die 
vielen indischen Videos sein. Damit werden die Mitarbeiter der indischen 
Dienstleister von deren Hochschulen ausgebildet.

von Gerhard H. (ghf)


Angehängte Dateien:

Lesenswert?

Jürgen S. schrieb:
> Gerhard H. schrieb:
>> Georg A. schrieb:
>>> So 1999 rum habe ich mich noch mit einem
>>> älteren Deppenprof (könnte Uni Dortmund oder Köln gewesen sein)
>>> rumgestritten, der der felsenfesten Meinung war, dass das mit FPGAs
>>> nichts wird und nur ASICs der Markt sind.
>> Aber Tunnelblick auf Fujitsu ASICs und Telefunken B1000, was man
>> halt bisher als Standardlösung hatte.
> Schon seltsam was man so lesen muss! Ich kann nur für meine Uni und
> meine Profs sprechen und diesbezüglich waren die sehr fortschrittlich.
> Wir waren damals die einzige Uni, wo man außer in Berlin so vertieft
> Halbleiterelektronik studieren konnte und sogar Aachen und Darmstadt
> voraus.

Das war bei mir Berlin. Und ich habe oben geschrieben, dass unsere
Profs sicher keine Deppen waren. Wer bei IBM I2L erfunden hat, der fällt
da sicher nicht darunter, und der, von dem ich geschrieben habe auch
nicht. Und auch nicht der, bei dem wir zu 6st eine CPU in HP's dynamic
n-MOS Prozess machen durften.
Es war auch kein Problem, dass ich auf der dortigen VAX750 die CUPL-
Version von meinem FHG-Nebenjob einspielen durfte und dort ziemlich
viel CPU-Zeit verbraten habe.
Da habe ich u.a. gelernt, wie man große state machines in den Griff
bekommt. Da ist z.B. obiges FIR-Filter dabei rausgekommen.
Etwa 1984 nach den Datecodes der Chips.

> Offenbar macht es doch einen Unterschied, an welcher Uni man war. Einige
> Studenten scheinen da auf Irrwege geschickt zu werden.

Also, Berlin war sicher kein Irrweg. Zumindest nicht, was die TU betraf.
Und wenn da Designhouse-Ausgründungen in der Luft liegen, dann
wäre ich heutzutage flexibler. :-)

Gerhard

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

Gerd schrieb:
> "So what" ganz einfach: Ich habe mir vor Corona erlaubt, bei einem der
> FPGA Dienstleister persönlich vorbei zu gehen und mich mit denen
> intensiv zu unterhalten und um mal die Lage ein wenig besser einschätzen
> zu können. Und siehe da: Nicht wenige Inder haben sich dort in den
> Räumen aufgehalten. Fazit: FPGA ist zu teuer und zeitintensiv und der
> Trend geht zu kostengünstigen Indern. Das dürfte auch der Grund für die
> vielen indischen Videos sein. Damit werden die Mitarbeiter der indischen
> Dienstleister von deren Hochschulen ausgebildet.

Und du glaubst, mit dieser Erfahrung für den gesamten deutschen bzw. 
europäischen oder gar westlichen Raum sprechen zu können?

von Gerd (Gast)


Lesenswert?

Gerhard H. (ghf)
>Da habe ich u.a. gelernt, wie man große state machines in den Griff
>bekommt. Da ist z.B. obiges FIR-Filter dabei rausgekommen.

Offtopic, aber trotzdem interessiert es mich: Was ist der ADSP-1100 in 
der Mitte der Platine? Das Datenblatt finde ich bei Analog nicht. 
Vielleicht kannst du noch kurz ein paar Worte zum Design der Platine 
schreiben ...

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


Lesenswert?

Gerd schrieb:
> Ich habe mir vor Corona erlaubt, bei einem der FPGA Dienstleister
> persönlich vorbei zu gehen und mich mit denen intensiv zu unterhalten
> und um mal die Lage ein wenig besser einschätzen zu können. Und siehe
> da: Nicht wenige Inder haben sich dort in den Räumen aufgehalten.
In unserem Fall war es vor längerer Zeit ein Italiener, der ein Design 
ablieferte, an dem ich im Nachgang einiges lernte was man nicht machen 
sollte.

> Fazit: FPGA ist zu teuer und zeitintensiv
Entweder hast du ein Design, wo man ein FPGA sinnvoll und gewinnbringend 
einsetzen kann, oder du hast eines, wo ein üblicher µC sich auch schon 
zu Tode langweilt.

Wenn es aber so ist, dass du ein Design mit Ach und Krach auf dem µC A 
zum Laufen bekommen hast und der wird abgekündigt, dann kannst du nur 
hoffen, dass du einen Nachfolger µC B findest, auf den du das Design 
umgebogen bekommst.

Wenn du ein Design im FPGA hast, dann portierst du das einfach auf ein 
neues FPGA. Natürlich hast du da auch das Thema, dass das neue FPGA 
andere Peripherie (Taktmanager, Speicher, DSP, ...) hat. Aber im Grunde 
hast du kein Problem mit der Geschwindigkeit und schon gar nicht mit der 
Menge der Ressourcen.

Oder andersrum meine Erfahrung aus einigen Designs: die 
FPGA-Designportierungen verlaufen recht problemlos.
Bei der Einführung eines neuen µC zur Lösung von zeitkritischen Aufgaben 
zickt es eher und man braucht dann irgendwie immer einen Hardware- 
und einen Softwarespezialisten zum einkreisen und lösen des Problems.

> Nicht wenige Inder haben sich dort in den Räumen aufgehalten. ...
> und der Trend geht zu kostengünstigen Indern.
Die Inder, die sich hier in D in irgendwelchen Räumen aufhalten, sind 
nicht kostengünstig. Kostengünstig sind sie nur, wenn sie im 
Remote-Office in Indien sitzen. Und da sollte sich der 
FPGA-Dienstleister dann die Schlauen aus den 1,4 Milliarden aussuchen. 
Einfach nur einen Inder einstellen, der irgendwie einen Abschluss 
"hinbekommen" hat? Aus eigener Erfahrung: Nein danke. Denn auch da gilt 
wie üblich: "Am schlechten Ingenieur erkennt man den Wert des Guten."

Gerd schrieb:
> Was ist der ADSP-1100 in der Mitte der Platine?
Ein Abtippfehler. Aber der ADSP1110 ist ein 16x16 MAC.

> Das Datenblatt finde ich bei Analog nicht.
1984 gab es noch kein Internet. Aber irgendwer hat da was eingescannt:
* 
https://www.findchips.com/parametric/Microcontrollers%20and%20Processors/DSP%20Peripherals?Manufacturer%20Part%20Number=adsp1110
* 
ttps://4donline.ihs.com/images/VipMasterIC/IC/ANDI/ANDIS12831/ANDIS12831 
-1.pdf?hkey=EF798316E3902B6ED9A73243A3159BB0
* 
https://4donline.ihs.com/images/VipMasterIC/IC/ANDI/ANDID021/ANDID021-3-367.pdf?hkey=EF798316E3902B6ED9A73243A3159BB0

: Bearbeitet durch Moderator
von Gerhard H. (ghf)


Lesenswert?

Auf der linken Seite ist der SMP-Bus von Siemens, meist 8080,
85 oder 86. Einen Z80 dafür zu modden war aber leicht.
In den Rams waren die Filterkoeffizienten und auch der zu
filternde Datenblock, WIMRE.

Der Filteralgorithmus wurde in Turbo-Pascal (oder MT+??)
geschrieben und erst mal debuggt. Dann wurde das Programm
in Schritte zerteilt, so dass zu jedem Zeitpunkt nur je
1 Daten- und 1 Addresstransfer stattfand.

Dann bekamen die Schritte Zustandsnummern und die Bedingungen
für die Zustandsänderungen wurden in CUPL eingegeben und auch
die Aktivitäten in den Zuständen. Das war nur viel Arbeit,
aber übersichtlich und nicht schwer. CUPL konnte das dann
simulieren, optimieren und dann auf die einzelnen PALs aufteilen.

Die Hardware hat auf Anhieb funktioniert, von einem WireWrap-
fehler abgesehen.

Gruß, Gerhard

von Falk B. (falk)


Lesenswert?

vancouver schrieb:
>> und ABM für ihre Belegschaft . . .
>
> Oh, Uni-Bashing. Daher weht der Wind.

https://www.merkur.de/deutschland/hamburg/zwei-millionen-euro-fuer-forschung-zur-pronomenverwendung-zr-91845518.html

"Eine neue Forschungsgruppe unter Leitung der Universität Hamburg erhält 
zwei Millionen Euro für die Erforschung von Pronomen. „Wir, Sie, du, es: 
Jede und jeder von uns benutzt täglich Pronomen, doch wann werden sie 
wie verwendet? Das will ein Team aus Wissenschaftlerinnen und 
Wissenschaftlern herausfinden“, teilte die Universität am Mittwoch mit. 
Dafür erhalte die Forschungsgruppe unter Leitung von Wolfgang Imo, 
Professor am Institut für Germanistik der Universität Hamburg, über vier 
Jahre rund zwei Millionen Euro von der Deutschen 
Forschungsgemeinschaft."

Jaja, das sind "Geistes"wissenschaftler, keine 
Ingenieurswissenschaftler, aber auch bei denen gibt's genügend Flausen 
und heiße Luft.

;-)

von Mcn (Gast)


Lesenswert?

Falk B. schrieb:
> vancouver schrieb:
>>> und ABM für ihre Belegschaft . . .
>>
>> Oh, Uni-Bashing. Daher weht der Wind.

>  keine
> Ingenieurswissenschaftler, aber auch bei denen gibt's genügend Flausen
> und heiße Luft.

Und für die Skurrilsten gibt es den Ig-Nobelpreis: ;-)

https://www.br.de/nachrichten/wissen/ig-nobelpreis-2022-surfende-enten-und-skorpione-mit-verstopfung,THaGYa3

https://www.geo.de/wissen/ig-nobelpreise-2021--die-gewinner-30729422.html

https://www.der-niedergelassene-arzt.de/kaffeepause/news-details/kaffeepause/ig-nobelpreis-2020-helium-alligator-kaugeraeusche-kot-messer-und-andere-kuriose-forschungsthemen

Und dann war da noch eine Dissertation zur Selbstverstümmelung an 
Vorwerk-Staubsaugern ;-) 
(https://de.wikipedia.org/w/index.php?title=Staubsaugersex)

von Georg A. (georga)


Lesenswert?

Falk B. schrieb:
> Jaja, das sind "Geistes"wissenschaftler, keine
> Ingenieurswissenschaftler, aber auch bei denen gibt's genügend Flausen
> und heiße Luft.
>
> ;-)

Sei doch froh, dass die damit einen bezahlten Unijob haben und nicht 
Taxifahren müssen. Das wäre wirklich gefährlich und effektiv für uns 
alle teurer, von daher finanziell und aus Sicht der Risikoprävention 
alles richtig gemacht.

von Geschockter (Gast)


Lesenswert?

Falk B. schrieb:
> "Eine neue Forschungsgruppe unter Leitung der Universität Hamburg erhält
> zwei Millionen Euro für die Erforschung von Pronomen.

Ich hatte erst "Protonen" verstanden!!!!

Unfassbar, wofür wir Geld ausgeben. Derweil rennen uns Chinesen und 
Inder davon und übernehmen nach und nach alles an Industrie womit wir 
unser Land aufgebaut haben.

Schon sehr bald ist kein Geld mehr da, um es mit vollen Händen 
auszugeben.
Der Staat macht munter Schulden, die dann die U40 alle mal abzahlen 
müssen. In erster Linie dadurch dass sie keine Rente bekommen!

von Mcn (Gast)


Lesenswert?

Geschockter schrieb:

> Der Staat macht munter Schulden, die dann die U40 alle mal abzahlen
> müssen. In erster Linie dadurch dass sie keine Rente bekommen!

Jajaja, ganz schlimm, ohne Rente wird man ja selber arbeiten müssen und 
vorsorgen. Aber: https://youtu.be/ESc6TQ8BVaU?t=17

von Falk B. (falk)


Lesenswert?

Geschockter schrieb:
> Schon sehr bald ist kein Geld mehr da, um es mit vollen Händen
> auszugeben.

Na hoffentlich! Dann hat der Spuk ein Ende!

> Der Staat macht munter Schulden, die dann die U40 alle mal abzahlen
> müssen. In erster Linie dadurch dass sie keine Rente bekommen!

Kaum. Die massiven Staatsschulden werden durch Inflation und irgendwann 
durch eine "Währungsreform" "abbezahlt". Bis es soweit ist, fließen 
Unmengen an Zinsen in die Taschen von Wenigen . . .
Ich garantiere dir, daß auch DU das in deiner Lebenszeit live erleben 
wirst!

von Falk B. (falk)


Lesenswert?

Georg A. schrieb:
> Sei doch froh, dass die damit einen bezahlten Unijob haben und nicht
> Taxifahren müssen. Das wäre wirklich gefährlich und effektiv für uns
> alle teurer, von daher finanziell und aus Sicht der Risikoprävention
> alles richtig gemacht.

Na dann sollten wir die Risikoprävention auch auf den Bundestag 
ausweiten und alle Mitglieder freistellen. Dann können sie Golf spielen, 
Kekse backen oder sich irgendwo festkleben. Es KANN nur besser werden!

P S Warst du nicht mal an der Uni als Mitarbeiter? Oder bist du es sogar 
noch? Könnte es da eine kognitive Dissonanz bei dir geben? ;-)

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


Lesenswert?

Hat der Thread jetzt die maximale Entropie erreicht und endet somit in 
der Politik? Kann der also zu?

von Gerd (Gast)


Lesenswert?

>Hat der Thread jetzt die maximale Entropie erreicht und endet somit in
>der Politik? Kann der also zu?

Für das Thema "FPGAs in der Lehre" fehlt noch folgendes:

Wie viele Stunden sollten in der Universtät/Hochschule dafür spendiert 
werden? Ist es wichtiger als die Vorlesungen zum Thema AI/Machine 
Learning & Cloud Computing.

Sollte es ein Praktikum geben? (Hochschule/Universität)

Und zu guter letzt fehlt ein praktische FPGA-Beispiel für ein Praktikum, 
das mehr kann als ein Mikrocontroller (oben gab's ja das Beispiels eines 
Fahrradcomputers, das geht aber mit einer Arduino besser und dann mit 
GPS).

von Falk B. (falk)


Lesenswert?

Gerd schrieb:
>>Hat der Thread jetzt die maximale Entropie erreicht und endet somit in
>>der Politik? Kann der also zu?
>
> Für das Thema "FPGAs in der Lehre" fehlt noch folgendes:
>
> Wie viele Stunden sollten in der Universtät/Hochschule dafür spendiert
> werden?

Das sollte Teil der Grundlagen zum Thema Digitaltechnik sein. Aber bitte 
NACHDEM die ELEMENTAREN Grundlagen wie FlipFlips, State Machine etc. 
behandelt wurde.
Wie hatten damals (1999) ABEL und den guten, alten GAL 22V10 im 
Praktikum, ist für den EINSTIEG auch ausreichend. Soooo viel Zeit für 
Tiefe hat man bei der Vorlesung am Ende auch nicht. Heute sollte man 
natürlich VHDL und einen kleinen CPLD, vielleicht auch einen kleinen 
FPGA nehmen.

> Ist es wichtiger als die Vorlesungen zum Thema AI/Machine
> Learning & Cloud Computing.

Nein.

> Sollte es ein Praktikum geben? (Hochschule/Universität)

Siehe oben.

> Und zu guter letzt fehlt ein praktische FPGA-Beispiel für ein Praktikum,
> das mehr kann als ein Mikrocontroller

Da muss es was sein, das ANSATZWEISE sie Vorteile des FPGAs ausnutzt, 
z.B. schnelle Schieberegister, BRAMs und einfache Datenvorverarbeitung. 
Ein Video-CODEC ist an der Stelle "leichter" Overkill und überfordert 
die Studenten in dem Moment.

> (oben gab's ja das Beispiels eines
> Fahrradcomputers, das geht aber mit einer Arduino besser und dann mit
> GPS).

Naja, bei solchen Projekte geht es nicht um die Killerapplikation, 
sondern um des Verstehen und Anwenden der Konzepte. Da kann man auch ein 
olle Ampelsteuerung in ein FPGA gießen. Wenn das die Leute mit einer 
sauberen FSM machen, ist das Lernziel für's Erste erreicht. So viel mehr 
haben wie mit den 22V10 auch nicht gemacht, was will man aus 10 
Makrozellen auch rausquetschen?

von Mcn (Gast)


Lesenswert?

Die Frage ist doch, in welches Fach passt das Thema "FPGA"?

Natürlich in das Fach, in dem die Grundlagen für die FPGA-Entwicklung 
gelehrt werden. Und in welcher Disziplin werden die Grundlagen für das 
Design mit "Gate-Arrays" gelegt? - Ganz Klar in der 
Elektrotechnik/Infomationstechnik/IC-Entwurf!

Genaugenommen benötigt auch Embedded Computing wie eben der Einsatz von 
Mikrocontroller einen gehörigen Anteil an Elektronik-Grundlagen. Deshalb 
ist es etwas befremdlich, das sich die Informatik als reiner 
Algorithmenumsetzer auf das Thema "Mikrocontroller" stürzt ohne in deren 
"Lehre" wenigstens in den Nebenfächern auf die Grundlagen der 
Schaltungstechnik/Peripherieigenschaften gründlich einzugehen.
Mit so einer selbstgefälligen Auslegung des Lehrauftrages und Ignoranz 
der Basis derIngenieurswissenschaften (Spass am Technik, "Technik 
anfassen") muß man ja auf die Schnauze fallen.

Nicht jeder ET-Absolvent wird in seinem Berufsleben mit 
FPGA's/(AS-)IC-Design und Computerarchitektur konfrontiert, vielleicht 
1%. Aber die, die es werden, müßen sich die Grundlagen dafür erarbeiten. 
Und für diese Grundlagen genügt es nicht mit Mikrocontrollern und ihren 
vorgekauten Entwicklungsumgebungen "rumzuspielen".

von Georg A. (georga)


Lesenswert?

Falk B. schrieb:
> Georg A. schrieb:
>> Sei doch froh, dass die damit einen bezahlten Unijob haben und nicht
>> Taxifahren müssen. Das wäre wirklich gefährlich und effektiv für uns
>> alle teurer, von daher finanziell und aus Sicht der Risikoprävention
>> alles richtig gemacht.
>
> Na dann sollten wir die Risikoprävention auch auf den Bundestag
> ausweiten und alle Mitglieder freistellen. Dann können sie Golf spielen,
> Kekse backen oder sich irgendwo festkleben. Es KANN nur besser werden!
>
> P S Warst du nicht mal an der Uni als Mitarbeiter? Oder bist du es sogar
> noch? Könnte es da eine kognitive Dissonanz bei dir geben? ;-)

Ja, war ich. Aber Informatik und nicht Germanistik. Aber das 
Bullshit-Bingo, um Fördergelder einzutreiben, war nicht anders oder 
inhaltlich solider, nur halt kein Aufreger für bestimmte Kreise wie 
Genderkram (beim MM ist es schon klar, wer die Zielgruppe der Meldung 
ist...). Feste Stellen am Lehrstuhl gabs nur ein paar, die anderen 15 
oder so kamen aus Förderprojekten. Ohne die Förderprojekte gäbs halt 
weder Forschung noch Studentenbetreuung noch richtige Klausurkorrektur, 
und das wird in jedem Fach so sein.

Und ich habe (um wieder zum Threadstart zurückzukommen) eine Menge 
FPGA-Projekte mit den Studenten gemacht. Und zwar genau solche, die mit 
kleinen CPUs quasi nicht machbar sind, um den Unterschied zu SW 
darzustellen. zB. Oszi mit VGA-Ausgang (natürlich ohne 
Bildschirmspeicher), Audio-Spektrumanalyzer, Videospiele, etc. alles nur 
aus einem Spartan2 raus (und von einer 3er Studigruppe aus 
Zweitsemestern bearbeitet). In einem späteren Praktikum gabs noch 
SOC-Entwicklung mit Microblaze+uCLinux, DMA (für echte Videoausgabe), 
etc.  Also alles "Real-World"-Dinge, die man nur mit FPGA hinbekommt und 
nicht so Le[eh]rkram wie eine öde Ampelsteuerung oder so.

Und wie gesagt, alles Informatikstudenten, nicht E-Technik. Ich glaube 
schon, dass das durchaus zum besseren Verständnis der Unterschiede HW/SW 
beigetragen hat und auch, wo man den "Sweetspot" bei einer einer 
Kombination aus SW+HW setzt.

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


Lesenswert?

Gerd schrieb:
> Und zu guter letzt fehlt ein praktische FPGA-Beispiel für ein Praktikum,
> das mehr kann als ein Mikrocontroller
Warum muss da ein Beispiel "mehr können"? Ein Grundschüler muss nach 
seinen ersten Übungen ja auch nicht "mehr können" als ein 
Taschenrechner.

Alle Praktikanten, die ich hatte, waren froh, wenn sie selbst kapiert 
haben, wie man so ein Blockschaltbild einer Komponente im µC in VHDL 
abbildet, sodass hinterher ein Modul wie z.B. eine serielle Schnitte 
oder eine VGA-Ansteuerung rauskommt. Und mit solchen selbst nachgebauten 
Modulen von Hand eine Kamera eingelesen und am Bildschirm wieder 
ausgegeben wird.

Aber es lernt keiner was, wenn er anhand einer 
Schritt-für-Schritt-Anleitung einen Megamonsterfilter mit Matlab 
modelliert, dann aufs FPGA spielt und in Echtzeit ein Kamerabild 
manipulieren und mit einem HDMI-Monitor darstellen kann. Hinterher hat 
der, der dieses Praktikum gemacht hat, nämlich immer noch keine Ahnung, 
was er da eigentlich gemacht hat oder gar, was er machen muss, wenn die 
Toolchain mal einen winzigen Fehler ausgibt.
Man kann also bestenfalls zum Schluss so eines Praktikums noch zeigen, 
was mit so einen FPGA darüber hinaus auch möglich ist.

Grundsätzlich muss auch nicht jeder Student so eine VHDL-Ausbildung 
durchlaufen. Denn wenn einer von von herein weiß, dass er später nie un 
nimmer was damit zu tun haben will, dann ist das für den eine Qual.

> oben gab's ja das Beispiels eines Fahrradcomputers, das geht aber mit
> einer Arduino besser
So wie die Berechnung von 72345/812 per Taschenrechner auch besser geht, 
es aber trotzdem sinnvoll ist, zu lernen, wie so eine Division 
grundlegend funktioniert.

von Klausi (Gast)


Lesenswert?

Mcn schrieb:
> in welcher Disziplin werden die Grundlagen für das
> Design mit "Gate-Arrays" gelegt? - Ganz Klar in der
> Elektrotechnik/Infomationstechnik/IC-Entwurf!

Kleine Korrektur: "IC-Entwurf" sehe ich paralle zum FPGA und von dem 
Erscheinen in der Vorlesung auch später, da es spezifischer ist. 
IC-Design ist ja auch wieder mehr Elektronik, Analogtechnik und 
konkreter als allgemeine Schaltungstechnik.

FPGAs sind aber nichts anderes als der Ersatz der Logikschaltungen, wie 
man sie seit den 1970ern kennt. Das braucht jeder, der Elektronik machen 
will.

Ich glaube, ein Problem bei der Zuordnung ist das veränderte Bild des 
Elektroingenieurs: Das ist heute viel softwarelastiger und vieles mit 
Controllern, Automation, MachineLearning hat mit "Elektro" nicht viel zu 
tun, sondern eher mit "Informatik".

Eigentlich müsste man die Studiengänge stärker differenzieren und 
sicherstellen, dass

die, die den Informatik-orientierten Zweig machen, mehr übergeordnete 
Dinge lernen, wie KI, Automatismen, Regeltechnik, embedded C und bei 
FPGAs die Softwarecores und die Echtzeitsachen

und die, die mehr Elektronik machen, sich mehr um die Technik kümmern, 
also die Elektron, Schaltungen, Analog, Signalintegrity, EMV, 
Hochfrequenzeffekte, Layouting, und eben auch die harten Themen FPGA + 
ASIC Bau.

> Genaugenommen benötigt auch Embedded Computing wie eben der Einsatz von
> Mikrocontroller einen gehörigen Anteil an Elektronik-Grundlagen.
Ja und nein, denn alles was Soft ist, ist ja entkoppelt von der 
HWardware. Nur wenn du eine komplette HW bauen willst, ist das wichtig.

> ist es etwas befremdlich, das sich die Informatik als reiner
> Algorithmenumsetzer auf das Thema "Mikrocontroller" stürzt ohne in deren
> "Lehre" wenigstens in den Nebenfächern auf die Grundlagen der
> Schaltungstechnik/Peripherieigenschaften gründlich einzugehen.
Es nützt niemandem, wenn die da Halbwissen haben. Damit können sie 
nichts anfangen.


> Nicht jeder ET-Absolvent wird in seinem Berufsleben mit
> FPGA's/(AS-)IC-Design und Computerarchitektur konfrontiert, vielleicht
> 1%. Aber die, die es werden, müßen sich die Grundlagen

Jeder, der wirklich Elektronik baut, kommt in jedem Fall mit digitalen 
Schaltungen zusammen, es sei denn, es ist sowas wie Zahnbürsten und auch 
die haben ja schon Controller drin.

FPGAs brauchen 90% der Elektroniker. ASIC nur 5%. Man muss nur deren 
SPEC lesen und verstehen, um sie wie jeden anderen Chip zu platzieren.

von Klausi (Gast)


Lesenswert?

Falk B. schrieb:
> Wie hatten damals (1999) ABEL und den guten, alten GAL 22V10

Ich rate mal, Du bist Ü50, hast noch 10 Jahre bis zur Rente und machst 
schon lange nichts mehr mit PCBs oder Layout und hast dich auch in die 
Software reinentwickelt, wie viele andere, programmierst UC und FPGA als 
Ersatz für weggefallene Aufgaben von vor 20 Jahren?

Lothar M. schrieb:
> Aber es lernt keiner was, wenn er anhand einer
> Schritt-für-Schritt-Anleitung einen Megamonsterfilter mit Matlab
> modelliert, dann aufs FPGA spielt und in Echtzeit ein Kamerabild
> manipulieren und mit einem HDMI-Monitor darstellen kann. Hinterher hat
> der, der dieses Praktikum gemacht hat, nämlich immer noch keine Ahnung,

Ich rate noch mal, Du bist auch Ü50, hast auch noch 10 Jahre bis zur 
Rente und machst auch schon lange nichts mehr mit PCBs oder Layouts und 
hast dich ebenfalls in die Software reinentwickelt. Das 
FPGA-Programmieren hast du dir selber beigebracht, weil FPGA-Schaltungen 
wie vor 20 Jahren, heute keiner mehr braucht.

Mit Deiner Aussage hast du insoweit Recht, als dass der Praktikant auf 
diese Weise nichts von der Elektronik, den Eigenheiten des FPGA und den 
Signalgüten lernt. Er hat aber eventuell etwas über 
Bildverarbeitungsfilter gelernt. Das wäre dann auch das Ziel der Übung.

Da muss eben unterschieden werden, ob ich jemandem die 
Signalverarbeitung beibringen will und die benutzte Hardeware (kann auch 
GPU sein) nur das Vehikel ist, oder ob er Elektronik lernen soll um 
solche Vehikel zu bauen.

Die Frage die sich für jeden Studenten stellt: Wo gibt es mehr 
Konkurrenz? und wo gibt es mehr zu lernen.

von Mcn (Gast)


Lesenswert?

Klausi schrieb:
> Mcn schrieb:
>> in welcher Disziplin werden die Grundlagen für das
>> Design mit "Gate-Arrays" gelegt? - Ganz Klar in der
>> Elektrotechnik/Infomationstechnik/IC-Entwurf!
>
> Kleine Korrektur: "IC-Entwurf" sehe ich paralle zum FPGA und von dem
> Erscheinen in der Vorlesung auch später, da es spezifischer ist.
> IC-Design ist ja auch wieder mehr Elektronik, Analogtechnik und
> konkreter als allgemeine Schaltungstechnik.

Dann siehstedas anders als ich. OK, wahrscheinlich verwechselst du hier 
IC-Entwurf mit IC-Fertigung und man hätte besser den alten Begriff 
"VLSI-Prozessorentwurf" verwenden sollen:
https://tu-dresden.de/ing/elektrotechnik/iee/hpsn/studium/materialien/prozessorentwurf-vorlesung

wobei lezteres schon eine sehr moderne Fassung ist, die "Handwerkliche" 
Grundlagen der EDA-Software überlässt.  Dann schon eher 
ISBN:9780131760592 das auch den von Studenten ungeliebten Urschleim wie 
Karnough oder Speicher-Zoologie von SRAM/ROM über DualPortRAM und Fifo 
zum Assoziativspeicher (CIM) nicht unter den Tisch fallen lässt.

Bei der Auflistung oben, ging es mir auch weniger um einzelne Fächer 
sondern Studiengänge. Und ja, ich bin schon der meinung man muss einen 
Studiengang besuchen der Hardware-Entwicklung in den Fokus stellt um 
sinnvoll mit FPGA's arbeiten, ein Informatik-Abschluß ist da ungenügend 
und erfordert Nachschulung. Die kann eben auch in der Freizeit gelingen, 
aber sicher nicht bei dem hobbymäßigen Beschäftigung mit 
MikrocontrollerEvalboards.

von Falk B. (falk)


Lesenswert?

Klausi schrieb:
> Falk B. schrieb:
>> Wie hatten damals (1999) ABEL und den guten, alten GAL 22V10
>
> Ich rate mal, Du bist Ü50, hast noch 10 Jahre bis zur Rente und machst
> schon lange nichts mehr mit PCBs oder Layout und hast dich auch in die
> Software reinentwickelt, wie viele andere, programmierst UC und FPGA als
> Ersatz für weggefallene Aufgaben von vor 20 Jahren?

Du liegst meilenweit daneben. Wenn man mal grob rechnen könnte, würde 
dir die Jahreszahl 1999 (als ich noch Student war) und das aktuelle Jahr 
2022 etwas anderes sagen. Und wenn du den ein oder anderen Beitrag von 
mir in den letzten Monaten oder gar Jahren gelesen hättest, wüßtest du 
auch, was ich ungefähr mache.

Ü40 und Hardwareentwickler, ein echter ;-)
Eagle hab ich oft laufen, wenn gleich nicht jeden Tag oder jede Woche.
Software mach ich wenig, nur bissel Low Level Kram mit AVRs und anderen 
KlimBim.
FPGA hab ich direkt nach dem Studium ca. 3 Jahren recht intensiv 
gemacht, dann noch mal kurz, dann offiziell gar nicht mehr 8-0, nur noch 
das eine, oder andere Hobbyprojekt.

> Die Frage die sich für jeden Studenten stellt: Wo gibt es mehr
> Konkurrenz? und wo gibt es mehr zu lernen.

Die Masse der Leute will keine Low Level Sachen machen, das werden immer 
weniger. Aber auch die Wenigen braucht man noch. Einfach mit der GUI was 
zusammenclicken reicht oft, aber nicht immer. Außerdem gibt auch 
Projekte, die WIRKLICH die volle Hardwareleistung brauchen, dann braucht 
es ECHTE Hardware-Könner und keine mittelharten Softwerker.

von Mcn (Gast)


Lesenswert?

Klausi schrieb:

> Die Frage die sich für jeden Studenten stellt: Wo gibt es mehr
> Konkurrenz? und wo gibt es mehr zu lernen.

Ich sag mal, am meisten gibt es in der Praxis zu lernen! Also brecht das 
Studium ab und rein in die Praxis ;-) ... nee eher nicht. Praxis kann 
man auch neben den Studium haben: Werksstudent oder einfach privat in 
das Thema reinknien (wenn man das nicht bereits vorher gemacht hat und 
eben studiert um seinem Interesse auch den fachlichen Schliff zu geben).

Und das mit der Konkurrenz kann man auch unterschiedlich bewerten: "Viel 
feind viel Ehr" sagt man auch - also wählt man das Fach mit den meisten 
Mitbewerbern, weil gerade der Wettbewerb anspornt. Im Gegensatz dazu das 
Fach wo man auf jeden Fall genommen wird, weil es keine anderen Bewerber 
gibt  Klingt jetzt nicht so prall, ein Job, wo man der Einzige ist, der 
diesen anstrebt.

Oder ist der numerus clausus gemeint? Also ich geh davon aus, das einen 
solchen nicht flächendeckend für die Ingenieursfächer gibt. Aber da kann 
ich mich irren, könnt ja sein, das inzwischen Hinz und Kunz sich zum 
Ingenieur berufen fühlt. Auch wenn der Notenschnitt es überhaupt nicht 
her gibt.
https://www.ingenieurwesen-studieren.de/studienwahl/numerus-clausus-nc/#informatik

von Joey5337 (Gast)


Lesenswert?

Ich frag mal andersrum:
Was wären denn die konkreten Lernziele?

Vorab zu mir: ich bin aus dem Thema komplett raus - Ich habe vor 20+ 
Jahren an der Uni dieses "VHDL-Praktikum" mit dem Fahrradcomputer 
gemacht. Im Jahr drauf hab ich mir das nochmal angeschaut, ein besseres 
Test-Tool gebastelt und einigen Studis geholfen, die damit Probleme 
hatten.
Obwohl ich das superspannend fand hat es sich bis jetzt weder beruflich 
noch privat ergeben, dass ich das gebraucht hätte.

Bei den Studis, denen ich geholfen habe, war das größte Problem, das 
Mindset auf Hardware umzustellen. Also dass eine Zuweisung nicht einer 
Variable einen Wert zuweist, sondern ein Kabel legt. Dann erklärt sich 
auch, warum das nur einmal geht. Und dass ein process nicht "ausgeführt" 
wird, wenn sich eines der Signale in der sensitivity-list ändert. Obwohl 
das im Code aussieht wie eine Pascal-Function mit aufeinander folgenden 
Anweisungen.

So langweilig sich der Fahrradcomputer anhört, da sind schon einige 
Erkenntnisse drin (die den VHDL-Profis vermutlich selbstverständlich 
erscheinen):
* Wie komme ich von einem Real-World-Problem mit möglichst wenig 
Rechenschritten in Ganzzahlen zum Ziel? Wie groß muss der einzige 
Skalierungsfaktor sein? (Im uC macht das der Compiler für mich)
* Wie groß sind meine Werte?
* Hardware nach Maß: In VHDL bekomme ich den 28bit-Zähler und kann die 
unteren 3 Bits ohne Mehrkosten verwerfen.
* Unterschied zwischen Bitvektor und Zahl, Zahlendarstellung
* Wie gieße ich einen Algorithmus (schriftliche Division) mit 
Schieberegistern in Hardware?
* Implementierung von Zustandsmaschinen, ggf. mehrere (für Zeitmessung, 
Division, Anzeige)
* Wenn man intern einen Bus gebaut hat: Buszugriff/Tristates
* Tricks, um die zweistellige Dezimalanzeige ohne zusätzliche echte 
Division hinzubekommen

Wie gesagt, ich habe keine Ahnung von aktuellem VHDL und denke, das sind 
alles grundlegendste Basics. Die Division hätte man damals schon aus 
einer Bibliothek nehmen können, das war nur zu Übungszwecken drin. 
Andererseits war das Praktikum für VHDL-Anfänger, eine 
Digitaltechnik-Vorlesung aber Voraussetzung.

Sicher gibt es Übungsaufgaben die sexyer sind, wo man die 
FPGA-Killerfeatures Parallelität und Geschwindigkeit besser 
demonstrieren kann.

Grundfrage aber ist: Was genau sollen die Studis lernen?

von Georg A. (georga)


Lesenswert?

Joey5337 schrieb:
> Grundfrage aber ist: Was genau sollen die Studis lernen?

Erweiterung des meistens doch sehr begrenzten Horizonts. Und da ist 
VHDL/FPGA sogar noch realitätsnäher als ein Prolog-Praktikum. Wer gut 
ist, nimmt zumindest mit, wo er später mal genau nachlesen kann, wenn er 
es braucht *)

Bei uns gabs zB. auch noch ein Praktikum Mikroprogrammierung (basierend 
auf den antiken AMD-Bitslice-Chips AM29xx). Nicht, weil irgendjemand 
noch eine CPU genau so aufbaut, sondern weil es lehrt, wie man komplexe 
Aufgaben inhaltlich und zeitlich so aufteilen kann, dass die Daten wie 
auf einer Modellbahn sauber durch alle Pfade und Weichen flutschen.

*) Ist IMO eh das Wichtigste in der Informatik. Wirklich konkret wissen 
muss man eigentlich gar nix, man muss nur wissen, wie/wo man schnell an 
die Infos kommt...

von J. S. (engineer) Benutzerseite


Lesenswert?

Joey5337 schrieb:
> Und dass ein process nicht "ausgeführt" wird, wenn sich eines
> der Signale in der sensitivity-list ändert. Obwohl das im Code aussieht
> wie eine Pascal-Function mit aufeinander folgenden Anweisungen.

Ähäm:

a) es SIND ja Pascal-Funktionen. Die HDL hat sich u.a. daraus 
entwickelt. Es war zunächst eine reine Software, die ausgeführt wurde, 
um die Funktion des Systems zu checken, also die Abläufe, bevor sich 
einer drangemacht hat, es in den Chip zu bringen.

b) es WIRD auch ausgeführt! - nur nicht vom späteren FPGA, sondern der 
Software, mit der der beschriebene FPGA / dessen Funktion analysiert 
wird. Die Liste enthält diejenigen Variablen, bei deren späteren 
Abarbeitung die Funktion aufgerufen werden soll. Nur so kann der 
Simulator richtig arbeiten. Beim Compilieren muss ja dafür gesorgt 
werden, dass alles, was von etwas anderem abhängt, auch noch einmal 
angesprungen wird, wenn sich der Zustand der Quelle ändert. Fehlt eine 
Variable, wird kein Funktionsaufruf eingebaut und deren Änderung 
folglich nicht mit simuliert. Sie wird in der Unterfunktion erst dann 
wahrgenommen, wenn sie aus einem anderen Grund heraus angesprungen 
wurde. Damit passt dann das Zeitverhalten eventuell nicht mehr mit dem 
zusammen, was real passiert. Auf diese Weise kann man aber die 
Datenübernahme mit und ohne Takt unterscheiden und ein einfaches 
D-Flip-Flop realisieren, indem man den Dateneingang aus der Sens-Liste 
weglässt und nur den Takt hinschreibt. Bevor es den Konstrukt mit dem 
rising_edge gab, hat man sogar das ganze FF so hingeschrieben - mit UND 
und Rückspeisung.

Die Tatsache, dass die Sens-Liste indirekt die Funktionsaufrufe steuert, 
ist auch der Grund, warum die Inhalte für die Synthese nicht relevant 
ist: Bei dieser wird ja die Struktur abgebildet und gebaut. Eine 
Struktur ist aber immer da und zwar für alle Signale und wird in der 
Realität auch immer un zu jeder Zeit funktionieren, ob man es bedacht 
hat oder nicht.

Das gilt für das implizit instanziierte FF per rising edge, wie die 
händisch aufgebaute Struktur mit UND und Rückkopplung, um in PLDs ein FF 
zu realisieren. Das sind allerdings technisch zwei verschiedene Dinge 
und letzteres sollte man heute tunlichst vermeiden, Stichwort asynchrone 
Latches, weil deren Zeitverhalten nicht eindeutig bestimmbar ist.

Es gilt mithin auch für ungewollt aufgebaut wired-OR, die sich leicht 
beschreiben, aber nicht bauen lassen.

Eigentlich ist das sehr einfach zu verstehen, wenn man sich immer vor 
Augen führt, wer einen Code wie nutzt. Und eigentlich ist DAS die 
Aufgabe des Lehrenden, das zu vermitteln. Da scheint es aber Defizite zu 
geben.

: Bearbeitet durch User
von J. S. (engineer) Benutzerseite


Lesenswert?

Was den Aufbau von Programmen angeht, habe ich den Studenten folgendes 
Beispiel mitgegeben:

Wenn es eine Rechenaufgabe zu lösen gilt, die mit einem Taschenrechner 
zu berechnen ist, dann ist:

- die Formel eine Handlungsanweisung für eine Person,
nämlich eine Vorschrift für einen Bediener zur Benutzung des 
Taschenrechners, welche Tasten er zu drücken hat.

- das C-Programm eine Handlungsanweisung für eine Software,
nämlich eine Vorschrift für einen Compiler zur Benutzung der späteren 
CPU-Architektur, um die konkrete Funktion des Taschenrechners, sowie das 
Verhalten des Bedieners abzuarbeiten, inklusive der Abläufe, welche 
Tasten zu drücken sind, um die Formel zu realisieren

- das HDL-Programm eine Handlungsanweisung für eine Software,
nämlich eine Vorschrift für eine Layoutsoftware zur Benutzung der 
späteren FPGA-Architektur, um die Funktion des Taschenrechners, sowie 
das Verhalten des Bedieners abzuarbeiten, inklusive alle Abläufe

Vereinfacht ausgedrückt:

C ist die auf die Formel abgespeckte Bedienungsanleitung für die Nutzung 
- HDL ist eine (auf die Formel reduzierte) Bauanleitung für den 
Taschenrechner.

Beim HDL kommt noch hinzu, dass eben auch Funktion von Struktur 
beschrieben und umgesetzt wird (FSM z.B.) und dass auch die Simulation 
drauf losgelassen  wird, was in etwa dem Level des C-Programms 
entspricht, sofern es BEHAVIORAL.

von Gerd (Gast)


Lesenswert?

Jürgen S. (engineer) Benutzerseite
>- das HDL-Programm eine Handlungsanweisung für eine Software,
>nämlich eine Vorschrift für eine Layoutsoftware zur Benutzung der
>späteren FPGA-Architektur, um die Funktion des Taschenrechners, sowie
>das Verhalten des Bedieners abzuarbeiten, inklusive alle Abläufe

Wir hatten gestern eine Diskussion im kleinen Kreis: es wäre hilfreich, 
die Terminologie "konfigurieren" statt "programmieren" bei FPGAs zu 
verwenden. Es wird nämlich eine Schaltung im FPGA konfiguiert. Das führt 
zu deutlich weniger Verwirrung bei den Studenten.

Die Erklärung geht dann so:

Mittels VHDL wird eine "Fuse-List" erzeugt. Diese werden in das FPGA 
geladen und erzeugen dort dann die Verbindung zwischen den 
Logikelementen im FPGA.
Durch die gesetzten Verbindungen ist dann das FPGA so konfiguriert, dass 
die gewünschte Schaltung entsteht.

von Georg A. (georga)


Lesenswert?

Gerd schrieb:
> Wir hatten gestern eine Diskussion im kleinen Kreis: es wäre hilfreich,
> die Terminologie "konfigurieren" statt "programmieren" bei FPGAs zu
> verwenden. Es wird nämlich eine Schaltung im FPGA konfiguiert. Das führt
> zu deutlich weniger Verwirrung bei den Studenten.

Deswegen habe ich nach dem Schreiben eines kleinen Zählers die Xilinx-SW 
gestartet, den ganzen Flow durchlaufen lassen (Synthese, Mapping, 
Routing) und am Ende gezeigt, wie das im Floorplanner dann aussieht. Das 
geht auch für eine Lehrveranstaltung ausreichend schnell ;) Bei ein paar 
FFs kann man da wirklich noch die Leitungen von den Pins zu den CLBs 
verfolgen, in die CLBs reinschauen, was da so verschaltet ist, usw. 
Damit wird dann auch klar, dass da mehr dranhängt, als bei einer 
Übersetzung von Hochsprachebefehlen in Assembleropcodes. Wenn man das 
nur so abstrakt erzählt, bleibt das den meisten völlig unklar.

von Rolf (Gast)


Lesenswert?

Joey5337 schrieb:
> Grundfrage aber ist: Was genau sollen die Studis lernen?

10 % Grundlagen und 80% womit man heute in der Industrie arbeitet, 10 % 
Expertenkenntnisse.

Wenn das die Hochschulen (oder lehren so etwas auch andere Schule????) 
nicht lehren, würde ich dort nicht mich einschreiben lassen!

von klausr (Gast)


Lesenswert?

Fitzebutze schrieb:
> Aus dem Grund haben wir auch eigene Kurse entworfen und sehen von
> VHDL-Murks erst mal ab.

Wenn ihr von dem "VHDL-Murks" abseht, was nehmt ihr dann? Und welche 
Inhalte haben dann eure Kurse?

von Yalu X. (yalu) (Moderator)


Lesenswert?

Gerd schrieb:
> Wir hatten gestern eine Diskussion im kleinen Kreis: es wäre hilfreich,
> die Terminologie "konfigurieren" statt "programmieren" bei FPGAs zu
> verwenden.

IMHO hängt die optimale Wahl der Begrifflichkeiten von der Zielgruppe
ab, denen man das Arbeiten mit FPGAs nahebringen möchte.

Ein reiner E-Techniker, der mit Informatik (noch) wenig am Hut hat,
versteht unter "Programmieren" das Programmieren eines Computers bspw.
in C oder Fortran, die beide zur Klasse der imperativen Sprachen
gehören (imperativ deswegen, weil Programme aus Anweisungen bestehen,
die vom Computer Schritt für Schritt abgearbeitet werden). Da aber
Hardwarebeschreibungssprachen wie Verilog oder VHDL mit imperativer
Programmierung kaum etwas zu tun haben, ist es hier sicher besser, einen
anderen Begriff, wie bspw. das von dir vorgeschlagene "Konfigurieren" zu
verwenden.

Anders sieht es bei reinen Informatikern aus, die mit E-Technik (noch)
wenig am Hut haben. In der Softwaretechnik versteht man unter
"Konfigurieren" die Einstellung von Parametern (wie bspw. Dateipfade,
IP-Adressen und dergleichen, um die Software an die jeweilige Umgebung
anzupassen), was gemeinhin als triviale Tätigkeit angesehen wird. Die
sehr viel anspruchsvollere Tätigkeit ist die Entwicklung der Software
selbst, also die Programmierung. Die Installation und Konfiguration
hingegen kann oft von angelernten IT-Hilfskräften übernommen werden.

Um den Informatikern vor vornherein klar zu machen, dass es sich bei der
Konfiguration von FPGAs sehr wohl um etwas Anspruchsvolles handelt, das
keineswegs auf die leichte Schulter zu nehmen ist, sollte man hier IMHO
tatsächlich von "Programmierung" sprechen, gleichzeitig aber deutlich
machen, dass mit "Programmierung" nicht die imperative, sondern die
datenflussorientierte gemeint ist, denn tatsächlich gehören Verilog
und VHDL zur Klasse der datenflussorientierten Programmiersprachen (zu
denen bspw. auch LabView als grafische Sprache gehört):

  https://en.wikipedia.org/wiki/Dataflow_programming

Jeder, der die Vorlesung über Programmierparadigmen nicht geschwänzt
hat, weiß dann, dass ihm seine Programmiererfahrung in C++ oder Python
bei der Arbeit mit FPGAs gar nichts nützt und er die Angelegenheit unter
einem ganz anderen Blickwinkel betrachten muss.


Leider hat VHDL seine Wurzeln in Ada (also einer imperativen Sprache),
das wiederum viel von Pascal geerbt hat. Da kommt schnell ein "Ach das
kenne ich doch schon"-Gefühl auf, das das Denken vieler FPGA-Einsteiger
(nicht nur Informatiker) erst einmal blockiert. Auch Verilog ist in
dieser Hinsicht nicht viel besser.

Vor der Einführung in eine HDL sollte deswegen den Leuten nach einer
allgemeinen Einführung in die Digitaltechnik erst einmal gezeigt werden,
wie ein FPGA prinzipiell aufgebaut ist und das Zusammenwirken der
konfigurierbaren Logikblöcke, Verbindungsleitungen und I/Os erläutern.
Bei einem imperativen Programm kann man (wenn man von Multithreading
absieht) zu jedem Zeitpunkt mit dem Finger auf eine Codezeile bzw.
Programmspeicheradresse zeigen, die gerade aktiv ist. Beim FPGA geht das
natürlich nicht, denn da müsste man mit Tausenden bis Millionen von
Fingern auf alle Logikblöcke zeigen, die gerade ihren Zustand ändern.
Vielleicht hilft dieser Vergleich ein wenig, sich von der Vorstellung
der Schritt-für-Schritt-Ausführung zu lösen.


Hmm ...

Nachdem meinen langen Text gerade noch einmal durchgelesen habe, bin ich
mir plötzlich unsicher, ob die diskutierte Begrifflichkeit überhaupt
irgendein nennenswertes Problem darstellt:

Vielleicht genügt auch ganz einfach, den Studenten einmal zu Beginn
klipp und klar zu sagen: "Leute, sch...egal, wie ihr die Tätigkeit
nennen wollt, die ein FPGA zum Leben erweckt: VHDL ist nicht C, also
versucht gar nicht erst, in VHDL C-like zu programmieren". Die werden
das dann schon kapieren, denn so dumm, wie man immer meint, sind die
Studenten ja auch wieder nicht ;-)

Auch ich selber bin nur ein dummer Informatiker und ganz gewiss alles
andere als ein FPGA-Experte. Als ich mich vor Jahren autodidaktisch ein
klein wenig in das Thema eingearbeitet habe, war die Sache mit dem von
einem Neumannschen Computer stark abweichenden "Ausführungsmodell" des
FPGAs das allerkleinste Problem. Die eigentlichen Herausforderungen
beginnen doch erst, wenn man die ersten Anwendungen entwickelt, deren
Komplexität die einer digitalen Stoppuhr o.ä. deutlich übersteigt.


Noch etwas am Rande:

Zwei meiner Bekannten beschäftigen sich als gelernte Elektroingenieure
hauptberuflich mit FPGAs und sind IMHO auch wirklich gut darin. In einer
gewöhnlichen Unterhaltung, in der keiner irgendwelche Haare spalten
möchte, sprechen beide ganz salopp vom "FPGA-Programmierung", ebenso,
wenn sie jemand nach ihrer beruflichen Tätigkeit fragt ("Ich mache
FPGA-Konfiguration" klingt ja auch irgendwie komisch). So falsch kann
"Programmierung" also nicht sein. Erst wenn man näher ins Detail geht,
fällt manchmal tatsächlich auch der Begriff "Konfiguration", dann aber
meist nur im Zusammenhang mit dem Configuration-Memory.

von Fitzebutze (Gast)


Lesenswert?

klausr schrieb:
>
> Wenn ihr von dem "VHDL-Murks" abseht, was nehmt ihr dann? Und welche
> Inhalte haben dann eure Kurse?

Ich hole mal kurz aus: Unsereiner 'durfte' noch 74xx und 40xx-Logik auf 
Breadboards zusammenstecken und sich früh eine blutige Nase mit 
synchronen/asynchronen und Cross-Clock-Domain-Transfer holen. Das hat 
sich beim Wissenserwerb "trotz" klarem Software-Hintergrund ausgezahlt.

Das Ziel war, sehr früh auf dem Schirm zu haben, welches syntaktische 
Konstrukt in welchem Bestandteil der Netzliste endet, heisst, 
Syntheseschritte grundsätzlich zu verstehen und unmittelbar auf 
Korrektheit zu verifizieren.
VHDL oder nun öfters Verilog spielt eher noch als Transfersprache oder 
beim Interfacing eine Rolle, nicht mehr beim Design.
Die Inhalte ansonsten sind klassisch mit dem Fokus auf Arithmetik und 
Eleganz (da finden sich die meisten Stolperfallen in den V*-HDLs). Also 
von FF über Mux, Zähler (Gray, LFSR, ...) bis zur Prozessorpipeline 
(RISC-V-Extensions) und SoC-Abstraktionen.

Um das lästige Dauerbrennerthema Programmierung versus 'Konfiguration' 
aufzugreifen: Geschätzt 90% der Beiträge hier wie auch Dozenten an den 
Hochschulen benutzen unpräzise Formulierungen und stiften damit eine 
Menge Verwirrung. Also:
- Wir programmieren eine funktionale Beschreibung/eine Simulation
- Wir synthetisieren in eine Netzliste (das ist noch keine 
Konfiguration)
- Beim Download ins FPGA (nach place & route) wird selbiges 
konfiguriert, aber allenfalls auch auf seine Funktion programmiert, das 
hängt von der Architektur und der Bootphase ab.

Da auch EEPROMs mit einem Bitstrom 'programmiert' werden, gibt es keinen
Grund, an der Stelle andere Begriffe zu finden.

von Christoph Z. (christophz)


Lesenswert?

Yalu X. schrieb:
> In einer
> gewöhnlichen Unterhaltung, in der keiner irgendwelche Haare spalten
> möchte, sprechen beide ganz salopp vom "FPGA-Programmierung", ebenso,
> wenn sie jemand nach ihrer beruflichen Tätigkeit fragt

Bei mir heisst das "Ich mache FPGA Entwicklung", gehört ja neben HDL 
schreiben noch viel anderes dazu wie Requirements schreiben, Architektur 
planen, dokumentieren, debuggen in Simulation, Inbetriebnahme und Test 
der realen Hardware im Labor.

Ist bisher glaub nur einmal vorgekommen, das jemand gefragt hat ob ich 
für FPGAs entwickle oder ob ich die FPGAs selber entwickle :-)

Yalu X. schrieb:
> gleichzeitig aber deutlich
> machen, dass mit "Programmierung" nicht die imperative, sondern die
> datenflussorientierte gemeint ist

Ja, das darf und soll man in einem Grundlagenkurs durchaus mal erwähnt 
werden. Auch einem E-Technikstudent tut es gut, wenn ihm mal jemand 
erklärt, dass es verschiedene Programmierparadigmen gibt (Die IT 
Vorlesungen bei den E-Technikern machen das üblicherweise nicht).

Georg A. schrieb:
> Deswegen habe ich nach dem Schreiben eines kleinen Zählers die Xilinx-SW
> gestartet, den ganzen Flow durchlaufen lassen (Synthese, Mapping,
> Routing) und am Ende gezeigt, wie das im Floorplanner dann aussieht.

Find ich sehr gut um zu zeigen, um was es da eigentlich geht. Danach 
kann man Zeigen was so ein Logic Block denn nun kann, wie das mit HDL 
geht etc.

von Rolf (Gast)


Lesenswert?

Georg A. schrieb:
> Gerd schrieb:
>> Wir hatten gestern eine Diskussion im kleinen Kreis: es wäre hilfreich,
>> die Terminologie "konfigurieren" statt "programmieren" bei FPGAs zu
>> verwenden. Es wird nämlich eine Schaltung im FPGA konfiguiert. Das führt
>> zu deutlich weniger Verwirrung bei den Studenten.

FPGA Architekt designet Hardware, im Hardwarebüro.

Programmieren tuen die Softwarer.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Christoph Z. schrieb:
> Ist bisher glaub nur einmal vorgekommen, das jemand gefragt hat ob ich
> für FPGAs entwickle oder ob ich die FPGAs selber entwickle :-)

Ich: "Dafür muss ich mal in den Quellcode des Prozessors schauen." 
(Nein, nicht in den Quellcode für die Software, die auf dem Prozessor 
läuft...) Da derjenige ein Vertriebler im IT-Bereich und daher durchaus 
halbwissend war, schaute er mich ziemlich irritiert an und wechselte das 
Thema. Ich weiß nicht, ob er sich nur keine Blöße geben wollte oder mich 
für bekloppt hielt.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Yalu X. schrieb:
> IMHO hängt die optimale Wahl der Begrifflichkeiten von der Zielgruppe
> ab, denen man das Arbeiten mit FPGAs nahebringen möchte.

Eigentlich ist das ganz einfach: Es handelt sich um PROGRMMIERBARE 
Logik. Folglich ist das, was man da tut, eben Programmieren. Und 
Programmieren heißt, eben ein Programm aufzustellen, also etwas zu 
formulieren, was getan werden soll. Solchen Terminus kennen selbst 
Politiker.

Das Verdrehen von Begrifflichkeiten kommt aus dem Bestreben von 
Programmierern, die sowas wie FPGA's programmieren, sich sprachlich von 
den anderen Programmierern abzusetzen, weil sie sich für etwas Besseres 
halten.

Ich hatte ja hier schon mal geschrieben, daß Programmiersprachen wie 
Verilog und VHDL eben keine "Hardwarebeschreibungs"-Sprachen sind und 
man zur Beschreibung der Hardware zumeist Englisch verwendet. Man schaue 
da z.B. mal in die Manuals von Xilinx. Aber das wollen die 
FPGA-Programmierer nicht hören und sie halten sich deswegen die Ohren 
zu.

Dss ganze Thema hat große Ähnlichkeit mit dem Umbenennen des 
Schraubenziehers in Schraubendreher, um sich als etwas Besonderes 
hervorzutun. Ist auch ähnlich wichtig. Und wenn man solchen Leuten dann 
sagt, daß Schrauben heutzutage nur noch selten gedreht werden, sondern 
rollgewalzt oder anderweitig spanlos umgeformt, dann gucken die recht 
konsterniert.

W.S.

von Yalu X. (yalu) (Moderator)


Lesenswert?

W.S. schrieb:
> Das Verdrehen von Begrifflichkeiten kommt aus dem Bestreben von
> Programmierern, die sowas wie FPGA's programmieren, sich sprachlich von
> den anderen Programmierern abzusetzen, weil sie sich für etwas Besseres
> halten.

Nein, das würde ich niemandem vorwerfen. Wie ich oben schon schrieb,
beruht die Benennung dieser Tätigkeit auf unterschiedlichen Sichtweisen
der Materie, die ihre Ursache wiederum in dem mehr oder weniger hohen
Rand des Tellers hat, in dem jeder von uns (auch du und ich) sitzt.

Hier ist mal eine Auswahl der Bedeutungen von "programmieren" in
verschiedenen technischen Gebieten:

1. Entwicklung einer PC- oder Mikrocontroller-Software

2. Entwicklung einer Konfiguration für ein FPGA

3. Aufspielen einer Firmware bzw. einer Konfiguration auf einen
   Mikrocontroller oder ein FPGA (also das, worauf du dich in deinem
   ersten Absatz beziehst)

4. Konfigurieren einer Analogschaltung (bspw. des TLC271, bei dem über
   den Bias-Eingang der Ruhestrom und damit die GBW, Slewrate und
   Differenzverstärkung in drei Stufen eingestellt werden kann).

Mit (1), (2) und (3) kann ich mich sehr gut anfreunden, bei (4) fällt es
mir zugegebenermaßen etwas schwer, von "programmieren" zu sprechen, weil
das doch arg weit weg ist von dem, was ich üblicherweise programmiere.
Im Zusammenhang mit Analog-ICs ist das aber durchaus gängiger Jargon.
Möglicherweise werde ich deswegen von Analogtechnikern als überheblich
angesehen ;-)

Weitere Bedeutungen von "Programmierung" (auch nichttechnisch):

  https://de.wikipedia.org/wiki/Programmierung_(Begriffskl%C3%A4rung)

von Georg A. (georga)


Lesenswert?

W.S. schrieb:
> Ich hatte ja hier schon mal geschrieben, daß Programmiersprachen wie
> Verilog und VHDL eben keine "Hardwarebeschreibungs"-Sprachen sind und
> man zur Beschreibung der Hardware zumeist Englisch verwendet. Man schaue
> da z.B. mal in die Manuals von Xilinx. Aber das wollen die
> FPGA-Programmierer nicht hören und sie halten sich deswegen die Ohren
> zu.

Doch, gerade VHDL ist zuallererst als reine Beschreibungssprache 
entwickelt worden. Das DOD wollte eine Methode, damit alle 
Hersteller/Zulieferer ihren Digital/Protokoll-Kram "wohldefiniert" 
beschreiben und auch gegeneinander testen können, statt sich nur auf 
irgendein schwammiges Englisch in undurchschaubaren Requirementlisten zu 
verlassen.

Zu dem Zeitpunkt (Mitte 80er Jahre) ging nur Simulation, VHDL hat ja 
auch viele Konstrukte, die nur simulierbar sind. FPGAs waren zu der Zeit 
noch exotische Spielereien, eine vernünftig nutzbare Synthese (egal ob 
ASIC oder FPGA) ist erst Anfang der 90er aufgekommen.

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

W.S. schrieb:
> Eigentlich ist das ganz einfach: Es handelt sich um PROGRMMIERBARE
> Logik. Folglich ist das, was man da tut, eben Programmieren. Und
> Programmieren heißt, eben ein Programm aufzustellen, also etwas zu
> formulieren, was getan werden soll.

Das Wort Programmieren ist ein Homonym.

https://de.wikipedia.org/wiki/Homonym

> Ich hatte ja hier schon mal geschrieben, daß Programmiersprachen wie
> Verilog und VHDL eben keine "Hardwarebeschreibungs"-Sprachen sind

Ohje!

> Dss ganze Thema hat große Ähnlichkeit mit dem Umbenennen des
> Schraubenziehers in Schraubendreher, um sich als etwas Besonderes
> hervorzutun.

Nö, es ist schlicht korrekt. Den ZIEHEN tut da keiner. Woher auch immer 
der Begriff kommt.

 Ist auch ähnlich wichtig. Und wenn man solchen Leuten dann
> sagt, daß Schrauben heutzutage nur noch selten gedreht werden, sondern
> rollgewalzt oder anderweitig spanlos umgeformt, dann gucken die recht
> konsterniert.

Jaja, immer schön schwätzen, als ob ein SchraubenDREHER was mit der 
Schraubenherstellung zu tun hat . . .

von Wühlhase (Gast)


Lesenswert?

Falk B. schrieb:
> Nö, es ist schlicht korrekt. Den ZIEHEN tut da keiner. Woher auch immer
> der Begriff kommt.

Der Begriff kommt ursprünglich aus dem Schiffbau, wo die Holzschrauben 
eingezogen wurden. Ansonsten sprechen selbst die DIN und der 
Werkstattmeister, der diesen Unsinn seinen Lehrlingen eingrichtert, vom 
Anzugsmoment oder ziehen Schrauben fest.


W.S. schrieb:
> Ich hatte ja hier schon mal geschrieben, daß Programmiersprachen wie
> Verilog und VHDL eben keine "Hardwarebeschreibungs"-Sprachen sind und
> man zur Beschreibung der Hardware zumeist Englisch verwendet.

Warum heißt es dann Hardware Description Language...?

von Falk B. (falk)


Lesenswert?

Wühlhase schrieb:
> Ansonsten sprechen selbst die DIN und der
> Werkstattmeister, der diesen Unsinn seinen Lehrlingen eingrichtert, vom
> Anzugsmoment oder ziehen Schrauben fest.

Naja, man zieht am Schraubenschlüssel, bis die Schraube fest ist oder 
abschert, nach fest kommt ab 8-0
Und eine Schraube bewirkt eine Zugkraft längs ihrer Achse, sei es eine 
Holzschraube oder Maschinenschraube.
Also bringt der SchraubenZIEHER Zug in die Verschraubung. Hmmm.

von Myclass (Gast)


Lesenswert?

Hallo an die FPGA Spezialisten, ich hätte da eine Frage. Wie falsch lege 
ich, wenn ich behaupte, dass mithilfe von FPGA die KI Modelle schneller 
berechnet werden können als z. B. mit den heutigen Ansätzen mit Script- 
oder Interpreter-Sprachen? Dass die FPGA in ersten Linie für Hardware 
Design verwendet wird - ist nachvollziehbar,  aber lässt sich es auch 
auch für andere Themen wie z.B. Mashine Learning anwenden oder ist das 
mit Kanonen auf Spatzen zu schießen. Danke.

von Falk B. (falk)


Lesenswert?

Myclass schrieb:
> Hallo an die FPGA Spezialisten, ich hätte da eine Frage. Wie falsch lege
> ich, wenn ich behaupte, dass mithilfe von FPGA die KI Modelle schneller
> berechnet werden können als z. B. mit den heutigen Ansätzen mit Script-
> oder Interpreter-Sprachen?

Ist das ein Witz? ALLES ist schneller als Script- und 
Interpretersprachen!

> Design verwendet wird - ist nachvollziehbar,  aber lässt sich es auch
> auch für andere Themen wie z.B. Mashine Learning anwenden

Sicher. Denn KI, so wie sie heute existiert, ist auf MASSIVE 
Rechenleitung angewiesen.

von Mcn (Gast)


Lesenswert?

Myclass schrieb:
> Dass die FPGA in ersten Linie für Hardware
> Design verwendet wird - ist nachvollziehbar,  aber lässt sich es auch
> auch für andere Themen wie z.B. Mashine Learning anwenden oder ist das
> mit Kanonen auf Spatzen zu schießen. Danke.

Du bist aber ein Blitzmerker ... das ASIC/FPGA schneller als 
Softwaregerüdel ist, hat man spätestens in den neunzigern erkannt. 
Siemens hat mit Synapse-1 1993 einen Neurocomputer rausgeballert der 
faktor 8000 schneller war als eine Workstation.
https://link.springer.com/chapter/10.1007/978-3-642-78565-8_11

War halt nicht der Hype damals, das da damit jedesnaseweise scriptkiddie 
um die Ecke kamm.

https://www.heise.de/news/Xilinx-Kria-K26-FPGA-gestuetztes-AI-Modul-6037306.html

von Duke Scarring (Gast)


Angehängte Dateien:

Lesenswert?

Yalu X. schrieb:
> Hier ist mal eine Auswahl der Bedeutungen von "programmieren" in
> verschiedenen technischen Gebieten:
>
> 1. ...
>
> 2. ...
>
> 3. ...
>
> 4. ...

5. Ich muß heute wieder ein paar Widerstände programmieren...

von Mcn (Gast)


Lesenswert?

Duke Scarring schrieb:

> 5. Ich muß heute wieder ein paar Widerstände programmieren...

Jajaja, immer lustig die translation failures: 
https://youtu.be/CkbHGH-NnkU?t=65


Und ich glaub ich hab irgendwie noch den Zettel wie man den PC-AT "auf 
Turbo 'programmiert'" (Jumper setzen für die taktanzeige).

https://de.wikipedia.org/wiki/Turbo-Taste

von Yalu X. (yalu) (Moderator)


Lesenswert?

Myclass schrieb:
> Hallo an die FPGA Spezialisten, ich hätte da eine Frage. Wie falsch lege
> ich, wenn ich behaupte, dass mithilfe von FPGA die KI Modelle schneller
> berechnet werden können als z. B. mit den heutigen Ansätzen mit Script-
> oder Interpreter-Sprachen?

Das ist schwer zu sagen. Das, was die KI-ler in Python programmieren,
läuft letztendlich meist auf einer GPU. Die FPGAs konkurrieren hier also
mit GPUs. Welcher der beiden Ansätze derzeit die Nase vorn hat, kann ich
nicht sagen, das hängt wohl auch von der konkreten Anwendung ab.

> Dass die FPGA in ersten Linie für Hardware Design verwendet wird - ist
> nachvollziehbar,  aber lässt sich es auch auch für andere Themen wie
> z.B. Mashine Learning anwenden oder ist das mit Kanonen auf Spatzen zu
> schießen. Danke.

FPGAs werden definitiv auch für Machine Learning eingesetzt. Für die
meisten "Büro-KI-ler" ist es aber bequemer, einen gewöhnlichen PC mit
einer leistungsstarken Grafikkarte zu verwenden. Für eingebettete
Systeme ist das aber wegen der Baugröße und des Stromverbrauchs meist
keine gute Option.

von Myclass (Gast)


Lesenswert?

Falk B. schrieb:
> Sicher. Denn KI, so wie sie heute existiert, ist auf MASSIVE
> Rechenleitung angewiesen.

Danke dir für die Antwort. Doch, wenn ich um mich herum umsehe, wird in 
dem Umfeld nur in Phyton programmiert. Und die langsame Geschwindigkeit 
wird in Kauf genommen.  Daher eventuell meine präzisere Frage - wieso 
wird weiter eine langsame (wie schon erwähnt wurde mit Faktor 8000) 
Umgebung für Daten-intensivsten Aufgaben verwendet, wenn es um die KI 
Modelle handelt? Mangel am Wissen, weil alle so machen, 1 Tag zu warten 
bis das KI Model berechnet wurde ist nicht schlimm usw.? Danke.

von Wühlhase (Gast)


Lesenswert?

Myclass schrieb:
> wieso
> wird weiter eine langsame (wie schon erwähnt wurde mit Faktor 8000)
> Umgebung für Daten-intensivsten Aufgaben verwendet, wenn es um die KI
> Modelle handelt?

Python wird für vieles verwendet, wo Skriptsprachen eher nicht für 
gedacht sind.

Angefangen hat es, soweit ich weiß, einmal damit, daß man in Python 
relativ einfach Zahlenkolonnen in Diagrammen und Kurven darstellen 
konnte. Heute wird Python gerne deshalb genutzt, weil es für jeden 
Scheiß eine Bibliothek gibt.
Es ist relativ einfach zu lernen, man muß wenig Eigenarbeit reinstecken, 
und daher ist es in der Wissenschaft weit verbreitet.

Und irgendwann wird die weite Verbreitung ein Selbstläufer, weil der 
Dozent seinen Schülern/Studenten zeigt wie was mit Python gemacht wird. 
Da kommt kaum einer auf die Idee, etwas anderes zu benutzen.

Fragen wie die nach Effizienz stehen da oft ganz weit hinten und werden 
oft gar nicht erst überdacht.

von Bewahrer der Ordnung (Gast)


Lesenswert?

Myclass schrieb:
> Daher eventuell meine präzisere Frage - wieso
> wird weiter eine langsame (wie schon erwähnt wurde mit Faktor 8000)
> Umgebung für Daten-intensivsten Aufgaben verwendet, wenn es um die KI
> Modelle handelt? Mangel am Wissen, weil alle so machen, 1 Tag zu warten
> bis das KI Model berechnet wurde ist nicht schlimm usw.?

Bitte mache für diese neue Frage eine neuen Thread auf. Sehr Danke!

von Myclass (Gast)


Lesenswert?

Bewahrer der Ordnung schrieb:
> Bitte mache für diese neue Frage eine neuen Thread auf. Sehr Danke!

Alles gut, der Redner (Wühlhase) davor hat meine Frage ausführlich 
beantwortet.

von Myclass (Gast)


Lesenswert?

Wühlhase schrieb:
> Fragen wie die nach Effizienz stehen da oft ganz weit hinten und werden
> oft gar nicht erst überdacht.

Danke für deine Antwort - sie bestätigt genau auch meine Vermutung!

von Yalu X. (yalu) (Moderator)


Lesenswert?

Wühlhase schrieb:
> Python wird für vieles verwendet, wo Skriptsprachen eher nicht für
> gedacht sind.
>
> ...
>
> Fragen wie die nach Effizienz stehen da oft ganz weit hinten und werden
> oft gar nicht erst überdacht.

Man kann auch in Python sehr performante Programme schreiben, wenn man
geeignete Bibliotheken verwendet, die den Großteil der Rechenarbeit
übernehmen oder gar auf externe Hardware (bspw. eine GPU) auslagern.
Genau das wird beim Einsatz von Python in Machine Learning,
Bildverarbeitung und vielen anderen Anwendungen getan.

Aber wie der "Bewahrer der Ordnung" bereits schrieb, führt dies immer
mehr vom eigentlichen Thema weg und sollte nicht in diesem Thread
weiterdiskutiert werden.

: Bearbeitet durch Moderator
von Fitzebutze (Gast)


Lesenswert?

Myclass schrieb:
> Danke dir für die Antwort. Doch, wenn ich um mich herum umsehe, wird in
> dem Umfeld nur in Phyton programmiert. Und die langsame Geschwindigkeit
> wird in Kauf genommen.

Nicht zwingend, da sich:
- Python-Berechnungen per LLVM beschleunigen lassen
- C-API-Bibliotheken einfach wrappen
- Python-Routinen ohne Änderungen in Hardware oder GPU-Elemente giessen 
lassen

Das macht Python zu einer echten Beschreibungssprache (was bei VHDL 
und Verilog gründlich schiefgegangen ist, deren Paradigmen entsprechen 
nach wie vor einer lupenreinen Programmiersprache, siehe Turing).

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Wühlhase schrieb:
> Es ist relativ einfach zu lernen, man muß wenig Eigenarbeit reinstecken,
> und daher ist es in der Wissenschaft weit verbreitet.

Was ja erstmal kein Nachteil ist.

> Fragen wie die nach Effizienz stehen da oft ganz weit hinten und werden
> oft gar nicht erst überdacht.

Sie sind auch oft nicht wichtig, wenn es darum geht, ein neues Konzept 
überhaupt erstmal in Software zu gießen. Ob das dann um einen Faktor 
1000 langsamer ist, ist oft nebensächlich. "Proof of concept" ist das 
Stichwort.

Ich arbeite bspw. gerne mit Tcl/Tk (auch Skriptsprache) - in 99% der 
Fälle ist das von der Effizienz her alleine völlig ausreichend (sogar 
direkt auf µC als C-Ersatz), dafür aber bspw. der Code/die Oberfläche 
während des laufenden Programms änderbar.

Und für das eine Prozent gibt es dann passende Schnittstellen.

: Bearbeitet durch Moderator
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Yalu X. schrieb:
> 4. Konfigurieren einer Analogschaltung (bspw. des TLC271, bei dem über
>    den Bias-Eingang der Ruhestrom und damit die GBW, Slewrate und
>    Differenzverstärkung in drei Stufen eingestellt werden kann).
>
> Mit (1), (2) und (3) kann ich mich sehr gut anfreunden, bei (4) fällt es
> mir zugegebenermaßen etwas schwer, von "programmieren" zu sprechen, weil
> das doch arg weit weg ist von dem, was ich üblicherweise programmiere.

Heutzutage gibt es tatsächlich viele analoge Bauelemente mit 
"programmierbaren" Elementen. Sog. programmierbare MOSFETs enthalten 
zwischen dem Gate und dem Kanal noch ein zusätzliches Floating Gate, mit 
dessen Ladezustand sich die Thresholdspannung sehr fein einstellen 
lässt, d.h. von reinen Verarmungstyp bis hin zum reinen 
Anreicherungstyp.

https://www.aldinc.com/ald_mosfetarrays.php

Einige Analog-IC sind mit ähnlichen Methoden herstellerseitig für z.B. 
eine minimale Offsetspannung "vorprogrammiert". Im Gegensatz zur 
Lasertrimmung kann dann die "Programmierung" erfolgen, wenn der Chip 
schon im Gehäuse untergebracht ist. Vielfach wird aber auch kein 
Analogwert direkt in einem Floating Gate gespeichert, sondern ein ganzer 
DAC oder gar Microcontroller im IC untergebracht.

: Bearbeitet durch User
von Markus F. (mfro)


Lesenswert?

Wühlhase schrieb:
> Fragen wie die nach Effizienz stehen da oft ganz weit hinten und werden
> oft gar nicht erst überdacht.

Nun, natürlich kann man auch performancekritische Dinge in Pure Python 
schreiben, wofür es nicht gedacht ist.

Das ist aber ganz schön aufwendig: man muss sie nämlich neu erfinden.

Wer Libraries wie numpy oder tensorflow benutzt, benutzt bei ersterem 
automatisch hochoptimierte, nativ ausgeführte Routinen wie BLAS oder 
LAPACK und bei letzerem (so er denn hat) die GPU und eben kein Python - 
zumindest nicht für die performancekritischen Teile.

von Wühlhase (Gast)


Lesenswert?

Chris D. schrieb:
> [...]

Ich wollte keine Diskussion über Vor- und Nachteile von Pyhton starten. 
Nur die Frage beantworten. :)

von W.S. (Gast)


Lesenswert?

Wühlhase schrieb:
> Warum heißt es dann Hardware Description Language...?

Das erinnert mich an die Frage von klein Fritzchen an seinen Vater:
"Warum heißt der Rollmops eigentlich Rollmops?"
Antwort:
"Tja, sieht aus wie ein Rollmops,
schmeckt auch so wie ein Rollmops,
warum soll er dann nicht auch Rollmops heißen?"

..und warum soll eine Programmiersprache für programmierbare 
Logik-Bauteile nicht Programmiersprache heißen?

Wir hatten hier schon mal Leute, die die deutsche Sprache partout 
reformieren wollten und deshalb u.a. alles, was mit 'wenden' zu tun hat, 
mit 'ä' schreiben wollten, weil es ja ihrer Ansicht nach von der Wand 
kommt. Es sind imme wieder die geltungssüchtigen Knalltüten, die 
etablierte Bezeichnungen wie Schraubenzieher, Programmieren, Zollstock 
und so mit selbsterfundenen neuen Namen versehen wollen, bloß weil ihnen 
nichts besseres zum Herumstänkern einfällt. Ein historisches Beispiel 
dazu ist das 'Beinkleid' anstelle der Hose.

W.S.

von Georg A. (georga)


Lesenswert?

W.S. schrieb:
> ..und warum soll eine Programmiersprache für programmierbare
> Logik-Bauteile nicht Programmiersprache heißen?

Nur weil du einen Hammer dazu nutzen kannst, verrostete Verbindungen zu 
lösen, ist ein Hammer noch lange kein Rostlöser.

VHDL kann man jetzt tatsächlich inzwischen ganz anständig für 
programmierbare Logik nehmen. Das war aber nicht immer so. Zuerst wars 
ausschliesslich nur für Simulation, dann kamen ASICs und gaaanz am 
Schluss FPGAs.

Und bis das halbwegs funktioniert hat, hat es lange gedauert. Ich habe 
1995 mit dem Synopsis Design Compiler VHDL für FPGAs rumgemacht. Der DC 
ist ursprünglich für ASICs entwickelt und das merkte man auch. FPGAs mit 
dem DC zu machen war ungefähr genauso schmerzfrei und angenehm, wie mit 
einem 5kg Rostlöser ständig auf das Knie und gegen die Stirn zu 
schlagen. Jeder SW-Entwickler hätte einen C-Compiler mit solchen 
Fehlern, wirren Abstürzen und unreproduzierbaren Ergebnissen nach ein 
paar Tagen in die Ecke geschleudert und höchstpersönlich den Hersteller 
in die Hölle gebombt.

von Bewahrer der Ordnung (Gast)


Lesenswert?

Naja Programmiersparchen wirft man auch nicht alle in einen Topf, 
sondern unterteilt die schon nach Scriptsprachen, Batchsprachen, 
Graphische Programmiersprachen, Hochsprachen, Makrosprachen, 
Druckerbefehlssprachen, ...

Und das tut man weil eben die Erfahrung lehrt, das ein Programmierer der 
permanent Scriptspachen schreibt nicht so geübt in OOP-Hochsprachen ist, 
und einer der PCL fliessend spricht dagegen in Labview eher mau ist.

manche Professoren behaupten sogar, das einer der eine bestimmte Sprache 
gelernt hat für den ganzen Rest der Programmierrei hoffnungslos 
verdorben sei. "It is practically impossible to teach good programming 
to students that have had a prior exposure to BASIC: as potential 
programmers they are mentally mutilated beyond hope of 
regeneration.(Edsger W. Dijkstra)"

Und dann kommt noch vom Rundfunk ein Programmdirektor daher und will 
auch als Programmierer ohne Einschränkungen und Spezialisierung wahr 
genommen wären....

Also ist es auch richtig das man für ein SDR-FPGA-design einen DSP 
erfahrenen FPGA-Programmierer einlädt und nicht einen 
Bank+Versicherungen Java programmer anheuert ... auch wenn sich beide 
mit dem "Schubladen-Etikett" Programmierer 'schmücken'.

von Falk B. (falk)


Lesenswert?

Myclass schrieb:
>> Sicher. Denn KI, so wie sie heute existiert, ist auf MASSIVE
>> Rechenleitung angewiesen.
>
> Danke dir für die Antwort. Doch, wenn ich um mich herum umsehe, wird in
> dem Umfeld nur in Phyton programmiert.

WAS läuft denn das WIRKLICH im schnarchlangsamen Phyton? Doch nur die 
oberflächliche Konfiguration und Steuerung der KI-Module. Diese wiederum 
laufen wie? Als compiliere Binärfiles. Der Echte KI-Algorithmis läuft 
sicher NICHT im Phyton. Und wer das trotzdem damit macht, ist selber 
Schuld.

von W.S. (Gast)


Lesenswert?

Bewahrer der Ordnung schrieb:
> sondern unterteilt die schon nach Scriptsprachen, Batchsprachen,
> Graphische Programmiersprachen, Hochsprachen, Makrosprachen,...

Nenne mir mal eine Grafische Programmiersprache. Nee, sowas nennt sich 
Stromlaufplan, Schematic oder so.

Und den Unterschied zwischen Hochsprachen und anderen Sprachen kann ich 
dir leicht erklären: Alles, was maschinenspezifisch ist, ist keine 
Hochsprache - sowas wird gemeinhin Assembler genannt. Und alles, was 
eben nicht maschinenspezifisch ist, wurde/wird dann eben Hochsprache 
genannt.

Und sowas wie Scriptsprachen, Batchsprachen (diesen Terminus hab ich 
bislang noch nie gehört) sind offenbar nichts weiter als ein Hinweis 
darauf, ob etwas in einer Programmiersprache geschriebenes nun in etwas 
maschinenspezifisches (Maschinencode oder sowas wie Fuse-Tabellen) 
übersetzt wird, oder ob es von einem Interpreter, also einem Programm, 
abgearbeitet wird. Von daher ist BASIC traditionell sowohl Hochsprache 
als auch Scriptsprache. Das Übersetzen in Maschinencode kam bei BASIC 
erst später.

W.S.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Falk B. schrieb:
> WAS läuft denn das WIRKLICH im schnarchlangsamen Phyton? Doch nur die
> oberflächliche Konfiguration und Steuerung der KI-Module.

Ist das deiner Ansicht nach ein Problem?

Betrachte die Sache einfach mal ganz pragmatisch:

- Der Anwender der Software möchte, dass diese seine funktionalen
  Anforderungen erfüllt und zudem performant läuft.

- Der Programmierer der Software möchte, dass er diese mit möglichst
  geringem Entwicklungsaufwand umsetzen kann.

Die Programmierung von ML-Anwendungen in leicht zu nutzendem Python
unter Verwendung bereits bestehender Bibliotheken erfüllt beide Wünsche
gleichermaßen. Was will man mehr? Die Alternative wäre, ständig das Rad
neu zu erfinden, was aber den Entwicklungsaufwand erhöht.

Um die Diskussion mal wieder etwas zurück zum Thread-Thema zu lenken:

Eine stark abstrahierende Sprache zu verwenden und auf bestehende, hoch
optimierte Module für wiederkehrende Aufgaben zurückzugreifen, ist nicht
nur in der PC- sondern auch in der FPGA-Programmierung gängige Praxis.

von Georg A. (georga)


Lesenswert?

W.S. schrieb:
> Bewahrer der Ordnung schrieb:
>> sondern unterteilt die schon nach Scriptsprachen, Batchsprachen,
>> Graphische Programmiersprachen, Hochsprachen, Makrosprachen,...
>
> Nenne mir mal eine Grafische Programmiersprache. Nee, sowas nennt sich
> Stromlaufplan, Schematic oder so.

Bist aber sehr von deinem Nichtwissen überzeugt... Labview ist eine 
grafische Programmiersprache, basierend auf dem Datenflussprinzip. Es 
ist ganz sicher kein Stromlaufplan oder so. Und akademisch ist es auch 
nicht, es ist (leider?) sehr weit verbreitet...

von Mcn (Gast)


Lesenswert?

Georg A. schrieb:
> W.S. schrieb:
>> Bewahrer der Ordnung schrieb:
>>> sondern unterteilt die schon nach Scriptsprachen, Batchsprachen,
>>> Graphische Programmiersprachen, Hochsprachen, Makrosprachen,...
>>
>> Nenne mir mal eine Grafische Programmiersprache. Nee, sowas nennt sich
>> Stromlaufplan, Schematic oder so.
>
> Bist aber sehr von deinem Nichtwissen überzeugt... Labview ist eine
> grafische Programmiersprache, basierend auf dem Datenflussprinzip.

Heute sagt man wohl eher "Visuelle Programmiersprache". Neben dem 
Einsatz in der Messtechnik wie Labview wird sowas auch in der 
voruniversitären Ausbildung verwendet, beispielsweise "Open Roberta" auf 
Calliope.

https://de.wikipedia.org/wiki/Visuelle_Programmiersprache

SPS/PLC und Prozessautomatisierung wäre noch ein Gebiet wo man sich 
Abläufe eher zusammenclickt statt runtertippt.

https://www.kreativekiste.de/welche-sps-plc-kleinsteuerungen-gibt-es-unterschiede-testbericht-software

Machen alles Programmierer, auch der Mantafahrer Manfred aus Mannheim 
programmiert täglich ... seinen Videorecorder!

von W.S. (Gast)


Lesenswert?

Georg A. schrieb:
> Bist aber sehr von deinem Nichtwissen überzeugt...

Ach Junge, wenn du begriffest, was du da zusammenredest...
Ich habe hier ja bereits Leute erlebt, die zu Programmen auf dem PC, die 
mittels Delphi verfaßt wurden, gesagt hatten, daß sie in Delphi 
geschrieben seien. Genauso könnte man sagen, daß andere Programme in der 
Programiersprache 'Eclipse' geschrieben worden seien.

W.S.

von Mcn (Gast)


Lesenswert?

W.S. schrieb:
> Georg A. schrieb:
>> Bist aber sehr von deinem Nichtwissen überzeugt...

> Ach Junge, wenn du begriffest, was du da zusammenredest...
> Ich habe hier ja bereits Leute erlebt, die zu Programmen auf dem PC, die

Es geht hier aber nicht die Verwechslung vun IDE/Editor mit 
drunterliegenden Compiler sondern um ganz konkrete nicht auf Texteingabe 
basierende Programmiersprachen/Systeme.

von W.S. (Gast)


Lesenswert?

Mcn schrieb:
> sondern um ganz konkrete nicht auf Texteingabe
> basierende Programmiersprachen/Systeme

Dann könnte man ein Bildbearbeitungsprogramm auch als IDE und ein Bild 
als Programmiersprache bezeichnen. Nö, sowas geht zu weit, was sich 
nicht in Worte fassen läßt oder zumindest schriftlich darstellen läßt, 
sollte nicht als Programmiersprache gelten.

OK, Spötter könnten jetzt mal fragen, wie sowas wie C mal gesprochen 
sich anhört.
For Grunz A gleichgleich B Znurg Pling C ZirpZirp gleich Pling D 
ZirpZirp Kommtnixmehr
Oder so ähnlich...

W.S.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Mcn schrieb:
> Heute sagt man wohl eher "Visuelle Programmiersprache".

Wer den Vi-Editor benutzt, programmiert in jeder Sprache visuell :D

(vi steht für "visual mode")

von Georg A. (georga)


Lesenswert?

W.S. schrieb:
> Georg A. schrieb:
>> Bist aber sehr von deinem Nichtwissen überzeugt...
>
> Ach Junge, wenn du begriffest, was du da zusammenredest...
> Ich habe hier ja bereits Leute erlebt, die zu Programmen auf dem PC, die
> mittels Delphi verfaßt wurden, gesagt hatten, daß sie in Delphi
> geschrieben seien. Genauso könnte man sagen, daß andere Programme in der
> Programiersprache 'Eclipse' geschrieben worden seien.

Du kennst Labview ganz offensichtlich nicht...

von Gerd (Gast)


Lesenswert?

W.S. schrieb:
> Nenne mir mal eine Grafische Programmiersprache. Nee, sowas nennt sich
> Stromlaufplan, Schematic oder so.

von Georg A. (georga)
>Bist aber sehr von deinem Nichtwissen überzeugt... Labview ist eine
>grafische Programmiersprache, basierend auf dem Datenflussprinzip.

W.S. schrieb:
>Ach Junge, wenn du begriffest, was du da zusammenredest...
>Ich habe hier ja bereits Leute erlebt, die zu Programmen auf dem PC, die
>mittels Delphi verfaßt wurden, gesagt hatten, daß sie in Delphi
>geschrieben seien. Genauso könnte man sagen, daß andere Programme in der
>Programiersprache 'Eclipse' geschrieben worden seien.

Gut, das ist natürlich starker Tobak für einen von sich selbst 
überzeugten Entwickler. Hier wurden dir ja einige Links zur Erklärung 
geschickt
Beitrag "Re: FPGAs in der Lehre"

Und hier geht das für LabView noch mal etwas präziser im Detail:
https://www.ni.com/de-de/shop/labview/benefits-of-programming-graphically-in-ni-labview.html

Ich habe mal zum Spaß ein 4 Gewinnt Spiel in LabView programmiert und 
ein Schachspiel hätte man auch machen können.
Scheinbar verstehst du wirklich nicht, was der Begriff "programmieren" 
bedeutet.

von Wühlhase (Gast)


Lesenswert?

W.S. schrieb:
> Nenne mir mal eine Grafische Programmiersprache. Nee, sowas nennt sich
> Stromlaufplan, Schematic oder so.

Labview. Lego Mindstorm-Kästen hat man originär übrigens ähnlich 
programmiert.
Und dann wäre da noch FUP für SPS.

Hat alles nix mit Stromlaufplänen oder dergleichen zu tun.

von Dergute W. (derguteweka)


Lesenswert?

W.S. schrieb:
> Nenne mir mal eine Grafische Programmiersprache.

Piet.

Unn? Komm ich getz in Fernsehen?
https://de.wikipedia.org/wiki/Piet_(Programmiersprache)

scnr,
WK

von Gerd (Gast)


Lesenswert?

>Piet.

Die Bilder dazu sind interessant:

https://www.dangermouse.net/esoteric/piet/samples.html

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


Lesenswert?

W.S. schrieb:
> Mcn schrieb:
>> sondern um ganz konkrete nicht auf Texteingabe
>> basierende Programmiersprachen/Systeme
> Dann könnte man ein Bildbearbeitungsprogramm auch als IDE und ein Bild
> als Programmiersprache bezeichnen.
Ich kannte mal eine Sekretärin, die sagte, sie sei 
Computerprogrammiererin, weil sie den Computer so "programmierte", das 
er den Brief so ausdruckte, wie sie das wollte.

W.S. schrieb:
> ..und warum soll eine Programmiersprache für programmierbare
> Logik-Bauteile nicht Programmiersprache heißen?
Weil sie sich in ihrem eignen Namen selbst "Beschreibungssprache" nennt?

Wenn einer sagt: "Ich bin Karl", sagst du dann auch "Hallo Franz"?

Myclass schrieb:
> Mashine Learning
Die Maschine heißt auf englisch "machine"

Auf Suaheli gehts natürlich durch:
https://en.wiktionary.org/wiki/mashine

: Bearbeitet durch Moderator
von hmm (Gast)


Lesenswert?


von Markus F. (mfro)


Lesenswert?

hmm schrieb:...
> Um was gings denn eigentlich ...

Zuerst war da tatsächlich noch ein Thema. Dann ging's schnell nur noch 
ums Recht haben.

von W.S. (Gast)


Lesenswert?

Lothar M. schrieb:
> Ich kannte mal eine Sekretärin, die sagte, sie sei
> Computerprogrammiererin, weil sie den Computer so "programmierte", das
> er den Brief so ausdruckte, wie sie das wollte.

Die Leute reden auch davon, daß sie ihre Sender im Radio auf bestimmte 
Tasten programmiert haben.

Lothar M. schrieb:
> Weil sie sich in ihrem eignen Namen selbst "Beschreibungssprache" nennt?

Hast du schon mal eine Sprache gehört, die sich selbst spricht? Nee, 
das sind immer irgendwelche Leute, die das tun.

> Wenn einer sagt: "Ich bin Karl", sagst du dann auch "Hallo Franz"?

Ja, wenn Franz versucht, mich anzulügen.

W.S.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Lothar M. schrieb:
> W.S. schrieb:
>> ..und warum soll eine Programmiersprache für programmierbare
>> Logik-Bauteile nicht Programmiersprache heißen?
> Weil sie sich in ihrem eignen Namen selbst "Beschreibungssprache" nennt?

Na ja, describen oder beschreiben tut man ja üblicherweise etwas, was
schon existiert, der FPGA-Programmierer, -Konfigurator (oder wie immer
man ihn nennen mag) schafft aber in der Regel etwas Neues.

Das "Description" in VHDL rührt noch von dessen Anfängen her, als die
Sprache ausschließlich zur Dokumentation bereits bestehender ASICs
verwendet wurde. Wäre VHDL von vornherein als Implementierungssprache
gedacht gewesen, stände das "D" vermutlich eher für "Design" oder
"Development".

Aber selbst "Hardware Design Language" wäre beim Einsatz für FPGAs nicht
sehr treffend, denn es wird damit ja keine Hardware entwickelt. Die
Hardware existiert bereits in Form des FPGAs und hat sogar schon eine
Beschreibung, nämlich in Form des Datenblatts. Was mit VHDL entwickelt
wird, ist in diesem Fall keine Hardware, sondern eine Konfiguration für
die bereits bestehende Hardware.

Wie würdest du einen Menschen nennen, der einem FPGA Leben einhaucht
(meinetwegen auch auch Englisch)?

Die Frage ist nicht leicht zu beantworten, aber "FPGA-Programmierer" ist
IMHO noch der man wenigsten schlechte Begriff dafür, gefolgt von
"FPGA-Konfigurator". Alternativen wie bspw. "FPGA-Entwickler",
"FPGA-Designer", "FPGA-Beschreiber" oder "FPGA-Describer" haben ja eine
andere Bedeutung".

von W.S. (Gast)


Lesenswert?

Yalu X. schrieb:
> Aber selbst "Hardware Design Language" wäre beim Einsatz für FPGAs nicht
> sehr treffend, denn es wird damit ja keine Hardware entwickelt. Die
> Hardware existiert bereits in Form des FPGAs und hat sogar schon eine
> Beschreibung, nämlich in Form des Datenblatts. Was mit VHDL entwickelt
> wird, ist in diesem Fall keine Hardware, sondern eine Konfiguration für
> die bereits bestehende Hardware.

Du sprichst mir aus dem Herzen.
Allerdings habe ich den Verdacht, daß da der Lothar schlechte Laune 
kriegt.

Man könnte - um das Wort "Programmiersprache" zu vermeiden - so eine 
Programmiersprache noch am ehesten eine "Ideenbeschreibungs-Sprache" 
nennen. Denn man benutzt sie, um seine Ideen zu einer gewünschten 
Funktionalität schriftlich auszudrücken. Das wäre eben die 
alphanumerische Weise, einen Stromlaufplan auszudrücken.

W.S.

von W.S. (Gast)


Lesenswert?

Markus F. schrieb:
> Zuerst war da tatsächlich noch ein Thema. Dann ging's schnell nur noch
> ums Recht haben.

Ähem... so ganz ist es nicht. Programmierbare Logik im Allgemeinen ist 
etwas, das wichtig genug ist, um beizeiten den jungen Leuten 
nähergebracht zu werden. Aber offenbar artet das in der Praxis aus zu 
einem Einführungskurs in eine bestimmte Programmiersprache.

Nun, das ist es nicht, was man an Grundlagenwissen im Studium erwerben 
sollte. Das sollte eigentlich den Studenten die Möglichkeiten (und 
Grenzen) von programmierbarer Logik näherbringen. Ganz ohne sich darauf 
einzuengen, bloß eine Programmiersprache zu lehren.

Ich sehe letzteres ziemlich ähnlich wie Tendenzen beim Programmieren von 
Mikrocontrollern, wo Leute die eigentliche Technik nicht mehr sehen (und 
z.T. nicht sehen WOLLEN), sondern sich bloß in einer Programmiersprache 
ergehen und anstatt zu wissen, was für ein Tier sie zu reiten 
beabsichtigen, für jeden Furz eine Bibliotheksfunktion haben wollen. Und 
für den Gesamtentwurf einen Codegenerator vom Hersteller und eine darauf 
spezialisierte IDE.

An Ende solcher mentaler Ausrichtung kommen dann Grundsätze wie "Ich 
programmiere nicht auf Registerebene" oder "Hardware lebt und sie ist 
böse" - also das finale Unverständnis all dessen, was man anzufassen 
gedenkt.

Fazit: Den Studenten beizubringen, was programmierbare Logik ist, wie 
man sie verwendet und was man damit alles machen kann, halte ich für 
ausgesprochen wichtig. So etwas auf eine Programmiersprache oder eine 
spezielle Hardware einzuengen, halte ich hingegen für grundfalsch. So 
etwas erinnert mich an den Informatikunterricht in der Schule, wo 
Lehrer, denen sowas aufgebrummt wurde, sich nur damit zu helfen wußte, 
daß sie den Schülern das Benutzen von Word, Excel und Konsorten erklären 
wollten.

W.S.

von Markus F. (mfro)


Lesenswert?

W.S. schrieb:
> Den Studenten beizubringen,

Dann mach' das. Sehr sinnvoll.

Sinnvoller jedenfalls, als das 1000undeinste Mal darüber zu 
philosophieren, ob VHDL nun eine Programmiersprache ist oder nicht 
(natürlich ist es das). Das wurde hier nun wirklich schon oft und 
engagiert genug durchgekaut.

von M.A. S. (mse2)


Lesenswert?

W.S. schrieb:
> Fazit: Den Studenten beizubringen, was programmierbare Logik ist, wie
> man sie verwendet und was man damit alles machen kann, halte ich für
> ausgesprochen wichtig. So etwas auf eine Programmiersprache oder eine
> spezielle Hardware einzuengen, halte ich hingegen für grundfalsch.
Ist ja irgendwie richtig und sinnvoll, was Du schreibst.
Aber sag: wie soll die Lehre vorgehen, OHNE eine bestimmte Hardware 
herzunehmen und diese mit einer bestimmten Sprache wie z.B. VHDL zu 
beackern?

von W.S. (Gast)


Lesenswert?

M.A. S. schrieb:
> Aber sag: wie soll die Lehre vorgehen, OHNE eine bestimmte Hardware
> herzunehmen und diese mit einer bestimmten Sprache wie z.B. VHDL zu
> beackern?

Ich bin nicht derjenige, der Lehrpläne macht. Ich hab auch keine 
Professur, bin also weder Lehrer noch werde ich dafür bezahlt. Von daher 
bin ich die falsche Adresse für deine Frage.

Allerdings gehört als Grundlagenwissen dazu, daß man weiß, wie die 
Hardware normalerweise funktioniert - Erfindungen, die noch nicht 
gemacht sind, könnten das ändern.

Und die Unterschiede zwischen LUT und AND/OR-Makrozelle benötigen keine 
spezielle Programmiersprache, sie bewirken aber, daß manche Dinge auf 
einer Hardware besser zu machen sind als auf einer anderen. Das als nur 
ein kleines Beispiel dafür, daß es weitaus mehr gibt, als nur eine 
Programmiersprache und deren Sprachelemente. Das Ganze ist - mal 
bildlich gesagt - sowas wie ein Grenzgebiet zwischen 
Digitalschaltungstechnik, Mathematik und noch weiteren Fachgebieten. Und 
du würdest ja bei digitaler Schaltungstechnik auch nicht fragen wie die 
Lehre vorgehen sollte, OHNE Standard-TTL oder CMOS herzunehmen. Oder? 
OK, man kann mit dem 7400 anfangen, aber ob das die rechte Didaktik 
ist, wage ich hier zu bezweifeln.

W.S.

von Georg A. (georga)


Lesenswert?

W.S. schrieb:
> Und die Unterschiede zwischen LUT und AND/OR-Makrozelle benötigen keine
> spezielle Programmiersprache, sie bewirken aber, daß manche Dinge auf
> einer Hardware besser zu machen sind als auf einer anderen. Das als nur
> ein kleines Beispiel dafür, daß es weitaus mehr gibt, als nur eine
> Programmiersprache und deren Sprachelemente. Das Ganze ist - mal
> bildlich gesagt - sowas wie ein Grenzgebiet zwischen
> Digitalschaltungstechnik, Mathematik und noch weiteren Fachgebieten. Und
> du würdest ja bei digitaler Schaltungstechnik auch nicht fragen wie die
> Lehre vorgehen sollte, OHNE Standard-TTL oder CMOS herzunehmen. Oder?
> OK, man kann mit dem 7400 anfangen, aber ob das die rechte Didaktik
> ist, wage ich hier zu bezweifeln.

Ich habe gute 16 Jahre für Info-Erstsemester den Teil für Technische 
Grundlagen gemacht. Da gab es zuerst Assembler, dann Mikroprogrammierung 
und am Schluss dann Logik+VHDL. In der Haupt-Info-Vorlesung gabs immer 
irgendeine Hochsprache (Java, etc) und damit die Grundlagen von 
Programm&Datenstrukturen.

Dazu passt Assembler parallel ganz gut, weil man da sieht, wie simple 
Sprachkonstrukte umgesetzt werden können und wie man überhaupt mit dem 
Speicher so "umgeht" (...und wieder zu den Datenstrukturen kommt...). 
Danach Mikroprogrammierung, um das parallele Denken in "dedicated" 
Funktionseinheiten und Datenflusssteuerung zu üben. Das hat die Studis 
immer am meisten gestresst, wobei es eigentlich total simpel ist, wenn 
man mal das Grundprinzip verstanden hat.

Und dann als "finalen Zoom" die Betrachtung, wie das eigentlich real 
ganz unten umgesetzt wird, also boolsche Logik AND/OR/NOT, 
Grundbausteine (En/Coder, Multiplexer, FFs). Da gings aber immer 
gleichzeitig auch um eine BESCHREIBUNG dieser Elemente, also welche 
IOs gibt es, welche Datentypen (nicht nur dumme Einzelbits, sondern auch 
Vektoren bzw. Zahlinterpretationen), welche Funktionen machen die Dinger 
(Abstrahierung vom AND/OR/NOT-Gattergrab zu einer besser lesbaren 
Beschreibung in VHDL), welche Hierarchiestrukturen gibt es etc.

Einige Aufgaben aus Assembler und VHDL waren effektiv gleich, zB. 
Dekodierung einer Binärzahl für eine 7Segment-Anzeige. Da kann man dann 
auch mal das Datenblatt eines 74LS48 zeigen und dessen Gatterdarstellung 
mit der VHDL-Beschreibung vergleichen.

Und am Ende gabs dann Automaten, womit wieder der Kreis zu 
Mikroprogrammierung/Assembler geschlagen wurde, also wie kann man man 
variable/"reaktive" zeitliche Abläufe beschreiben. Und da wird es mit 
VHDL im Gegensatz zum Gattergrab doch um einiges übersichtlicher.

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


Lesenswert?

W.S. schrieb:
> Allerdings habe ich den Verdacht, daß da der Lothar schlechte Laune
> kriegt.
Inzwischen ist es mir egal. Der Student, den ich betreue, zeigt mir sein 
"VHDL-Programm" und ich sage ihm, er müsse seine "VHDL-Beschreibung" 
nochmal stellenweise überarbeiten und dass er sich von der prozeduralen 
Denkweise ihm bekannter Programmiersprachen lösen müsse.

Yalu X. schrieb:
> stände das "D" vermutlich eher für "Design" oder "Development".
> Wie würdest du einen Menschen nennen, der einem FPGA Leben einhaucht
> (meinetwegen auch auch Englisch)?
"FPGA designer" oder "FPGA developer" wären durchaus plausibel statt 
"FPGA programmer".  Auf deutschen Jobportalen findet man "FPGA 
Entwickler" wenn man "FPGA Programmierer" sucht.

: Bearbeitet durch Moderator
von J. S. (engineer) Benutzerseite


Lesenswert?

Gerd schrieb:
> Wir hatten gestern eine Diskussion im kleinen Kreis:
Das ist das Problem, dass dort irgendwer seine Meinung dominant 
reinbringt.

Man muss das nicht im "kleinen Kreis" diskutieren, sondern darf es auf 
Wikipedia machlesen. Ich persönlich habe mich seinerzeit - auch aufgrund 
der Diskussionen hier- mit anderen Editoren im Fachforum Elektro 
unterhalten und wir haben uns auf die Formulierung in der WP in der 
heutigen Fassung geeinigt.

Dabei wurde herausgestellt, was das Wort Programmieren bedeutet. Das ist 
auch industrieweit inzwischen Konsens.

> es wäre hilfreich,
> die Terminologie "konfigurieren" statt "programmieren" bei FPGAs zu
> verwenden.
Das löst das Problem der Dualität des Wortes "Programmieren" nicht und 
überdies auch nicht die des Wortes "Schaltung", der du hier leider 
aufsitzt:

> Es wird nämlich eine Schaltung im FPGA konfiguiert.
Nein, es werden Schaltelemente konfiguriert, sodass eine Verschaltung 
entsteht, welche dann eine Funktion hat, die der Schaltung entspricht, 
die wir als Logikschaltung kennen und als Netzliste angezeigt wird.

> Das führt zu deutlich weniger Verwirrung bei den Studenten.
Nein, nur die unsaubere Sprache mancher Lehrenden :-)

> Mittels VHDL wird eine "Fuse-List" erzeugt.
Das ist leider überhaupt nicht verdeutlichend und zudem formell und auch 
logisch falsch!

Mit VHDL wird eine Struktur einer Schaltung, oder die Funktion einer 
Schaltung beschrieben - oder beides gleichzeitig. Das war es.

Diese Schaltung existiert aber nirgends. Sie existiert später virtuell 
in Form der o.g. Elemente deren Funktion dasselbe macht, wie die 
beschriebene Schaltung.

Es wird auch keine Fuse-List erzeugt. In FPGAs ist das Allermeiste 
S_RAM-basiert und damit reversibel.

> Durch die gesetzten Verbindungen ist dann das FPGA so konfiguriert, dass
> die gewünschte Schaltung entsteht.
Der Satz ist korrekt.

Es fehlt aber das Wichtigste: Nämlich dass durch das VHDL + TCL + 
Test-Constraints und weitere Einstellungen die Synthesesoftware 
programmiert wird. Das VHDL ist ein Programm für die Synthese (die 
Implementierung rechnen wir mal rein). Teile des VHDLs sowie andere 
Vorgaben sind Programme = lat "Vorschriften" für den Autorouter.

DAS muss den Studenten klargemacht werden. Das VHDL programmiert einen 
virtuellen Ingenieur, der Schaltungen aus Logigzellen zusammenbaut und 
sie im FPGA verteilt.

Und all die, die mal so angefangen haben, mit Gates zu bauen und/oder 
diese in TTL genutzt haben, wissen was gemeint ist.

von J. S. (engineer) Benutzerseite


Lesenswert?

Yalu X. schrieb:
> Aber selbst "Hardware Design Language" wäre beim Einsatz für FPGAs nicht
> sehr treffend, denn es wird damit ja keine Hardware entwickelt. Die
> Hardware existiert bereits in Form des FPGAs und hat sogar schon eine
> Beschreibung, nämlich in Form des Datenblatts.

Leider vermischst nun auch du "Schaltung" und "Schaltung", nämlich die 
Zielelektronik und die FPGA-Elektronik.

1) Was wir programmieren, ist die Software und damit indirekt die 
Schaltelemente. Ich würde daher den FPGA nicht als "Schaltung" 
bezeichnen, sondern eben als Array von Elementen, wie der Name es ja 
suggeriert.

2) Was wir haben wollen ist "unsere" Zielschaltung. Dies wird in der Tat 
"beschrieben". Daher ist der Hinweis auf HW-"Beschreibung" korrekt. Er 
steht aber nicht im Gegensatz zum Programmieren, wie immer wieder 
angeführt wird, weil sich dieser Begriff auf die Software und die Gates, 
also Punkt 1 bezieht. Diese werden nicht beschrieben, sondern stehen wie 
du es sagst, im Datenblatt.

Das muss man auseinander halten. Ich denke, dass das für Leute, die 
Logikschaltungen bauen wollen, möglich sein sollte. :-)

Um es nochmal auf den Punkt zu bringen:

Wir wollen eine Zielschaltung, die wir aber nicht bauen können, weil wir 
nur einen pool rudimentärerer programmierbarer Gates und Speicher haben. 
Wir zerlegen daher also unsere Schaltung in kleine Teile und 
programmieren die Gates per Hand, wir wir es 1990 gemacht haben. Oder 
wir nehmen eine Beschreibungssprache und programmieren damit eine 
Software, die das für uns tut.

von Wühlhase (Gast)


Lesenswert?

Jürgen S. schrieb:
> Nein, nur die unsaubere Sprache mancher Lehrenden

Pff....schwafelt über unsaubere Sprache und kommt dann mit sowas daher.

von J. S. (engineer) Benutzerseite


Lesenswert?

Wühlhase schrieb:
> Pff....schwafelt über unsaubere Sprache und kommt dann mit sowas daher.

Was hast du denn nicht verstanden?

Yalu X. schrieb:
> Na ja, describen oder beschreiben tut man ja üblicherweise etwas, was
> schon existiert, der FPGA-Programmierer, -Konfigurator (oder wie immer
> man ihn nennen mag) schafft aber in der Regel etwas Neues.

Ich sehe da keinen Gegensatz: Beschrieben wird die Zielschaltung (die im 
Kopf des Designers existiert) und der "Programmierer" lässt es 
erschaffen. Man darf sich eben nicht daran stören, dass der gesamte 
Entwicklungsprozess Schaltung zerlegen, Gates aussuchen, zusammenlöten 
von einer Software gemacht wird - es ist faktisch die gleiche 
Komplexität.

Lothar M. schrieb:
> "FPGA designer" oder "FPGA developer" wären durchaus plausibel statt
> "FPGA programmer".
Die sind alle drei ungenau, da am FPGA direkt nichts gemacht wird, weder 
programmiert noch designed. Ein FPGA-Designer ist streng genommen der 
Entwickler, der bei XI sitzt und sie baut.

Was man dringend unterscheiden muss, wäre die Anforderung im 
FPGA-Umfeld, wenn es um die Software geht, die darin laufen soll:

Also z.B. so:

- "C++ Entwickler für Linux-Systeme in SoCs"
- "C-Entwickler für Software in FPGA und SoCs"
- "VHDL-Entwickler für FPGAs und SoCs"
- "Schaltungs-Entwickler für Elektronik mit FPGAs"

von Yalu X. (yalu) (Moderator)


Lesenswert?

Lothar M. schrieb:
> Yalu X. schrieb:
>> stände das "D" vermutlich eher für "Design" oder "Development".
>> Wie würdest du einen Menschen nennen, der einem FPGA Leben einhaucht
>> (meinetwegen auch auch Englisch)?
> "FPGA designer" oder "FPGA developer" wären durchaus plausibel statt
> "FPGA programmer".  Auf deutschen Jobportalen findet man "FPGA
> Entwickler" wenn man "FPGA Programmierer" sucht.

Diese Begriffe sind sicher nicht ganz verkehrt, nur denke ich dabei eher
an die Jungs von Xilinx, die dort die FPGA-Chips entwickeln.

Jürgen S. schrieb:
> Yalu X. schrieb:
>> Aber selbst "Hardware Design Language" wäre beim Einsatz für FPGAs nicht
>> sehr treffend, denn es wird damit ja keine Hardware entwickelt. Die
>> Hardware existiert bereits in Form des FPGAs und hat sogar schon eine
>> Beschreibung, nämlich in Form des Datenblatts.
>
> Leider vermischst nun auch du "Schaltung" und "Schaltung", nämlich die
> Zielelektronik und die FPGA-Elektronik.

Ich habe das Wort "Schaltung" hier doch überhaupt nicht benutzt, und das
sogar mit Absicht, um genau die von dir angesprochene Mehrdeutigkeit zu
vermeiden. Stattdessen schrieb ich von "Hardware" und "Konfiguration",
womit der Unterschied IMHO deutlicher herausgestellt wird.

von J. S. (engineer) Benutzerseite


Lesenswert?

Yalu X. schrieb:
> ch habe das Wort "Schaltung" hier doch überhaupt nicht benutzt,

Du stellst aber heraus, dass HW-DescriptionLanguage und sogar 
HW-DesignLanguage nicht passen sollen und führst dazu an, dass die "HW" 
schon existiert - fokussierst also mit dem Begriff "hardware" die Gates 
im FPGA.

Das ist der Verwechsler! Allgemein verstehen wir unter der "Schaltung", 
die beschrieben wird, eben jene, die wir haben wollen. Das wollte ich 
herausstreichen.

@all:  Deshalb passt auch der Begriff "FPGA-Designer" nicht. Der FPGA 
wird nicht designed. Er wird auch nicht programmiert und er wird auch 
nicht beschrieben. (Jedenfalls nicht vom Mensch - beschrieben und 
programmiert wird er vom USB-Programmer).

Entwickelt wird die Schaltungsbeschreibung in Form eines Schaltplans, 
oder das C oder das VHDL für die Funktion.

Ich habe das Thema ja regelmäßig bei den Projektausschreibungen und 
sogar die Verantwortlichen im Einkauf sind nicht in der Lage, korrekt zu 
formulieren, was sie wollen und haben eine noch ungenauere 
Ausdrucksweise, als der Anforderer in der Abteilung. Über das, was die 
BWL-studierten Vermittler davon weitergeben, sage ich jetzt mal lieber 
überhaupt nichts. :-)

von Andi F. (chefdesigner)


Lesenswert?

Dergute W. schrieb:
> Unn? Komm ich getz in Fernsehen?
> https://de.wikipedia.org/wiki/Piet_(Programmiersprache)
Oha, kannte ich noch gar nicht.

LABVIEW nennt sich auch "grafische Programmierpsrache" und kann glaube 
ich auch FPGA.

von Gerd (Gast)


Lesenswert?

>LABVIEW nennt sich auch "grafische Programmierpsrache" und kann glaube
>ich auch FPGA.

Stimmt, so ist es:
https://www.ni.com/de-ch/shop/electronic-test-instrumentation/add-ons-for-electronic-test-and-instrumentation/what-is-labview-fpga-module.html

von Mcn (Gast)


Lesenswert?

Jürgen S. schrieb:

> @all:  Deshalb passt auch der Begriff "FPGA-Designer" nicht. Der FPGA
> wird nicht designed. Er wird auch nicht programmiert und er wird auch
> nicht beschrieben. (Jedenfalls nicht vom Mensch - beschrieben und
> programmiert wird er vom USB-Programmer).

Es wird ein Design mit einem FPGA erstellt - also passt der Begriff 
FPGA-Designer mindestens ungangsprachlich. Auch wenn der FPGA als IC 
nicht von "FPGA-Entwickler" gemacht wird, das macht der "Chipdesigner". 
Exakter passt FPGA-HW-designer, aber da winken auch viele ab, weil sie 
Hardware-Design mit reinem PCB-Design (Schematic-Entry und Layout) 
verwechseln.

Manchmal ist es auch eine Frage der Größe der Entwicklungsabzeilung(en). 
Bei Firmen mit schlankes, Produktzentrierte Entwicklung können schon mal 
wenige Mitarbeiter alle Schritte in der Geräteentwicklung, bei Konzernen 
dagegen macht eine sein Leben lang den Papierkram (datenblattpflege, 
Zertifikate "abheften) ein Leben lang ohne  sich mit den anderen 99.5% 
der Entwicklungs-KnowHow konfrontiert zu werden.

Übrigens hatte man das Problem der genauen Job-Beschreibung zwischen den 
Abteilungen in einer Computerbude schon in den Achtziger. Bil Herd, der 
Chefentwickler bei Commodore für den C128, bevorzugte seinen 
Arbeitsplatz unter den Chipdesignern, obwohl auch als 
Firmware-Programmierer tätig war.

https://youtu.be/-Zpv6u5vCJ4?t=677
https://www.c64-wiki.de/wiki/Bil_Herd

von Duke Scarring (Gast)


Lesenswert?

Yalu X. schrieb:
> Was mit VHDL entwickelt
> wird, ist in diesem Fall keine Hardware, sondern eine Konfiguration für
> die bereits bestehende Hardware.
Na dann haben wir es doch: HCL - Hardware Configuration Language ;-)

> Wie würdest du einen Menschen nennen, der einem FPGA Leben einhaucht
> (meinetwegen auch auch Englisch)?
Wenn das FPGA aus Lehm wäre, käme der Rabbi Löw in Frage...

Duke

von W.S. (Gast)


Lesenswert?

Jürgen S. schrieb:
> @all:  Deshalb passt auch der Begriff "FPGA-Designer" nicht. Der FPGA
> wird nicht designed. Er wird auch nicht programmiert und er wird auch
> nicht beschrieben. (Jedenfalls nicht vom Mensch - beschrieben und
> programmiert wird er vom USB-Programmer).

Also, ich hab da eher den Eindruck, daß du dich gegen das Wort 
"Programmierer" sträubst wie die Zicke am Strick.

Programmierbare Logik ist mehr als nur ein FPGA. Und programmiert werden 
alle Sorten von programmierbarer Logik. Da gibt es keine 
Mehrdeutigkeiten.

Allerdings wird das Wort "Programmieren" von den Leuten auch anderweitig 
benutzt, was aber hier nicht stört, da irrelevant.

Programmieren heißt im grundlegenden Sinne, seinem Willen einen Ausdruck 
geben, also "ich will, daß das Ding so funktioniert, wie ich es mir 
vorgestellt habe". Und dabei das ist völlig egal, ob es rein technisch 
dann durch eine passende Verschaltung von irgendwas oder durch eine 
Turing-Maschine realisiert wird.

W.S.

von Falk B. (falk)


Lesenswert?

Die gescheiterten Germanisten beim Philosophieren, ach wie süß . . .

von Andi F. (chefdesigner)


Lesenswert?

Falk B. schrieb:
> Die gescheiterten Germanisten beim Philosophieren, ach wie süß .
Wenn ich deine Beiträge so lese, hast du dich mit der Bemerkung auch und 
vor allem selbst miteingeschlossen. :-)

Meine Haltung dazu:

Da es um "FPGAs in der Lehre" zu gehen scheint, sollte sich die 
Lehrkraft, wer auch immer sich dafür hält, einer exakten Ausdrucksweise 
befleissigen. Alles, was der Lehrer verbockt, überträgt sich auf die 
Schüler. Eigene Philosphien sollte man da auch tunlichst zur Seite 
lassen.

Mcn schrieb:
> Es wird ein Design mit einem FPGA erstellt - also passt der Begriff
> FPGA-Designer mindestens ungangsprachlich.

Es wird ein Design FÜR einen FPGA erstellt. Das Design MIT dem FPGA ist 
ein Schematic. Also Elektronik! Da sind wir in meiner Domäne :-)

Ich versuche es einmal mit Logik:

Ein Schaltplandesigner baut einen Schaltplan.
Ein Softwaredesigner baut eine Software.
Ein FPGA-Designer baut aber KEINEN FPGA.

Finde den Fehler :-)

Der FPGA-Mann baut eine Software für einen FPGA. In unserer Abteilung 
heissen die Leutz "FPGA-Entwickler" (was also unrichtig wäre). Sie 
gehören aber richtigerweise zur Softwareabteilung. Hab ich aber auch 
schon anders gesehen. Die Argumentation war: Ein FPGA ist Hardware, 
deshalb ist alles, was FPGA angeht, auch Harware. Meine 
Gegenargumentation war: Ein Computer ist auch Hardware.

Finde die Logik!

von Christoph Z. (christophz)


Lesenswert?

Andreas F. schrieb:
> Sie
> gehören aber richtigerweise zur Softwareabteilung. Hab ich aber auch
> schon anders gesehen. Die Argumentation war: Ein FPGA ist Hardware,
> deshalb ist alles, was FPGA angeht, auch Harware. Meine
> Gegenargumentation war: Ein Computer ist auch Hardware.

Mein "Lösung" in der letzten Firma war:
- Ich hatte meinen Arbeitsplatz in der Embedded Software Gruppe, mit SVN 
Zugang und Oszilloskop
- Auf meiner Visitenkarte Stand "HW/SW Engineer"
- Ich war immer Schuld :-)

von Andi F. (chefdesigner)


Lesenswert?

Yalu X. schrieb:
> Jeder, der die Vorlesung über Programmierparadigmen nicht geschwänzt
> hat, weiß dann, dass ihm seine Programmiererfahrung in C++ oder Python
> bei der Arbeit mit FPGAs gar nichts nützt

Es ist aber schon bekannt, dass

- in jedem zweiten FPGA ein SoftCore steckt, der C-Software fordert
- in jedem fünften FPGA ein Hardcore steckt, der C-Software erfordert
- in jedem zehnten FPGA ein Betriebssystem steckt, das sogar C++ 
erfordert

Das ist eine ganze Menge Software finde ich, die bei
"der Arbeit mit FPGAs" zur Anwendung kommt.


Das hier ist der bisher stärkste Beitrag:

Dussel schrieb:
> Aber die Diskussion ist schon richtig. Ohmsches Gesetz und
> Kondensatorladekurve habe ich in meiner beruflichen Laufbahn nie
> gebraucht.

Interessant! Ohm und C-ladezeiten / Dämpfung braucht ein Ingenieur 
nicht.
Welche Hochschule / welcher Studiengang ist das bitte?

'B'asis 'W'issen für 'L'uschen?

> von Maxwellschen Gleichungen kann man Studenten auch nicht
> überzeugen, weil sie von Studenten (und vielen Profis) nur für
> unrealistische Spezialfälle lösbar sind. Das sollte alles nicht mehr
> unterrichtet werden.

Soso!

von Georg A. (georga)


Lesenswert?

Mei, die Begrifflichkeiten sind halt nicht so einfach, erst recht, weil 
nativ ja alles in Englisch ist. Gibt ja auch Zitronenfalter und 
Zitronenkuchen...

Mit "Beschreibung" kann man zumindest die gewisse Andersartigkeit 
gegenüber normaler SW-Entwicklung hervorheben. Das hat nichts mit 
elitärem Denken oder so zu tun. Ich habs ja oft genug gesehen, wie an 
sich gute Studenten zumindest am Anfang mit VHDL+FPGA auch etwas 
gestrauchelt sind. Irgendwann machts dann Klick...

Andreas F. schrieb:
> Der FPGA-Mann baut eine Software für einen FPGA. In unserer Abteilung
> heissen die Leutz "FPGA-Entwickler" (was also unrichtig wäre). Sie
> gehören aber richtigerweise zur Softwareabteilung. Hab ich aber auch
> schon anders gesehen. Die Argumentation war: Ein FPGA ist Hardware,
> deshalb ist alles, was FPGA angeht, auch Harware. Meine
> Gegenargumentation war: Ein Computer ist auch Hardware.
>
> Finde die Logik!

Ich habe von einer grösseren Firmen im Space-Sektor gehört, dass sie 
immer versucht haben, den VHDL/FPGA-Teil als HW zu verkaufen, weil da 
wohl deutlich weniger Test&Zertifizierungsaufwand vorgeschrieben war...

von Falk B. (falk)


Lesenswert?

Georg A. schrieb:
> Mei, die Begrifflichkeiten sind halt nicht so einfach, erst recht, weil
> nativ ja alles in Englisch ist. Gibt ja auch Zitronenfalter und
> Zitronenkuchen...

Babyöl, Kinderdöner  . . . ;-)

von Wühlhase (Gast)


Lesenswert?

Jürgen S. schrieb:
> Wühlhase schrieb:
>> Pff....schwafelt über unsaubere Sprache und kommt dann mit sowas daher.
>
> Was hast du denn nicht verstanden?

Ich habe schon verstanden was er sage wollte. Und um dir auf die Sprünge 
zu helfen: Mache dir mal den Unterschied zwischen einem Lehrer und einem 
Lehrenden klar.

von W.S. (Gast)


Lesenswert?

Georg A. schrieb:
> Mit "Beschreibung" kann man zumindest die gewisse Andersartigkeit
> gegenüber normaler SW-Entwicklung hervorheben. Das hat nichts mit
> elitärem Denken oder so zu tun. Ich habs ja oft genug gesehen, wie an
> sich gute Studenten zumindest am Anfang mit VHDL+FPGA auch etwas
> gestrauchelt sind.

Wenn es dir so wichtig ist, die Andersartigkeit durch die Namensgebung 
zu betonen, dann ist das zum einen sehr wohl ein unangebrachtes elitäres 
Denken und zum anderen eine schlechte Lehre. Da wundert es mich nicht, 
wenn ansonsten gute Studenten damit ihre Probleme haben. Nun, sie haben 
offenbar selbst (und ohne dich) die Sache gelernt.

Es wird - zumindest mir - immer klarer, daß es bei Leuten, die das 
Programmieren von programmierbarer Logik lehren sollen, zuviel an 
eigenen Befindlichkeiten gibt und die didaktischen Fähigkeiten dagegen 
eher zu gering ausgebildet sind. Das hat es auch in anderen Sparten 
gegeben. Heinrich Hertz zum Beispiel war kein guter Lehrer, er wußte das 
und er litt darunter.

Also an diejenigen, die in der Lehre arbeiten: Verbessert die Lehre so 
ihr könnt. Es ist nicht immer alles auf die Begriffsstutzigkeit der 
Studenten abzuwälzen.

Und Eitelkeitsthemen wie das Erfinden von großartigeren Namen für eine 
Programmiersprache, um sich von anderen Programmierern abzuheben und 
"die Andersartigkeit gegenüber normaler SW-Entwicklung" zu betonen, sind 
nicht nur unnütz, sie schaden der Sache mehr als man glaubt.

W.S.

von J. S. (engineer) Benutzerseite


Lesenswert?

W.S. schrieb:
> Also, ich hab da eher den Eindruck, daß du dich gegen das Wort
> "Programmierer" sträubst

???
Ganz im Gegenteil. Ich schreibe ja ausdrücklich, dass vor allem ich den 
Terminus "Programmieren" im WIKI Artikel durchgedrückt und präzisiert 
habe:
Beitrag "Re: FPGAs in der Lehre - Was ist FPGA-Programmieren"

und auch in den Kontext gestellt habe. Siehe auch hier:
Beitrag "Re: Unterschied HDL-Programm und C-Programm"

Dazu passt:

Andreas F. schrieb:
> - in jedem zehnten FPGA ein Betriebssystem steckt, das sogar C++
> erfordert
"in jedem größeren FPGA-Design ein Core steckt, der mit C konfiguriert 
wird" könnte man noch sagen, weshalb der MicroBlaze und seine Freunde 
überhaupt erst ins Spiel kommen.

Und es gibt noch mehr Gründe:

Ich habe auch lange keine großen Anwendungen für den Blaze gesehen, bis 
ich mal eine Config-State-Machine für einen DVI-Chip gebraucht habe. 
"Hol was aus dem RAM, vergleiche es mit dem User-Setup, plausibilisiere 
es mit dem Gerätestatus und schreibe es in die Register und finde raus, 
welche Register noch gesetzt werden müssen". Das ist in C nicht nur 
einfacher hinzupinnen, sondern auch erheblich resourcenschonender als in 
einer 150MHz FSM. Das gleiche Spiel gab es später bei einem Ethernet-MAC 
und den HDMI-Chips.

Auch der FPGA, der eigentlich keinen SoftCore braucht, muss in C 
"programmiert" werden, damit er mit der Hardware, die sonst noch auf dem 
PCB sitzt, sinnvoll reden kann.

Die Software für den Umgang mit FPGAs ist aber noch viel breiter: Es ist 
heute normal und gebräuchlich, dass:

- C für die Erzeugung von Code benutzt wird
- C für die Konfiguration von Cores benutzt wird

- C++ für die Erzeugung von parallelem Code benutzt wird

- Python für die Erzeugung von Code benutzt wird
- Python für die Erzeugung von Scripten genutzt wird
- Python für die Verifikaton benutzt wird

- System-C für Verifikation genutzt wird

Hinzu kommt, dass  für Sonderlösungen in FPGAs oftmals Strukturen aus 
C++ und den Betriebssystemen entliehen werden, seien es message pipes, 
Interprozesskommunikation mit Semaphoren und nicht zuletzt die 
Verwaltung mehrdimensionaler Datenstrukturen.

von J. S. (engineer) Benutzerseite


Lesenswert?

Georg A. schrieb:
> Ich habe von einer grösseren Firmen im Space-Sektor gehört, dass sie
> immer versucht haben, den VHDL/FPGA-Teil als HW zu verkaufen, weil da
> wohl deutlich weniger Test&Zertifizierungsaufwand vorgeschrieben war...

Ja und das gibt es nicht nur in der AER und DEF sondern auch in der MED. 
Eines meiner ersten Projekte im FPGA-Bereich war die Übersetzung einer 
FSM mit 600 states in VHDL, um die umfangreiche SW-Verifikation zu 
vermeiden.

Damals ging das (noch).

Interessant ist:

Betrachtet man das genauer, kann es sein, dass durch die sehr komplexe 
Logik die Vulnerabilität des Systems sogar wächst. Hängt am Ende von der 
Implentierung ab. Eine normale FSM unterliegt z.b. einer steuerbarer 
FSM, die aus einem FPGA-BRAM kontrolliert wird. Besser ist aber wieder 
eine one hot FSM, die jedoch wieder größer, dafür aber schneller ist. 
Ganz schlecht sind umfangreiche FSMs mit vielen waits und Verzweigungen, 
die konventionell codiert sind. Auch SoftCores sind anfällig, weil sie 
im Vergleich zur Leistung viel tun- und schieben müssen: Ein externer 
Mikrocontroller mit redundantem RAM-Bereich aus einem SRAM ist aus 
FMEA-Sicht mit wenig Aufwand sicherer zu machen. Sehr viel sicher sogar!

Beitrag #7253528 wurde von einem Moderator gelöscht.
von studi, ehemaliger (Gast)


Lesenswert?

Falk B. schrieb:
> Babyöl, Kinderdöner  . . . ;-)

Seniorenschnitzel


@W.S.:
Was eine (Programmier)Sprache ist, ist seit den 1950ern definiert. Du 
möchtest dazu Vorlesungsunterlagen (Grund- bzw. Bachelorniveau) einer 
beliebigen Uni konsultieren (evtl. auch Gymnasium, abhängig davon wie 
fit der/die Informatik-Lehrer/in ist). Es könnten dir die Zeichen L(G), 
G, L*, Sigma, N, und P und dergleichen begegnen.

Natürlich gibt es graphische Programmiersprachen. Oder welche, die mit 
farbigen Feldern arbeiten (Piet, echt lustig. Danke dafür.). Oder mit 
whitespaces.

@Georg A.:
Kann mich noch gut an den Kurs erinnern.
Habe damals zwar kein Großpraktikum gemacht, aber aus Spaß an der Freude 
den UART aus unserer Aufgabe auf nem Xilinx CPLD gebaut :-)

von Nachschlag um Mitternacht (Gast)


Lesenswert?

studi, ehemaliger schrieb:
> Was eine (Programmier)Sprache ist, ist seit den 1950ern definiert.
was aber noch lange nichts über die Sprachen aussagt, die danach 
erfunden wurden. Sieht man sich die Geschichte der Programmierung von 
Bausteinen an, dann wird evident, dass die ersten mit einer Sprache 
definiert wurden, die dem Text von SPICE ähnelt. Das waren UND und ODER 
Konstruktionen und lief auf eine Formelsprache hinaus, die so aufgebaut 
war, wie die Gleichungen bei einem Taschenrechner.

Alle diese Geräte (Taschenrechner, Videorekorder, Spülmaschine inklusive 
dem Fernseher) werden "programmiert". Beim einem sind es nur Befehle, 
bei anderen eine ganze Sequenz. Wenn die Sequenzen komplizierter sind, 
entsteht eine Sprache. Kennt jemand HPGL? Das ist auch so eine 
Beschreibung von Grafik, die von einem Interpreter als Kommandosequenz 
aufgefasst wird.

Ich sehe keinen Grund, warum der Vorgang, einen programmierbaren 
Baustein zu konfigurieren nicht als "programmieren" deklariert werden 
kann oder soll. Auch der Videorekorder wird in dem Sinne nur 
konfiguriert, aber dennoch nennt es die halbe Welt "Programmierung".

von Mcn (Gast)


Lesenswert?

W.S. schrieb:

> Programmieren heißt im grundlegenden Sinne, seinem Willen einen Ausdruck
> geben, also "ich will, daß das Ding so funktioniert, wie ich es mir
> vorgestellt habe".

Nö, das ist die Definition für "infantiler Trotzkopf".

https://de.wikipedia.org/wiki/Trotz
--
> Ich versuche es einmal mit Logik:

> Ein Schaltplandesigner baut einen Schaltplan.
> Ein Softwaredesigner baut eine Software.
> Ein FPGA-Designer baut aber KEINEN FPGA.

Das ist keine Logik, da ist billige Polemik.

Wenn du Logisch argumentieren willst, musst du erst die Unterschiede 
zwischen FPGA und IC wie µC analysieren.
Ein FPGA ist wie jedes Gate Array ein Halbzeug, aber kein 100% fertiges 
und damit einsetzbares Endprodukt.

Zur "Endfertigung" durchläuft ein Gate-Array (nach erster 
Auslieferung/Einlagerung) weitere Fertigungsschritte, bei denen die 
eigentliche Funktionalität eingebracht aka programmiert wird.

Das kann entweder durch Prozessierung von Metallisierungslagen geschehen 
oder eben beim FPGA durch ein "Programming in Field" ("in field" ... vor 
Ort, nicht in der Fab, sondern beim Kunden, siehe "Customizing") also 
eben Aktivierung einer elektrisch veränderbaren Verdrahtungsmatrix durch 
Download des Bitstreams. Und diesen Bitstream erstellt eben der 
FPGA-designer und schliesst eben so die Herstellung eines FPGA-Designs 
ab.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Mcn schrieb:
> Wenn du Logisch argumentieren willst, musst du erst die Unterschiede
> zwischen FPGA und IC wie µC analysieren.
> Ein FPGA ist wie jedes Gate Array ein Halbzeug, aber kein einsetzbares
> Endprodukt.

Das gilt aber, wie auch deine nachfolgende Argumentation, genauso für 
Mikrocontroller.

Auch ein Mikrocontroller tut von sich aus zunächst nichts (ist also in 
deiner Sprechweise ein Halbzeug) und wird entweder beim Hersteller 
(maskenprogrammierte Typen) oder "in field" (Flash-programmierbare 
Typen) mit einer Folge von Bits programmiert.

von Mcn (Gast)


Lesenswert?

Yalu X. schrieb:

> Auch ein Mikrocontroller tut von sich aus zunächst nichts (ist also in
> deiner Sprechweise ein Halbzeug)

Ja kann man so sehen. Programmerstellung ist eben nur ein Schritt bei 
der Geräte-Herstellung und es gibt verschiedene 
Realisierungen/Implementierunegn eines "Programmes". Deshalb muss man 
zur Geräteentwicklung auch mehr mehr Fähigkeiten ausbilden als das das 
"uninspirierte Psalmodieren von (Programmier-)Sprachkonstrukten", man 
sollte die vorhandenen "Werkzeuge, Arbeitsmittel" wie auch die 
Arbeitsfeld des Auftraggebers verstehen.

Das bringt eine auf Eigeninititiative und (Industrie-)Praktika breit 
ausgestellte Lehre wie die Ingenieursausbildung besser zustande als das 
Abspulen irgendwelcher Lernprojekte mit beigestellten Studenten wie es 
an manchen Informatik-Fakultäten zelebriert wird.

von W.S. (Gast)


Lesenswert?

Mcn schrieb:
>> Programmieren heißt im grundlegenden Sinne, seinem Willen einen Ausdruck
>> geben, also "ich will, daß das Ding so funktioniert, wie ich es mir
>> vorgestellt habe".
>
> Nö, das ist die Definition für "infantiler Trotzkopf".

Du hast ne seltsame Art, den Widerspruch zu suchen. Also das was ich 
geschrieben habe, hältst du für falsch? Dann versuche mal das Gegenteil:
"ich will, daß das Ding NICHT so funktioniert, wie ich es mir
vorgestellt habe" - würde dir das besser gefallen?

Das Ganze erinnert mich an einen Spruch von Karl Valentin: Er wurde mal 
vom Autor eines kürzlich aufgeführten Stückes nach seiner Meinung 
gefragt. Seine Antwort: "Ja, es hätte schlechter sein können". Der Autor 
darauf: "Wie können Sie sowas sagen!!" Valentin darauf: "Na gut, dann 
sag ich eben, es hätte NICHT schlechter sein können".

Mcn schrieb:
> Das ist keine Logik, da ist billige Polemik.
> Wenn du Logisch argumentieren willst, musst du erst die Unterschiede
> zwischen FPGA und IC wie µC analysieren.

Mcn schrieb:
> Metallisierungslagen

Merkst du was? Du gleitest immerzu in für die Sache unbedeutende Details 
ab. Was haben Metallisierungslagen oder deine Ansicht über Polemik mit 
der Programmierung zu tun? Natürlich nichts. Allerdings sehe ich hier 
auch, daß manche Leute die Programmierung von Turing-Maschinen mit der 
Verwendung der Programmiersprache C gleichsetzen. Ist auch falsch, denn 
das ist nur eine von vielen Programmiersprachen - auch wenn manche außer 
C nix kennen und können.

W.S.

von Gustl B. (-gb-)


Lesenswert?

Ich finde die Frage ob Programm/Programmieren oder 
Beschreibung/Beschreiben sollte man aufteilen.

Es gibt das Sprachen wie VHDL. Und die Tätigkeit in so einer Sprache 
etwas zu schreiben.

Man beschreibt in dieser Sprache Hardware, weil man aus dem Code eine 
echte Hardwareschaltung erstellen kann. So richtig mit Logikgattern 
diskret aufgebaut.
Andererseits wird die Sprache auch z. B. im Simulator für eine CPU 
übersetzt. Aus der Schaltung wird ein echtes Programm das dann während 
der Simulation auf einer CPU läuft.
Und dann kann die Sprache auch noch viele Sachen die nicht auf Hardware 
abbildbar sind. Das verwendet man in der Testbench und dort kann man 
sich austoben und eher  wie in einer normalen Programmiersprache Code 
schreiben. Der wird dann auch nur in ein Programm für die Simulation 
aber nicht in Hardware übersetzt.
Also ist das schreiben von HDL je nachdem wofür und wie man drauf guckt 
eher Programmieren im C Sinn oder Beschreiben im Schaltplan-Malen-Sinn.

Und dann gibt es noch das FPGA. Das ist ein Stück Hardware das sich nach 
dem vom Hersteller kommt nicht mehr verändert (bis auf Alterung, Fuses, 
...).
Lädt man da einen Bitstream rein, dann ändert sich nur das Verhalten, 
nicht aber die Hardware.
Warum ändert sich das Verhalten? Weil da Bits gesetzt sind die Dinge 
steuern. Also eigentlich genau wie bei einem Atmel. Auch da setzt man 
Bits (im RAM) und danach verhält er sich anders.
Der Unterschied ist aber der Aufbau. Beim Atmel/CPU/SoC ist eine starre 
Funktionalität vorgegeben und im FPGA ist eben auch das Routing zwischen 
den Blöcken konfigurierbar.
Aber dadurch ändert sich nicht der Aufbau im FPGA, das bleiben eben die 
Strukturen die dort schon immer waren. Wenn im HDL ein Addierer aus 
Logikgattern beschrieben wurde, dann wird in das FPGA kein solcher 
Addierer eingebaut. Im FPGA gibt es die Gatter nicht, der Addierer im 
HDL wird also bei der Synthese auf das abgebildet, was im FPGA schon 
vorhanden ist. CLBs/Slices. Der FPGA verhält sich also nach der 
Konfiguration so, als wäre da ein Addierer drinnen, aber da sind eben 
nur LUTs/... drinnen die mit gesetzten Bits an der passenden Stelle wie 
Logikgatter funktionieren.
Das HDL beschreibt also einen Schaltplan der so nie den Weg ins FPGA 
schafft.

Ist der Bitstream dann ein Programm oder eine Konfiguration?
Viele Geräte werden umgangssprachlich programmiert obwohl man dazu auch 
konfigurieren sagen könnte.
Zeitschaltuhr, Waschmaschine, Fernbedienung, ... daher finde ich die 
Unterscheidung sinnfrei. Die Tätigkeit des Programmierens (hier: 
Reinladen vom Bitstream und dann sich so verhalten wie dort kodiert ist) 
hat eben mehrere Bedeutungen.
Und das Programm oder nicht ist auch unscharf.
Wenn im FPGA später eine Soft-CPU sitzt und deren Programm mit im 
Bitstream liegt, tja, was dann? Was wenn beim Atmel viel vom Binary nur 
Daten sind die vom Programm abgefragt werden? Ist das ein Programm wenn 
es von einem Programm (im läuft auf einer CPU Sinn) nur verwendet wird?

Das ist aber alles egal, die Hauptsache ist man sagt genau was man meint 
und alle Beteiligten wissen dann Bescheid.

von Nachschlag vor Mitternacht (Gast)


Lesenswert?

Gustl B. schrieb:
> Man beschreibt in dieser Sprache Hardware, weil man aus dem Code eine
> echte Hardwareschaltung erstellen kann.
> Andererseits wird die Sprache auch z. B. im Simulator für eine CPU
> übersetzt.
Die Hardwaresprache wurde aber zuerst zum Simulieren genutzt und war 
eine reine Programmiersprache für einen Compiler. Als das erfunden und 
genutzt wurde, hat niemand daran gedacht, das zu benutzen um die 
Chipsynthese zu automatisieren. Dass mit dieser Software ein 
Chipverhalten gemeint ist, tut auch nichst zur Sache. Bei einer 
Werkzeugmaschine programmiert der Dreher auch eine Software hinein und 
raus kommt eine Hardware. Und zwar eine sehr harte :-) Ist sein 
Werkzeugprogramm dann eine Hardwarebeschreibungssprache?

Gustl B. schrieb:
> Lädt man da einen Bitstream rein, dann ändert sich nur das Verhalten,
> nicht aber die Hardware.
Mit Hardwarebeschreibung ist nicht die Elektronik im Chip oder FPGA 
gemeint, sondern das "was bei rauskommt", also die klassische 
Fahrstuhlsteuerung. Habt ihr die eigentlich auch gemacht? So ziemlich 
jeden, den ich frage, hat im Chip-Praktikum eine Fahrstuhlsteuerung 
gemacht. :-)

Die haben wir nebenbei gesagt auch in Software erst programmiert.

von J. S. (engineer) Benutzerseite


Lesenswert?

Gustl B. schrieb:
> Ist der Bitstream dann ein Programm oder eine Konfiguration?
Kann man formell beantworten:

[Deutschlehrermodus = ON]
Der Bitstream als Datenfolge auf der Leitung ist ein Programm.
Der Bitstream als file ist eine Konfiguration der Magnetik deiner 
Festplatte. :-)

Eine Konfiguration ist immer ein Zustand und der findet sich später im 
FPGA wieder. Folglich ist ein Bitstrom sowohl als file als auch als 
fliegende Daten eine Konfigurations-ANWEISUNG (Das ist ein Unterschied). 
Eine Anweisung, oder Vorschrift, heißt im lat. "Programm" -> der 
Bitstrom ist definitiv ein Programm!

[Deutschlehrermodus  = OFF]

Machen wir es mal ab Bitfile komplett:

Das Hineinladen ist ein Programmiervorgang: Ein Software (Xilinx 
HW-Manager) nutzt eine andere Software (das Bitfile, das ein mir 
bekannter Schlaumeier immer belehrend "loadware" nannte) um den FPGA zu 
programmieren.  Dabei entsteht - soweit es fabric ist - eine 
Konfiguration im FPGA, die man firmware nennt. Ferner entstehen durch 
die ausgerollten Strukturen der FSMs zwei Dinge, nämlich ein implizites 
Programm und eine Ausführeinheit dafür. Überdies enthält die "loadware" 
explizite Programme, die als Ablaufkommandos in RAMs geladen werden und 
sie enthält Startwerte für die Registerzellen, die den Ablauf beim Start 
im FPGA steuern. Und: Teile der loadware sind reine Software, die als 
compiliertes C in Rams (auch in BRAMs) geschoben wird.

Das Bitfile ist also eine Software, die ausdrückliche 
Konfigurationsanweisungen enthält, welche ihrerseits indirekt 
abstrahierte Abläufe beschreiben können (z.B. akkumulativ arbeitende 
FSMs) die ihrerseits wiederum virtuelle Strukturen beschreiben können 
(Filter).

Gustl B. schrieb:
> Lädt man da einen Bitstream rein, dann ändert sich nur das Verhalten,
> nicht aber die Hardware.
Siehe nächsten Satz:

Gustl B. schrieb:
> Das HDL beschreibt also einen Schaltplan der so nie den Weg ins FPGA
> schafft.
Exakt das streiche ich auch immer wieder heraus! Daher spreche ich auch 
immer von einer virtuellen Schaltung, die im FPGA arbeitet.

Nachschlag vor Mitternacht schrieb:
> Ist sein Werkzeugprogramm dann eine
> Hardwarebeschreibungssprache?
Ja sicher doch. Beschrieben wird das Werkstück. Programmiert wird die 
Maschine. Die Beschreibung steckt implizit im Programm drin.

Jetzt die Analogie:

Beim FPGA programmieren wir Vivado (Drehbank) und das baut uns eine 
Verschaltung, die das tut, was diejenige Schaltung tun soll, die wir 
beschrieben haben. Genau genommen baut die Drehbank eine von mehreren 
denkbaren funktionsähnlichen Schaltungen.

von -gb- (Gast)


Lesenswert?

Ja kann man so sehen. Aber dann ist so ziemlich alles ein Programm und 
Software.
Eine Bilddatei beschreibt ja auch wie die Pixel zu färben sind. Also ist 
das jpg auf der Speicherkarte ein Programm. Ich kann das dem Drucker 
geben und für den ist das eine Art Plan was er zu tun hat. Und Software 
ist ein Bild auch denn es ist nicht Hardware und kann auch in eine 
Firmware mit reingebacken werden.

Oder eine Textdatei. Die beschreibt auch was da angezeigt oder 
ausgedruckt werden soll. Also klar ein Programm. Der Texteditor verhält 
sich mit der Textdatei anders als ohne und auch anders als mit anderen 
Textdateien.

von Gerd (Gast)


Lesenswert?

Ein Programm kann man laufen lassen. Mit Hilfe eines Debuggers kann man 
im Einzelschrittbetrieb nach Fehlern suchen.

Wie kann man ein FPGA Programm laufen lassen? Mit welchem Debugger kann 
man im VHDL Breakpoints setzen und nach Fehlern suchen?

von Mcn (Gast)


Lesenswert?

Gerd schrieb:

> Wie kann man ein FPGA Programm laufen lassen? Mit welchem Debugger kann
> man im VHDL Breakpoints setzen und nach Fehlern suchen?

Das sollte dir klar sein bevor du hier als komplett Ahnungsloser 
versuchst in einem Fachforum mit zu diskutieren!

Lies Dich bitte in die FPGA design-methodology ein bevor du hier das 
nächste Mal den Mund aufreist.
Stichpunkte: altera signaltap, xilinx chipscope,logic analyzer,

https://docs.xilinx.com/r/en-US/ug1393-vitis-application-acceleration/Automated-Setup-for-Hardware-Debug

Hinweis1: In der FPGA-Entwicklung spricht man eher von Verification 
(Überprüfung der Implementierung gegen die Requirements) statt 
Debugging. Oder auch in derSoftwareentwicklung oberhalb des Levels 
"blutiger Amateur".

Hinweis2: https://www.rz.uni-frankfurt.de/39888311/Generic_39888311.pdf

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


Lesenswert?

Da kann man das Haar offensichtlich 8-fach der Länge nach durchspalten.
Was aber abseits jeglicher Philosophie und Germanistik im täglichen 
Leben laufend passiert, ist das: irgendwer "programmiert" sein FPGA mit 
Verilog und VDHL genau mit der selben (Zeile-für-Zeile-)Denkweise wie er 
auch seinen µC mit C oder seinen PC mit Python "programmiert".

Da im https://embdev.net/topic/546016 klemmt sich schon wieder einer die 
Nase ein, weil er sein FPGA mit VHDL "programmieren" will und dazu 
Vergleiche mit anderen prozeduralen Programmiersprachen heranzieht.

Der Beste dort hat keine Ahnung, wie ein FPGA intern aufgebaut ist und 
dass es dank 4er oder 6er LUTs völlig sinnlos ist, die 
Logiktiefe/Durchlaufzeit durch einen Binärbaum reduzieren zu wollen.

Es kann natürlich auch eine vom Lehrer völlig verunglückte 
Aufgabenstellung sein. Das wäre dann aber wieder ein Beispiel zum 
ursprünglichen Thema des Threads. Und zwar eines dafür, wie man es nicht 
machen sollte.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

So wichtig ja auch der Unterschied zwischen programmieren und 
beschreiben sein mag, man darf auf keinen Fall auch die anderen 
wichtigen Unterschiede vergessen, z.b. ob man Ballons fliegt oder 
faehrt, oder ob alte Saecke jetzt Amateurfunker oder Funkamateure 
sind...

duck&wech
WK

von Falk B. (falk)


Lesenswert?

Lang lebe die judäische Volksfront!

von Markus F. (mfro)


Lesenswert?

Lothar M. schrieb:
> Was aber abseits jeglicher Philosophie und Germanistik im täglichen
> Leben laufend passiert, ist das: irgendwer "programmiert" sein FPGA mit
> Verilog und VDHL genau mit der selben (Zeile-für-Zeile-)Denkweise wie er
> auch seinen µC mit C oder seinen PC mit Python "programmiert".

... und Du (oder Ihr) glaubt, das wäre irgendwie anders oder besser, 
wenn VHDL keine Programmiersprache, sondern eine "FPGAisiersprache" 
wäre?

Es ist völlig normal, dass Menschen versuchen, mit dem, was sie kennen, 
sich das zu erschliessen, was sie noch nicht kennen. Da ist es komplett 
wurscht, wie das heisst und wenn dieser Fred noch hundert philosophische 
Beiträge bekommt.

von Christoph Z. (christophz)


Lesenswert?

Gerd schrieb:
> Wie kann man ein FPGA Programm laufen lassen? Mit welchem Debugger kann
> man im VHDL Breakpoints setzen und nach Fehlern suchen?

Mit Synplify Identify kann ich im VHDL Source Code einen Beakpoint 
setzen, der dann den Logic Analyser Triggert, den Identify mir 
zusätzlich zu meinem Design in das FPGA gepackt hat.

Ich war sehr beeindruckt, dass Identify das auf Source Code Ebene kann 
und nicht nur klassisches Pattern Triggern, wie man es sich bei Logic 
Analysern gewöhnt ist.

https://it.emcelettronica.com/wp-content/uploads/2016/10/La-finestra-principale-dell%E2%80%99Instrumentor.jpg

Markus F. schrieb:
> ... und Du (oder Ihr) glaubt, das wäre irgendwie anders oder besser,
> wenn VHDL keine Programmiersprache, sondern eine "FPGAisiersprache"
> wäre?
>
> Es ist völlig normal, dass Menschen versuchen, mit dem, was sie kennen,
> sich das zu erschliessen, was sie noch nicht kennen. Da ist es komplett
> wurscht, wie das heisst und wenn dieser Fred noch hundert philosophische
> Beiträge bekommt.

Ja, das ist völlig normal und ist uns auch allen bewusst, da wir das ja 
selber durchgemacht haben.
Die Idee VHDL in der Lehre als Beschreibungssprache einzuführen ist 
genau, dass ein Lernender hoffentlich ein bisschen gezwungen ist, etwas 
besser aufzupassen, was gleich ist zu bekanntem und was komplett anders 
ist.


Es ist nicht einfach zu erklären was jemand wie ich mache, noch 
schwieriger es zu unterrichten eben genau, weil es zwischen Stuhl und 
Bank zwischen reiner Software und reiner Hardware fällt.

Ich selber finde genau das aber so super spannend :-)


In diesem Thread ist es glaub Konsens, das Grundlagen FPGAs und HDL zu 
einer heutigen Ausbildung gehören sollten. Damit das klappt sind wir uns 
glaub auch einig, das es dafür zuerst auch etwas Grundlagen in 
Digitaltechnik, Programierparadigmen, Softwareentwicklung und 
Rechnerarchitekturen braucht.

Damals in meiner Lehre als ich CMOS Gatter zusammengelötet und ein 
bisschen C programmiert habe, habe ich von FPGAs und VHDL gelesen und 
konnte mir selber komplett nicht vorstellen, wie das gehen soll, dass 
ich da in Text so was wie ein Schema erstelle.
Mein Erster Dozent im Studium konnte mir das auch nicht wirklich 
näherbringen.
Für mich, der von unten her an VHDL gekommen ist, war das Buch "VHDL 
Synthese" genau richtig und für andere wird es nicht passen.

von Markus F. (mfro)


Lesenswert?

Christoph Z. schrieb:
> dass
> ich da in Text so was wie ein Schema erstelle.

Lustigerweise bewegen sich die Konzepte da mittlerweie aufeinander zu. 
Auch in C++ z.B. schreibt man heutzutage Schleifen, die am Ende gar 
keine sind (metaprogramming) bzw. ganz generell (constexpr) erzeugt ein 
Quelltext u.U. etwas ganz anderes (oder auch gar nichts) als in der 
Vergangenheit, wo immer 1:1 die direkte Umsetzung in Binärcode 
herauskam.
Ich würde eigentlich erwarten, dass heutige Studenten, die so was schon 
mal gesehen haben, sich deswegen mit dem Konzept der 
Hardwarebeschreibung (die statt Binärcode eben ein funktionsidentisches 
Schaltwerk erzeugt) deutlich einfacher tun als unsereins, für den das 
(direktes Umsetzen) schlicht ein Naturgesetz war.

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


Lesenswert?

Christoph Z. schrieb:
> Mit Synplify Identify kann ich im VHDL Source Code einen Beakpoint
> setzen, der dann den Logic Analyser Triggert, den Identify mir
> zusätzlich zu meinem Design in das FPGA gepackt hat.
Der "Breakpoint" bewirkt dann aber nicht, dass das FPGA in diesem 
Zustand "stehenbleibt". Sondern das ist eben nur ein elegant berechneter 
"Triggerpoint".

Markus F. schrieb:
> ... und Du (oder Ihr) glaubt, das wäre irgendwie anders oder besser,
> wenn VHDL keine Programmiersprache, sondern eine "FPGAisiersprache" wäre?
Allemal besser als wenn sie gleichlautend wie C oder Python eine 
"Programmiersprache" ist.

> Es ist völlig normal, dass Menschen versuchen, mit dem, was sie kennen,
> sich das zu erschliessen, was sie noch nicht kennen.
Ja, und jede Ähnlichkeit mit etwas Bekanntem ("programmieren"?, ja klar, 
kann ich!) setzt den Anreiz zum selbständigen Nachdenken herunter.

> Da ist es komplett wurscht, wie das heisst
Da fällt mir sofort "Wegtreten!" vom Traumschiff Surprise ein. In dieser 
Szene kommt auch einer mit den Begrifflichkeiten durcheinander ;-)

Eines noch zu dem, was
Andreas F. schrieb:
> Es ist aber schon bekannt, dass
> * in jedem zweiten FPGA ein SoftCore steckt, der C-Software fordert
> * in jedem fünften FPGA ein Hardcore steckt, der C-Software erfordert
> * in jedem zehnten FPGA ein Betriebssystem steckt, das sogar C++ erfordert
> Das ist eine ganze Menge Software finde ich
80% aller FPGA-Systeme mit einem Soft- oder Hardcore?
Woher kommen diese Werte?
Mir scheinen die Zahlen arg hoch gegriffen...

von Andi F. (chefdesigner)


Lesenswert?

Lothar M. schrieb:
> Christoph Z. schrieb:
>> Mit Synplify Identify kann ich im VHDL Source Code einen Beakpoint
>> setzen, der dann den Logic Analyser Triggert, den Identify mir
>> zusätzlich zu meinem Design in das FPGA gepackt hat.
> Der "Breakpoint" bewirkt dann aber nicht, dass das FPGA in diesem
> Zustand "stehenbleibt". Sondern das ist eben nur ein elegant berechneter
> "Triggerpoint".
Gleichwohl ist das sehr interessant. Mit dem Xilinx Debugger ist das 
umständlicher: Signal markieren, XDC updaten, bauen lassen. Debugger 
anwerfen. Ich kenne das noch vom ChipScope, wo ich noch Signale zählen 
und die Anzahl dem Programm mitteilen musste, weil es zu dumm war, 
selber zu zählen. Das scheint wohl abgestellt worden zu sein.

Ich bin da nicht mehr so drin, nehme aber zur Kenntnis, daß die 
FPGA-Welt voranschreitet. Kann man das Synplify Itenty auch mit der 
Xilinx Toolchain komnbinieren? Das würde ich dann unseren Entwicklern 
aufs Auge drücken.

Lothar M. schrieb:
> Andreas F. schrieb:
>> Es ist aber schon bekannt, dass
> 80% aller FPGA-Systeme mit einem Soft- oder Hardcore?
> Woher kommen diese Werte?
> Mir scheinen die Zahlen arg hoch gegriffen...
Ich beziehe mich dabei auf das was wir so machen. Die vielen kleinen 
Anwendungen mit einfacher Logik haben wahrscheinlich werden eine CPU 
noch großartiges Cores drin. Mag sein. Es ist aber eine Tatsache , daß 
man mit einer eingebauten CPU als Softi es sehr einfach hat, solche 
Sachen zu debuggen und von der Console aus mit dem FPGA zu 
kommunizieren. Wir haben hier ganze Bibliotheken voll mit C-Code, um 
Gegenstellen für unsere Operationssysteme im Microblaze zu realisieren.

Tatsächlich taucht auch in jeder zweiten Stellenanzeige anderer Firmen 
zuerst C++ auf, wenn es um FPGAs geht. Das scheint mir aber deshalb so 
zu sein, weil dort der Beadrf ist und sich die Geschichte dort hin 
hinbewegt.

von Andi F. (chefdesigner)


Lesenswert?

Lothar M. schrieb:
> irgendwer "programmiert" sein FPGA mit
> Verilog und VDHL genau mit der selben (Zeile-für-Zeile-)Denkweise wie er
> auch seinen µC mit C oder seinen PC mit Python "programmiert".
Dann hat er eben nicht verstanden, was er da tut.

> schon wieder einer die Nase ein, weil er sein FPGA mit VHDL
> "programmieren" will und dazu Vergleiche mit anderen prozeduralen
> Programmiersprachen heranzieht.
Dann muss man es ihm erklären.

> Der Beste dort hat keine Ahnung, wie ein FPGA intern aufgebaut ist und
> dass es dank 4er oder 6er LUTs völlig sinnlos ist, die
> Logiktiefe/Durchlaufzeit durch einen Binärbaum reduzieren zu wollen.
dito


Ich denke das Hauptproblem ist, dass sich die Allermeisten die 
Programmiererei selber beigebracht haben. Als es um Prozessoren geht, 
war der Zusammenhang zwischen Ablauf und Befehl leicht autodidaktisch zu 
erfassen. Das geht bei einem FPGA halt nicht, wenn man nicht versteht, 
was man tut, sondern sich beim Ausprobieren das Wissen aufbauen will.

Da ist der Lehrer gefordert. Wenn natürlich die Lehrer sehr keine klare 
Vorstellung davon haben, wie man das vermittelt und viele erst gar keine 
Hochschule sehen, sondern auf Youtube lernen, wird es schwer.

Ich stamme gott-sei-dank noch aus einer Generation 1970+, die mit 
Elektronik aufgewachsen ist und Bausteine verlötet hat.

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.