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.
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...
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
Andreas S. schrieb:> Mit solch einer Einstellung gewinnst Du aber niemals den renommierten> Troll-Award! :-)
Mist! Ich werde meine Einstellung über das Wochenende überdenken.
:)
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 ;-)
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?
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. :-(
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.
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.
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.
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.
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.
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.
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 :-)
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 :)
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.
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.
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.
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...
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 . . .
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.
Mcn schrieb:> Und natürlich gibt es auch die Exoten wie Crypto-Miner, realtime> trading, Retro-Obsoloscence-Ausgleicher, ... .
das gibts mittlerweile ASICs für
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.
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.
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.
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.
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!
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.
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.
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".
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! ;-)
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"
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".
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...
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/
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.)
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
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 . . .
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.
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
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.
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.
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.
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
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.
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!
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.
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.
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
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?
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 ...
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
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
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.
;-)
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.
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!
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
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!
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? ;-)
>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).
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?
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".
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.
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.
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.
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.
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.
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.
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
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?
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...
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.
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.
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.
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.
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!
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?
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.
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.
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.
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.
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.
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.
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)
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, geradeVHDL 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.
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 . . .
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...?
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.
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.
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.
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
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...
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.
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.
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.
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!
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.
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!
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.
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).
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.
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.
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.
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.
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.
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'.
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.
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.
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.
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...
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!
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.
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.
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.
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")
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...
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.
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.
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
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.
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".
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.
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.
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.
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?
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.
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.
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.
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.
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.
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"
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.
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. :-)
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=677https://www.c64-wiki.de/wiki/Bil_Herd
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
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.
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!
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 :-)
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!
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...
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 . . . ;-)
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.
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.
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.
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!
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 :-)
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".
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.
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.
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.
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.
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.
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.
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.
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.
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?
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
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.
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
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.
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.jpgMarkus 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.
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.
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...
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.
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.
