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.
Ja, die Vermittlung macht Sinn Ja, Lehr-/Lernprojekte gibt es massenweise. Gut, dass heute Freitag ist....
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.
:
Bearbeitet durch User
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.
Gerd schrieb: > ... Insbesondere da es heute sehr > schnelle Mikrocontroller gibt (bsp. die H7 Serie von ST) kann man immer > mehr auf FPGAs verzichten. Hier mal schauen: https://www.microchip.com/en-us/products/fpgas-and-plds/radiation-tolerant-fpgas/rtg4-radiation-tolerant-fpgas https://www.microchip.com/en-us/product/rtax4000s Bei den aktuellen Space-Projekten verzichten wir damit auf µCs/CPUs!
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.
:
Bearbeitet durch Moderator
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.
Bierbaron schrieb: > Mcn schrieb: >> Und natürlich gibt es auch die Exoten wie Crypto-Miner, realtime >> trading, Retro-Obsoloscence-Ausgleicher, ... . > > das gibts mittlerweile ASICs für Wer halt zu spät kommt, denn bestraft das Leben. Es sei denn, er sucht sich eine neues Betätigungsfeld für seine Vorreiterfähigkeiten, bspw.: https://chime-experiment.ca/en. Die Umsätze der FPGA-Firmen klettern seit Jahrzehnten stetig, da ist eine baldige Ablöse unwahrscheinlich: https://www.golem.de/news/fpgas-xilinx-macht-ein-drittel-mehr-umsatz-und-kauft-solarflare-1904-140873.html
vancouver schrieb: >> und ABM für ihre Belegschaft . . . > > Oh, Uni-Bashing. Daher weht der Wind. Jaja, es leben die Extreme. Ich will nicht behaupten, daß ALLE Uni-Angestellten in der Ecke zu finden sind. Leider mußte ich in den letzten ~20 Jahren feststellen, daß überwiegend diese mir über den Weg gelaufen sind. Mal überlegen. Hmmm. Bei den drei bis vier Projekten, bei denen ich mehr oder minder Einblick hatte oder gar beteiligt war, ist nicht viel rausgekommen. Und das lag oft an den Leuten, nicht am Projektinhalt. Mir ist der Unterschied zwischen Forschung und Entwicklung schon klar. Bei Forschung weiß man an Anfang nicht was rauskommt, bei Entwicklung schon. Trotzdem ist es eine Frage, wie man die Sache angeht. Ich schweife ab.
:
Bearbeitet durch User
Beitrag #7236002 wurde von einem Moderator gelöscht.
Beitrag #7236014 wurde von einem Moderator gelöscht.
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. |
https://www.c64-wiki.de/wiki/Bil_Herd https://de.wikipedia.org/wiki/Tobias_L%C3%BCtke
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" |
(Ehrlich, hinter dieser Schilderung könnt auch mein Klarname stehen ;-), beim Reset der Linus-Geschichte aber eher nicht :-( ) https://www.hna.de/netzwelt/multimedia/freak-statt-karrierist-zr-813563.html
Beitrag #7236243 wurde von einem Moderator gelöscht.
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/
Angehängte Dateien:
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 . . .
Angehängte Dateien:
-
makeItYourASIC.PNG
110 KB
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
fir_filter.jpg
69 KB
Jürgen S. schrieb: > Gerhard H. schrieb: >> Georg A. schrieb: >>> So 1999 rum habe ich mich noch mit einem >>> älteren Deppenprof (könnte Uni Dortmund oder Köln gewesen sein) >>> rumgestritten, der der felsenfesten Meinung war, dass das mit FPGAs >>> nichts wird und nur ASICs der Markt sind. >> Aber Tunnelblick auf Fujitsu ASICs und Telefunken B1000, was man >> halt bisher als Standardlösung hatte. > Schon seltsam was man so lesen muss! Ich kann nur für meine Uni und > meine Profs sprechen und diesbezüglich waren die sehr fortschrittlich. > Wir waren damals die einzige Uni, wo man außer in Berlin so vertieft > Halbleiterelektronik studieren konnte und sogar Aachen und Darmstadt > voraus. Das war bei mir Berlin. Und ich habe oben geschrieben, dass unsere Profs sicher keine Deppen waren. Wer bei IBM I2L erfunden hat, der fällt da sicher nicht darunter, und der, von dem ich geschrieben habe auch nicht. Und auch nicht der, bei dem wir zu 6st eine CPU in HP's dynamic n-MOS Prozess machen durften. Es war auch kein Problem, dass ich auf der dortigen VAX750 die CUPL- Version von meinem FHG-Nebenjob einspielen durfte und dort ziemlich viel CPU-Zeit verbraten habe. Da habe ich u.a. gelernt, wie man große state machines in den Griff bekommt. Da ist z.B. obiges FIR-Filter dabei rausgekommen. Etwa 1984 nach den Datecodes der Chips. > Offenbar macht es doch einen Unterschied, an welcher Uni man war. Einige > Studenten scheinen da auf Irrwege geschickt zu werden. Also, Berlin war sicher kein Irrweg. Zumindest nicht, was die TU betraf. Und wenn da Designhouse-Ausgründungen in der Luft liegen, dann wäre ich heutzutage flexibler. :-) Gerhard
:
Bearbeitet durch User
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
:
Bearbeitet durch Moderator
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: > vancouver schrieb: >>> und ABM für ihre Belegschaft . . . >> >> Oh, Uni-Bashing. Daher weht der Wind. > keine > Ingenieurswissenschaftler, aber auch bei denen gibt's genügend Flausen > und heiße Luft. Und für die Skurrilsten gibt es den Ig-Nobelpreis: ;-) https://www.br.de/nachrichten/wissen/ig-nobelpreis-2022-surfende-enten-und-skorpione-mit-verstopfung,THaGYa3 https://www.geo.de/wissen/ig-nobelpreise-2021--die-gewinner-30729422.html https://www.der-niedergelassene-arzt.de/kaffeepause/news-details/kaffeepause/ig-nobelpreis-2020-helium-alligator-kaugeraeusche-kot-messer-und-andere-kuriose-forschungsthemen Und dann war da noch eine Dissertation zur Selbstverstümmelung an Vorwerk-Staubsaugern ;-) (https://de.wikipedia.org/w/index.php?title=Staubsaugersex)
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?
>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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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, gerade VHDL ist zuallererst als reine Beschreibungssprache entwickelt worden. Das DOD wollte eine Methode, damit alle Hersteller/Zulieferer ihren Digital/Protokoll-Kram "wohldefiniert" beschreiben und auch gegeneinander testen können, statt sich nur auf irgendein schwammiges Englisch in undurchschaubaren Requirementlisten zu verlassen. Zu dem Zeitpunkt (Mitte 80er Jahre) ging nur Simulation, VHDL hat ja auch viele Konstrukte, die nur simulierbar sind. FPGAs waren zu der Zeit noch exotische Spielereien, eine vernünftig nutzbare Synthese (egal ob ASIC oder FPGA) ist erst Anfang der 90er aufgekommen.
:
Bearbeitet durch User
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
Angehängte Dateien:
-
programmable_resistor.jpg
150 KB
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...
Duke Scarring schrieb: > 5. Ich muß heute wieder ein paar Widerstände programmieren... Jajaja, immer lustig die translation failures: https://youtu.be/CkbHGH-NnkU?t=65 Und ich glaub ich hab irgendwie noch den Zettel wie man den PC-AT "auf Turbo 'programmiert'" (Jumper setzen für die taktanzeige). https://de.wikipedia.org/wiki/Turbo-Taste
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.
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > 4. Konfigurieren einer Analogschaltung (bspw. des TLC271, bei dem über > den Bias-Eingang der Ruhestrom und damit die GBW, Slewrate und > Differenzverstärkung in drei Stufen eingestellt werden kann). > > Mit (1), (2) und (3) kann ich mich sehr gut anfreunden, bei (4) fällt es > mir zugegebenermaßen etwas schwer, von "programmieren" zu sprechen, weil > das doch arg weit weg ist von dem, was ich üblicherweise programmiere. Heutzutage gibt es tatsächlich viele analoge Bauelemente mit "programmierbaren" Elementen. Sog. programmierbare MOSFETs enthalten zwischen dem Gate und dem Kanal noch ein zusätzliches Floating Gate, mit dessen Ladezustand sich die Thresholdspannung sehr fein einstellen lässt, d.h. von reinen Verarmungstyp bis hin zum reinen Anreicherungstyp. https://www.aldinc.com/ald_mosfetarrays.php Einige Analog-IC sind mit ähnlichen Methoden herstellerseitig für z.B. eine minimale Offsetspannung "vorprogrammiert". Im Gegensatz zur Lasertrimmung kann dann die "Programmierung" erfolgen, wenn der Chip schon im Gehäuse untergebracht ist. Vielfach wird aber auch kein Analogwert direkt in einem Floating Gate gespeichert, sondern ein ganzer DAC oder gar Microcontroller im IC untergebracht.
:
Bearbeitet durch User
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.
Chris D. schrieb: > [...] Ich wollte keine Diskussion über Vor- und Nachteile von Pyhton starten. Nur die Frage beantworten. :)
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: > Nenne mir mal eine Grafische Programmiersprache. Piet. Unn? Komm ich getz in Fernsehen? https://de.wikipedia.org/wiki/Piet_(Programmiersprache) scnr, WK
W.S. schrieb: > Mcn schrieb: >> sondern um ganz konkrete nicht auf Texteingabe >> basierende Programmiersprachen/Systeme > Dann könnte man ein Bildbearbeitungsprogramm auch als IDE und ein Bild > als Programmiersprache bezeichnen. Ich kannte mal eine Sekretärin, die sagte, sie sei Computerprogrammiererin, weil sie den Computer so "programmierte", das er den Brief so ausdruckte, wie sie das wollte. W.S. schrieb: > ..und warum soll eine Programmiersprache für programmierbare > Logik-Bauteile nicht Programmiersprache heißen? Weil sie sich in ihrem eignen Namen selbst "Beschreibungssprache" nennt? Wenn einer sagt: "Ich bin Karl", sagst du dann auch "Hallo Franz"? Myclass schrieb: > Mashine Learning Die Maschine heißt auf englisch "machine" Auf Suaheli gehts natürlich durch: https://en.wiktionary.org/wiki/mashine
:
Bearbeitet durch Moderator
Wollt ihr nicht da weiterspielen? https://www.babymarkt.de/plum-gigantischer-kinder-sandkasten-aus-holz-mit-baenken-und-schutzhuelle-a207299.html?recommended Um was gings denn eigentlich ...
hmm schrieb:... > Um was gings denn eigentlich ... Zuerst war da tatsächlich noch ein Thema. Dann ging's schnell nur noch ums Recht haben.
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.
:
Bearbeitet durch Moderator
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.
Jürgen S. schrieb: > Nein, nur die unsaubere Sprache mancher Lehrenden Pff....schwafelt über unsaubere Sprache und kommt dann mit sowas daher.
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. :-)
Dergute W. schrieb: > Unn? Komm ich getz in Fernsehen? > https://de.wikipedia.org/wiki/Piet_(Programmiersprache) Oha, kannte ich noch gar nicht. LABVIEW nennt sich auch "grafische Programmierpsrache" und kann glaube ich auch FPGA.
>LABVIEW nennt sich auch "grafische Programmierpsrache" und kann glaube >ich auch FPGA. Stimmt, so ist es: https://www.ni.com/de-ch/shop/electronic-test-instrumentation/add-ons-for-electronic-test-and-instrumentation/what-is-labview-fpga-module.html
Jürgen S. schrieb: > @all: Deshalb passt auch der Begriff "FPGA-Designer" nicht. Der FPGA > wird nicht designed. Er wird auch nicht programmiert und er wird auch > nicht beschrieben. (Jedenfalls nicht vom Mensch - beschrieben und > programmiert wird er vom USB-Programmer). Es wird ein Design mit einem FPGA erstellt - also passt der Begriff FPGA-Designer mindestens ungangsprachlich. Auch wenn der FPGA als IC nicht von "FPGA-Entwickler" gemacht wird, das macht der "Chipdesigner". Exakter passt FPGA-HW-designer, aber da winken auch viele ab, weil sie Hardware-Design mit reinem PCB-Design (Schematic-Entry und Layout) verwechseln. Manchmal ist es auch eine Frage der Größe der Entwicklungsabzeilung(en). Bei Firmen mit schlankes, Produktzentrierte Entwicklung können schon mal wenige Mitarbeiter alle Schritte in der Geräteentwicklung, bei Konzernen dagegen macht eine sein Leben lang den Papierkram (datenblattpflege, Zertifikate "abheften) ein Leben lang ohne sich mit den anderen 99.5% der Entwicklungs-KnowHow konfrontiert zu werden. Übrigens hatte man das Problem der genauen Job-Beschreibung zwischen den Abteilungen in einer Computerbude schon in den Achtziger. Bil Herd, der Chefentwickler bei Commodore für den C128, bevorzugte seinen Arbeitsplatz unter den Chipdesignern, obwohl auch als Firmware-Programmierer tätig war. https://youtu.be/-Zpv6u5vCJ4?t=677 https://www.c64-wiki.de/wiki/Bil_Herd
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!
Beitrag #7253528 wurde von einem Moderator gelöscht.
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.jpg Markus F. schrieb: > ... und Du (oder Ihr) glaubt, das wäre irgendwie anders oder besser, > wenn VHDL keine Programmiersprache, sondern eine "FPGAisiersprache" > wäre? > > Es ist völlig normal, dass Menschen versuchen, mit dem, was sie kennen, > sich das zu erschliessen, was sie noch nicht kennen. Da ist es komplett > wurscht, wie das heisst und wenn dieser Fred noch hundert philosophische > Beiträge bekommt. Ja, das ist völlig normal und ist uns auch allen bewusst, da wir das ja selber durchgemacht haben. Die Idee VHDL in der Lehre als Beschreibungssprache einzuführen ist genau, dass ein Lernender hoffentlich ein bisschen gezwungen ist, etwas besser aufzupassen, was gleich ist zu bekanntem und was komplett anders ist. Es ist nicht einfach zu erklären was jemand wie ich mache, noch schwieriger es zu unterrichten eben genau, weil es zwischen Stuhl und Bank zwischen reiner Software und reiner Hardware fällt. Ich selber finde genau das aber so super spannend :-) In diesem Thread ist es glaub Konsens, das Grundlagen FPGAs und HDL zu einer heutigen Ausbildung gehören sollten. Damit das klappt sind wir uns glaub auch einig, das es dafür zuerst auch etwas Grundlagen in Digitaltechnik, Programierparadigmen, Softwareentwicklung und Rechnerarchitekturen braucht. Damals in meiner Lehre als ich CMOS Gatter zusammengelötet und ein bisschen C programmiert habe, habe ich von FPGAs und VHDL gelesen und konnte mir selber komplett nicht vorstellen, wie das gehen soll, dass ich da in Text so was wie ein Schema erstelle. Mein Erster Dozent im Studium konnte mir das auch nicht wirklich näherbringen. Für mich, der von unten her an VHDL gekommen ist, war das Buch "VHDL Synthese" genau richtig und für andere wird es nicht passen.
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.
Ich bin mir ziemlich sicher das Schlaubi-Schlumpf seine FPGAs schlumpft, und nicht programmiert oder beschreibt. Vielleicht könnten wir das einfach übernehmen und in Stelleninseraten würde dann stehen: 'FPGA Schlumpf' gesucht. ;-)
Lothar M. schrieb: >>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. Da kommen wir jetzt in einen kritischen, da politischen Diskussionsbereich, zu dem ich nur ganz kurz was sagen möchte, um den thread nicht zu abstrahieren und auch nicht in den Verdacht zu geraten, zu hetzen: Doch, die Inder, die hier "in den Räumen hocken" sind sehr billig. Die kriegen als Anfangsgehalt gerade das Minimum mit Hinweis auf Deutschkenntnisse und gebremste Kommunikation. Allein schon durch ihre Zahl und das Vorhandensein, entspannen sie den Arbeitsmarkt für den AG und drücken die Löhne runter. Ich behaupte dabei nicht, dass sie nichts können - im Gegenteil: Ein bacheler aus Indien lernt in etwa das Gleiche, wie einer hierzulande. Man bekommt eben nur in Indien keinen Experten mit 20 Jahren TopErfahrung, weil es damals nicht so dolle war. > Und da sollte sich der FPGA-Dienstleister dann die Schlauen > aus den 1,4 Milliarden aussuchen. Was aus zwei Gründen nicht geht: 1) Die Inder sind auch nicht dumm und wollen am Ende besser verdienen. Daher gehen sie zu den OEMs. Wir haben uns 2 gekrallt. Die sind richtig gut und kriegen das Gleiche, wie ihre gleichgestellten Kollegen. Allerdings: Die Gehälter dieser jungen Leute U30 sind bei Weitem nicht mehr das, was es zu meiner Zeit mal war. 2) Die Ausbildungen sind dort nicht verifizierbar. Die Inder haben z.T. gleiche Vor- und Nachnamen und man findet unter ein und demselben Namen gleich mehrere Ingenieure unterschiedlicher- aber auch derselben Hochschule. Indien schüttet den Markt mit Softwareentwicklern zu, dass es nur so kracht und bei Ingenieuren ist es ähnlich. Da die Unis dort geflrdert werden, wenn sie viele gute Absolventen haben, haben sie eben viele Absolventen mit guten Noten :-) :-( Es gibt dann ein Problem: Manche, die das Studium nicht geschafft haben, kopieren sich die Lebensläufe und Zeugnisse einer namensgleichen Person und hängen sich da dran. Z.T. gibt es dann doppelte und dreifache Profile auf LinkedIn. Am Ende muss man Inder noch mehr testen als die anderen Absolventen mit ihren gefotoshopten Zeugnissen.
@Gerd: Ich möchte dir als TO noch etwas schreiben: Alle die nachfolgenden von dir geposteten Beiträge zeigen mir, dass du von FPGAs nicht viel verstanden hast. Du hast sehr einfache Projekte gemacht und eine stark reduzierte Vorstellung von dem was damit zu machen ist und auch gemacht wird. Gerd schrieb: > Allerdings ist die Programmierung von FPGAs so viel umständlicher und > braucht so viel mehr Zeit (ich nehme Faktor 5 als Richtwert) Es gibt keinen Richtwert, weil es verschiedene Dinge sind. Ob man eine bestimmte Lösung mit einem FPGA überhaupt und besser bauen kann und wie schnell das zu tun ist, hängt von der Aufgabe ab. Da gibt es alle Kombinationen zwischen schneller und langsamer, teuer und billiger, früher fertig und später fertig. Gerd schrieb: > Mir viel keines ein. In meiner beruflichen Laufbahn bin ich immer ohne > den Einsatz von FPGAs ausgekommen. Dann sitzt du auf eine Spezialstelle in einer Spezialfirma, die nur Spezialprojekte macht. Alles was heute Elektronik ist, hat digitale Komponenten und braucht programmierbare Bausteine. Gerd schrieb: > Mittels VHDL wird eine "Fuse-List" erzeugt. Diese werden in das FPGA > geladen Zu keinem Zeitpunkt wurde jemals eine "fuse list" in einen FPGA geladen. Gerd schrieb: > Ein Programm kann man laufen lassen. Mit Hilfe eines Debuggers kann man > im Einzelschrittbetrieb nach Fehlern suchen. Das geht in den FPGA-Umgebungen ganz genau so. Breakpoints, Assertions, Messages - alles da. Man kann es von der GUI aus, von der Console und auch vom Code aus steuern. > Wie kann man ein FPGA Programm laufen lassen? Das was du "Programm nennst" ist der HDL-Code. Der wird in der Entwicklungsumgebung wie oben beschrieben laufen gelassen. Der Simulator rechnet alles mit, zeigt dir die Speicher, die Zustände und sogar den Ausführungspunkt im Code, weil das sequenziell geht. Es ist dasselbe wie in jeder anderen Umgebung. Du kannst sogar Visual Studio und Eclipse zum Handling des Codes hernehmen. Das eigentliche "Programm" im FPGA, was wir Konfiguration nennen, kann man genau so laufen lassen: Im ärgsten Fall kann man die Clock einzeln takten. Das wird man aber nicht tun, sondern einen debugger drüber hängen. Entweder einen im FPGA oder einen draussen der die Leitungen beobachtet. Bei uns klemmt ein fettes RACK am ARINC-Bus - kannst du mit dem OSZI jedes Signal einzeln begrüßen, so wie mit einem Lauterbach am ARM. Breakpoints setzen geht auch, wenn man sie instrumentiert: Man formuliert das Stopkriterium und legt es auch die enables der Schaltung. Die hält dann sofort an. Wer es braucht.
Lothar M. schrieb: > 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? Woher diese Werte kommen? Aus der Vorstellung von Andreas. Allerdings sind sie alle grundfalsch, denn kein einziger Soft- oder sonstiger Core erfordert etwas in C Geschriebenes und kaum ein OS erfordert Programme, die in C++ geschrieben sind. Da kenne ich nur eine Ausnahme: Symbian. Das exportierte als Schnittstelle irgendwelche Objekte, die mit C++ gebildet waren. Aber die Zeit der Nokia-Telefone mit Symbian drin ist vorbei. 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". Wer gelernt hat, nach PAP zu programmieren (aka Rumpelstilzchen: Heute back ich, morgen brau ich, ...) kann sowas erstmal nicht anders. Man müßte ihm Lehre angedeihen lassen. Fehlt aber offenbar. Tja, das läßt auf Defizite in der Lehre schließen, wie ich viel weiter oben bereits geschrieben habe. Anstatt sich "verbesserte" Bezeichnungen für die verwendete Programmiersprache auszudenken, tagelang hier herumzudiskutieren und haarspalterisch tausendunddrei Gründe herbeizuziehen, bloß um den selbstgemachten Unterschied herauszustellen, wäre eine inhaltlich bessere Lehre weitaus nützlicher - für alle. W.S.
Andreas F. schrieb: > Gerd schrieb: >> Ein Programm kann man laufen lassen. Mit Hilfe eines Debuggers kann man >> im Einzelschrittbetrieb nach Fehlern suchen. > Das geht in den FPGA-Umgebungen ganz genau so. Breakpoints, Assertions, > Messages - alles da. Man kann es von der GUI aus, von der Console und > auch vom Code aus steuern. Auch im Linearen fernsehen läuft den ganzen Tag ein Programm https://www.dazn.com/de-DE/news/fu%C3%9Fball/programm-live-stream-uebertragung-heute/cm1gakc7f9pizvzb0b79o6k8 🤪
Lothar M. schrieb: > 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? Man muss die drei Mengen nicht unbedingt als disjunkt auffassen, was dann bedeuten würde, das in jedem zweiten FPGA eine CPU als Hilfscomponente für den Logikteil steckt. Das könnte dann für die letzten zehn Jahre auch in etwa stimmen. Man denke da beispielsweise an das Retrocomputing (obwohl die dort verwendeten 8 bit Cores wie Z80 und Co eher nicht in C programmiert werden). Und historisch betrachtet ersetzen diese Cores weniger den Logikteil, sondern sind eher das Ergebnis der Systemintegration, die inzwischen gestattet CPU samt Glue,logic, DSP-Arithmetiks etc. unter einem IC-Hut zu schieben. Man kommt also auch in den Zeiten, in denen 100% der FPGA's eine CPU enthalten (egal ob Hard oder Soft) nicht umhin VHDL und Co zu können um die Turbomöglichkeiten des FPGA auszunutzen. Wer das nicht kann, soll halt bei seinem Embedded Controllern bleiben.
Lothar M. schrieb: >> 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. Das "ja-klar-kann-ich"-Problem gibt es nicht nur beim Wechsel von C nach VHDL, sondern sogar beim Wechsel von einer Computer-Programmiersprache zu einer anderen. Einem erfahrenen C/C++/Java-Programmierer fällt der Einstieg in bspw. Lisp, Prolog oder Haskell genauso schwer wie einem absoluten Programmierneuling, wenn nicht sogar noch schwerer. Der Unterschied zwischen den erstgenannten drei Sprachen (imperativ) und den letztgenannten drei (deklarativ) ist ähnlich groß wie der zwischen C und VHDL, weswegen das vermeintlich nützliche Vorwissen des C-Programmierers den Lernfortschritt eher blockiert. Plötzlich muss er auf viele liebgewonnene Dinge wie Anweisungen, Variablenzuweisungen und dergleichen komplett verzichten. Es gibt auch keine Ablaufsequenz mehr, die sich an der Reihenfolge der Programmzeilen im Quellcode orientiert. Deswegen ist auch Debuggen mit Single-Step durch den Quellcode nur sehr eingeschränkt möglich und oft wenig zielführend. Jetzt könnte man sich natürlich fragen, warum man das überhaupt noch "Programmieren" nennt, wo es doch mit der gewohnten Programmiererei kaum noch etwas gemein hat. Weil es sich um deklarative Sprachen handelt, könnte man bspw. "programmieren" durch "deklarieren" und "Programmierer" durch "Deklarierer" oder gar "Deklarator" ersetzen. Ich glaube aber nicht, dass diese Umbenennung die Einarbeitungszeit auch nur um eine Minute verkürzen würde. Anderes Beispiel aus dem täglichen Leben: Auch ein geübter Radfahrer tut sich schwer, wenn er das erste Mal Auto fährt. Das ist zwar beides "Fahren", und beide Fahrzeuge haben Pedale. "Hey, fahren mit Pedalen, das kann ich doch schon längst", sagt der Radfahrer zum Fahrlehrer, setzt sich ins Auto und strampelt munter drauflos :) Sollte man deswegen statt "Autofahren" besser "Automobilieren" sagen und den Fahrer "Automobileur" nennen, um den Unterschied zu verdeutlichen und damit vielleicht dem Fahrschüler den Einstieg ins Autofahren zu erleichtern? Ich glaube eher nicht. Das "ja-klar-kann-ich"-Problem wird IMHO nicht (auch nicht ansatzweise) durch Anpassung der Begrifflichkeiten gemindert. Aber natürlich ist das nur meine persönliche Meinung, andere mögen ganz anders darüber denken.
Bei Veranstaltungen gibt es ein Veranstatungsprogramm. Seltsamerweise gibt es niemanden, der es programmiert hat. Betrachten wir das Programm, sehen wir zeitlich aufeinanderfolgende Veranstaltungen. Auf manchen Veranstaltungen gibt es auch parallele Threads und kann leider nicht zwei Vorträge gleichzeitig besuchen. Kurz Zusammengefasst: Ein Programm ist eine Liste von Anweisungen, die zeitlich nacheinander abgearbeitet werden.
Gerd schrieb: > Kurz Zusammengefasst: Ein Programm ist eine Liste von Anweisungen, die > zeitlich nacheinander abgearbeitet werden. Nö. Keineswegs. Das war mal so. Spätestens seit Rechner mehr als einen Rechenkern haben, ist das Geschichte und nebenläufige Programme sind eher die Regel als die Ausnahme.
Markus F. schrieb: > nebenläufige Programme sind eher die Regel als die Ausnahme. Stimmt, wobei jedes Modul für sich ein ziemlich strikter Ablauf ist. Wenn man sich aber mit C++ befasst, ist der Schritt zur völligen Parallelität eigentlich machbar, meine ich, oder? Deswegen wird CC+ ja auch bevorzugt, wenn es um das Beschreiben von Parallelstrukturen geht, die z.B. in einen FPGA sollen. Markus F. schrieb: > Lustigerweise bewegen sich die Konzepte da mittlerweile aufeinander zu. Ja das tun sie und zwar von beiden Seiten :.) > Auch in C++ z.B. ... > Ich würde eigentlich erwarten, dass heutige Studenten, > sich ... deutlich einfacher tun als unsereins, Kommt drauf an, was man studiert. C++ wurde bei uns seit Mitte 1995 unterrichtet, C und die klassischen Parallelisierungsprobleme (Philosophenproblem) von Anfang an, als ich dort anfing. Die meisten sollten also die Chance gehabt haben, Paralleles Denken anhand von Hardware und Software zu erlernen. Aber wir haben ja die ganzen FHs die den "theoretischen Ballast" nicht unterrichten. Wahrscheinlich haben viele damit das Denken nicht mitbekommen, was nötig wäre. Wie auch immer ... Um die eigentliche Frage zu beantworten: Man sollte FPGAs und die Art, wie man sie programmiert, erst dann durchnehmen, wenn die Basics stehen. Und das sind aus meiner Sicht die Gatter. Wenn man so etwas vor Augen hat, ist das Beschreiben mit Formeln und Umsetzen in eine Schaltung kein Problem. Das bisschen VHDL kann man dann auch noch lernen, denke ich. http://www.96khz.org/oldpages/simplesoundgenerator.htm
Gerd schrieb: > Bei Veranstaltungen gibt es ein Veranstatungsprogramm. Seltsamerweise > gibt es niemanden, der es programmiert hat. Aber sicher gibt es den! Es ist jener, der die Agenda verfasst und gedruckt hat. > Betrachten wir das Programm, sehen wir zeitlich aufeinanderfolgende > Veranstaltungen. Nee. An jedem größeren Theater, Oper und Konzerthäusern gibt es massenweise parallele Veranstaltungen, Aufführungen, Rehearsals und Proben. Das Theaterprogramm z.B. ist immer mein Argument, um denen die so sehr an dem PGENBC*-Syndrom leiden, die Augen aufzumachen, was das Wort eigentlich alles heißt. "Parteiprogramm" wäre noch so ein Beispiel und zwar eins, das ein Paradebeispiel dafür ist, dass etwas "Programm" heißen kann, real aber rein gar nichts (ab)läuft - im Einzelfall 16 Jahre nichts! > leider nicht zwei Vorträge gleichzeitig besuchen. Es muss auch kein Prozessor zwei threads gleichzeitig zu bearbeiten. Er macht sie nacheinander fertig, im Wechsel. Für den Nutzer sieht es so aus, als seinen sie gleichzeitig. Das widerspricht nicht der Parallelität. Man muss hier Parallelität auf Datentaktebene und Systemtaktebene auseinanderhalten. Übrigens auch bei FPGAs. Man kann heute per Streaming-TV und Teams im Übrigens durchaus an zwei V gleichzeitig teilnehmen: Ich schaue oft Fern und programmiere FPGAs :-) Kürzlich habe ich ein Konzert der Berliner Phils im Streaming gehört und gleichzeitig American Football gesehen, weil das ständig von Werbung unterbrochen ist und Dumpfbackenmusik eingestreut wird. Noch ein "programmatisches" Beispiel für Parallelität aus der Musikwelt: Bei vielen klassischen Konzerten gibt es deutlich mehr Stimmen, als Musiker. Gelöst wird das dadurch, dass einer im Wechsel 2 Instrumente spielt. Ich habe sogar schon mal eine Flötistin vom Großen Haus, Richtung kleines Haus gefahren, damit sie dort für eine erkrankte Musikerin einspringen, eine Passage auf der Querflöte spielen und anschließend schnell wieder zum 2. Akt zurück sein konnte. Der "Prozessor" hat hier also sogar den PC gewechselt, um einen thread zu bearbeiten, geil, oder? Mein Aufnahmeequipment lief im Übrigen auch weiter. Voll parallel.* > Kurz Zusammengefasst: Ein Programm ist eine Liste von Anweisungen, die > zeitlich nacheinander abgearbeitet werden. Nur in sehr eindimensionalen Systemen und (Entschuldigung) Köpfen! Ganz ehrlich: Vielen Menschen und vor allem den Programmierern und Softwareentwicklern täte es richtig gut, wenn sie mal aus ihrem Kabuff rauskämen und sich mit ganz anderen Themen und Fragen befassten. Dort kommen sie mit Menschen anderer Denkweisen zusammen, stoßen auf Sonderprobleme und deren Lösungen und können so ihren eigenen Horizont erweitern: Als die Flötistin wieder an ihrem Platz sass, wusste ich, wie ich meinen FPGA-Synth dazu bringen kann, mit einer festen und limitierten Anzahl von Stimmkanälen, eine größere und variable Anzahl von Stimmen zu spielen und wie ich das zu Programmieren habe: Es braucht ein "Programm" mit Markern für die Partitur, die Stimme, die Note, das Instrument, die Position, das Haus und den Takt ... und ein Marker für das "Auto". ----------------------------------------- 1*) PGENBC = "Programmieren-gibt-es-nur-bei-Computern-Syndrom". 2*) moderne DAWs ermöglichen das automatische Starten und Stoppen bei definierten Pausenlängen, um die Dateien automatisch zu schneiden und die filelängen zu begrenzen.
:
Bearbeitet durch User
Gerd schrieb >> Kurz Zusammengefasst: Ein Programm ist eine Liste von Anweisungen, die >> zeitlich nacheinander abgearbeitet werden. Jürgen S. >Nur in sehr eindimensionalen Systemen und (Entschuldigung) Köpfen! Hier mag es hilfreich sein, sich die Definition eines Computerprogramms in der Wikipedia genauer anzusehen: "Ein Computerprogramm oder kurz Programm ist eine den Regeln einer bestimmten Programmiersprache genügende Folge von Anweisungen" https://de.wikipedia.org/wiki/Computerprogramm Was allerdings noch nichts über die Parallelität der Ausführung von Programmen auf einem Computer aussagt. Jürgen S. >Ganz ehrlich: Vielen Menschen und vor allem den Programmierern und >Softwareentwicklern täte es richtig gut, wenn sie mal aus ihrem Kabuff >rauskämen und sich mit ganz anderen Themen und Fragen befassten. Dort >kommen sie mit Menschen anderer Denkweisen zusammen, stoßen auf >Sonderprobleme und deren Lösungen und können so ihren eigenen Horizont >erweitern: Die Probleme des Denkens in parallelen Abläufen haben auch mit dem Denken der Mathematiker des schrittweisen Rechnens und der Entwicklungsgeschichte der Mikroprozessoren zu tun, die durch die Anzahl der realisierbaren Transistoren beschränkt waren. Computer sollten ursprünglich zuallererst den Menschen die Mühsal der händischen Berechnungen abnehmen und waren ursprünglich nicht für andere Aufgaben vorgesehen. In der Robotik, in der ein Roboter alle möglichen Sensoren und Aktuatoren parallel ansteuern müssen, gab es schon gleich zu Anfang die Idee der parallelen Verarbeitung. Wenn du ein LabView-Programmierer wärest, würdest du gar nicht auf die Idee kommen, dass es eine "Nichtparallelität" bei der Programmausführung gibt. Die Beschränktheit der Nichtparallelität sind in den Denkmustern zur LabView-Programmierung überhaupt nicht vorhanden. Außer in speziellen Ausnahmefällen hat man mit den Problemen, die in gewöhnlichen listenbefehlsorientierten Programmiersprachen vorhanden sind, nichts zu tun. Es ist übrigens interessant, dass die heutigen Schüler mit "Scratch" als ablauforientierte, graphische Programmiersprache heutzutage schon in einem Rutsch Parallelität und Objektorientierung lernen. https://scratch.mit.edu/projects/358795881/editor/
Jürgen S. schrieb: > Aber wir haben ja die > ganzen FHs die den "theoretischen Ballast" nicht unterrichten. Hehehe, lass' mir die FHs in Ruhe. Da kommt (meist) eine solide Ausbildung raus, die einem durch das gesamte Berufsleben hilft (Du wirst dir denken können, wo ich meine her habe?). Allerdings bin ich auch der (möglicherweise etwas "altmodischen") Ansicht, dass ein (Ingenieurs-) Studium keineswegs dazu da ist, "fertige" Ingenieure zu konfektionieren, sondern Menschen mit ausreichend Grundlagen auszustatten, um sich schnell in nahezu beliebige technische Themen einzuarbeiten. Die müssen nicht können, aber wissen, wie sie flott zum Können kommen. Nach meiner persönlichen Erfahrung ist ein guter Ingenieur hauptsächlich ein guter, schneller Lerner. Eben jemand, der sich mit dem was er weiss, etwas, was er nicht weiss, schnell erschliessen kann. Das mag aber durchaus daran liegen, dass es in meiner Generation noch kein wirklich stabiles IT-Berufsbild gab, praktisch sämtliche Entwickler (mein erster Job war bei einem 3D-CAD Hersteller) waren Quereinsteiger: Mathematiker, Maschinenbauingenieure, Elektrotechniker und nur ganz wenige "echte" Informatiker und von denen wusste jeder was, was der andere dringend brauchte.
Markus F. schrieb: > Hehehe, lass' mir die FHs in Ruhe. Da kommt (meist) eine solide > Ausbildung raus, die einem durch das gesamte Berufsleben hilft (Du wirst > dir denken können, wo ich meine her habe?). Wenn ich so einen Unsinn wieder lese, dass FHs "praktischer" ausbilden, nur weil sie viel Theorie weglassen und damit den Schwerpunkt verschieben. Diese abgedroschene Floskel scheint man ganzen Generationen in den Kopf geschossen zu haben. An der Uni lernst du EXAKT das gleiche- nur eben von den komplizierten und mathematisch anspruchsvollen Dingen deutlich weniger. Und wie "praktisch" die FH-ler und Bachelorenten damit wirklich sind, konnte ich gerade heute wieder lernen: Katastrophal zusammengestrickte Lösungen beim Zugriff auf den FPGA, sowohl im Treiber als auch im handling der Anfragen an das interne RAM im FPGA selber. Da rennen die kompliziertesten state machines um parallel eintreffende Daten zu managen und zu speichern, nehmen sich dabei gegenseitig die Bandbreite weg. Das Ergebnis sind totale Blockaden! Diese "Praktiker" haben einfach große Wissensdefizite und lösen Probleme mit dem Holzhammer, statt auf das zurückzugreifen, was andere vor ihnen längst ausgedacht haben. Die möglichen Probleme und Aufgaben bei solchen dynamischen parallelen Prozessen sind nämlich allesamt hinlänglich bekannt, erörtert, durchdacht, klassifiziert, haben Namen und Nummern. Es gibt für alles fertige Konzepte, wie man sie mit Synch-messages, Semaphoren, pipelines und Vorrangstufen löst, worauf jeweils zu achten ist und wie wann was eingesetzt werden muss oder was gfs. auch weggelassen werden kann. Das alles wird in einem soliden vollständigen Informatikstudium bis ins letzte durchgekaut und an vielen "Praktischen" Beispielen eingeübt und abgeprüft, während es in den vereinfachten Studiengängen nur gestreift wird. Solche Probleme lassen sich in der Regel mit ausreichenden Denkaufwand mit sehr wenig Code und Aufwand lösen- aber nein, den FPGA und das Zugriffskonzept machen 2 FH-Ingenieure und ein Informatik-Bachelor, die vom Parallelrechnen nur die Grundbegriffe kennen und sich selber eigene wilde Lösungen ausdenken, auf die sie auch noch stolz sind, weil sie diese komplizierte Aufgabe gepackt haben. Markus F. schrieb: > sondern Menschen mit ausreichend Grundlagen auszustatten Das wäre schön, wenn das so wäre. Da die Ausbildung an FHs aber meistens deutlich kürzer ist, erklärt sich von selber, wer mehr Grundlagen zum Weiterlernen hat.
Krtiker schrieb: > Wenn ich so einen Unsinn wieder lese, dass FHs "praktischer" ausbilden, > nur weil sie viel Theorie weglassen und damit den Schwerpunkt > verschieben. wo genau hast Du das gelesen?
In dem zitierten Satz, dass da ein solide Ausbildung bei rauskommt. Klingt so, als sei es anderswo unsolide. Ist mir aber Wurscht. Eines was mir noch aufgefallen ist? Markus F. schrieb: > Das mag aber durchaus daran liegen, dass es in meiner Generation noch > kein wirklich stabiles IT-Berufsbild gab, Was ist denn das für eine Generation? Informatik und IT gibt es seit 30 Jahren.
Phew. Also die ganze Diskussion (nur diagonal gelesen) wiederspiegelt eigentlich das Problem in der Lehre: Es wird sich nicht richtig fokussiert. Um die Unzulänglichkeiten der hierzulande nun halt leider vorherrschenden HDL-Konzepte wird an vielen Hochschulen zu 80% herumgeeiert, Konzepte 'neu erfunden' (von Robei über webbasierte HDL zu VHDP usw.), gezielt zwischen Hardware und Software getrennt, dann wieder alles für HLS zusammengewürfelt. Danach ist den meisten Azubis immer noch nicht klar, wie sie in die Innereien schauen können. Schlussendlich ist jede Art der Programmierung auf folgendes runterzukochen: - Aus einer formalen Notation in einer beliebigen Programmiersprache (dazu zählen wir auch VHDL) entsteht ein Objektcode (Netzliste, Bytecode oder Assembly) - Jeder Azubi muss schlussendlich per Ausprobieren und Blick in die Innereien ein Gefühl dafür bekommen, wie aus einer programmatischen Beschreibung (in einem gewissen Stil) in besagter Sprache welches Objekt erzeugt wird. Daran richtet sich die Art des Programmierens. Eine funktionale Beschreibung die sich pur an einer Abarbeitung eines Threads orientiert, wird von einem klassischen FPGA-Synthesetool nicht umgesetzt (obwohl das durchaus ginge, siehe auch diverse Arduino-Versuche wie VHDP). C-Programmierung ist aber nicht wie Forth- oder deutlich parallelitätsorientierte Occam-Programmierung. Daran lassen sich auch die Unzulänglichkeiten (oder das komplette Scheitern) von V* HDL als "Beschreibungssprachen" messen. Haskell oder Scala können deutlich mehr, sitzen aber nach wie vor in einer in der breiten Masse wenig vermittelten Nische der funktionalen Beschreibungen. Da könnte man grundsätzlich eine Programmiersprache/Simulationssprache als zur Hardwareentwicklung ungeeignet bezeichnen - gäbe es keine Anforderungen an Revisionskontrolle oder formale Verifikation. Nichtsdestotrotz wird auch bei grafischen Frickellösungen wie LabVIEW FPGA-backend HDL als Zwischenergebnis erzeugt, allerdings nicht in der lesbaren (oder portablen) Form einer funktionalen Beschreibung. Die Designmethode fällt allerdings eher unter abstrahierten Schaltungsentwurf anstatt Programmierung (let aside LabWindows). Als ehestes würde ich noch `Smalltalk` oder `blockly`-Ansätze (gibt's wohl auch für VHDL) als grafisches Programmieren ansetzen. Somit kommt man an V* HDL als Transfer- und Simulationssprachen allenfalls nicht vorbei, wobei das Opensource-Multitool `yosys` diese Bastion allmählich bricht. Für Entwurf komplexer Designs allerdings gibt es schlicht deutlich effizientere Methoden der syntaktischen Beschreibung, kaum einer entwirft noch ernsthaft komplexe Prozessrechner SoCs bare metal in VHDL oder Verilog. Genau da fehlen hierzulande Leute, die über den Tellerrand schauen können, sich in moderner Software-Methodik auskennen (keep it simple) und keinen Unterschied mehr zwischen HW und SW machen oder sich gar in Begrifflichkeiten/Befindlichkeiten verzetteln. Und leider geht auch der Trend bei einigen europäischen FH/TUs Richtung Abschaffung der harten Grundlagenkurse ("Assembler ist heutzutage total unnötig") und der Arbeitsmarkt ist gesättigt mit Ingenieuren, deren eigentliches Können sich fortschreitend schlechter seitens HR einschätzen lässt. Noch schlimmer wird es, wenn an den HS gezieltes Lobbying betrieben wird, um die Studenten frühzeitig auf die Vendor-Tools zu eichen und OpenSource-ist-untauglich zu propagieren.
Fitzebutze schrieb: > kaum einer entwirft noch ernsthaft komplexe Prozessrechner > SoCs bare metal in VHDL oder Verilog Das liegt aber vorwiegend daran, dass es SofCores in Massen gibt, die sich bereits selber ausgedünnt haben, weil es sehr viel braucht, um dort effizient zu arbeiten, ein OS draufzumachen und allem pipapo. Da geht man eben den Weg und nimmt das, was der Hersteller an SoftCores anbietet. Keiner hat die Zeit sich mit einem Spezialprozessor zu befassen sondern nutzt möglich viel von Vorhandenem aus. Also bleibt nichts über, außer NIOS und MICRO. Arbeitet noch jemand mit PICO? Und: Die Ansprüche steigen, daher haben X und A sich schon vor Jahren die CPUs als hardcore reingezogen. Und auch da wird ausgedünnt, weil die user das machen, was sie können und gerne bei einer Plattform bleiben. Das waren und sind die ARM-Prozessoren und nicht SPARK oder PowerPC.
Yalu X. schrieb: > Ich glaube eher nicht. Das "ja-klar-kann-ich"-Problem wird IMHO nicht > (auch nicht ansatzweise) durch Anpassung der Begrifflichkeiten > gemindert. Na doch. Dann würde dem Radfahrer schon begrifflich klargemacht, das Automobilieren was völlig anderes ist...
Krtiker schrieb: > Und auch da wird ausgedünnt, weil die > user das machen, was sie können und gerne bei einer Plattform bleiben. Nö, der Grund fürs Ende von Virtex-II Pro war die miesse Ausbeute und geringe Nachfrage. Und der FPGA-markt (Telecom) verlangte mach Multigigabit-Transceiver und nicht nach einer Desktop-CPU für housekeeping-tasks. Der Virtex E war ein völliger Rohrkrepierer, erst mit Virtex-5 (und Softcore) ging es wieder aufwärts.
Krtiker schrieb: > Das liegt aber vorwiegend daran, dass es SofCores in Massen gibt, die > sich bereits selber ausgedünnt haben, weil es sehr viel braucht, um dort > effizient zu arbeiten, ein OS draufzumachen und allem pipapo. Da geht > man eben den Weg und nimmt das, was der Hersteller an SoftCores > anbietet. Ich fürchte das wird in zunehmendem Masse unbeliebter, wenn der Code portabel (unabhängig von der Zielarchitektur) gehalten sein oder in Verilog sowie auch VHDL ausgegeben werden muss. Da könnte man lm32 nehmen, gibt aber eine Menge anderer Gründe, einen RISC-V SoC mit Opcode-Erweiterungen und allenfalls Coprozessor (die sind letzthin der Knackpunkt) zu entwerfen und von AXI- wie Linux-Overhead und generell Vendor-Lock-In abzusehen.
Gerd schrieb: > Hier mag es hilfreich sein, sich die Definition eines Computerprogramms > in der Wikipedia genauer anzusehen: Nein, hilft es nicht, denn erstens ist die Definition in der Wikipedia nicht vollständig formuliert und zweitens machst du einen logischen Denkfehler beim Argumentieren: Du engst den Begriff "Programm" ein, indem du auf die Teilmenge "Computerprogramm" verweist, ziehst dir von dort die eingeschränkte Erklärung, um sie dann auf den allgemeinen Begriff zu extrapolieren. Frei nach dem Motto: Glasuren werden immer in einem flüssigem Zustand aufgetragen, weil Kuchenglasuren so aufgetragen werden. Merkst du, was du machst? Das ist mit Verlaub ein ziemlich gravierender logischer Fehler, für jemanden der anderen etwas beibringen will. :-) Und hier kommt der nächste Denkfehler, gepaart mit einem Lesefehler: Gerd schrieb: > Wenn du ein LabView-Programmierer wärest, würdest du gar nicht auf die > Idee kommen, dass es eine "Nichtparallelität" bei der Programmausführung > gibt. 1a) habe ich nirgendwo eine "Nichtparallelität" unterstellt, schon gar nicht bei dem Thema Programm, sondern argumentiere exakt gegensätzlich, wenn du meinen Beitrag nochmal lesen möchtest 1b) wäre ein "Nichtparallelität" nicht zwingend das Gegenteil von sequentiell, wie du es offenbar siehst 2) ist ausgerechnet Labview nicht geeignet, jemanden den Unterschied zwischen PAR und SEQ zu offenbaren, weil in einem grafischen Programmiersystem alle Funktionen gleichzeitig evident sind, aber nicht 100% sichtbar ist, auf welcher Ebene sie auch parallel ausgeführt werden. Letztlich wird nämlich das Meiste, was in LV scheinbar parallel ist, von den CPUs auf dem PC sequenziell abgearbeitet. Ich kenne im Übrigen LV recht genau, weil einige meiner Kunden das einsetzen und kann gut einschätzen, inwieweit es zum FPGA-Entwickeln oder generell zum Aufbauen von Messsystemen geeignet ist. Was ich mal definitiv sagen kann, ist dass es NICHT dazu geeignet ist, Anfängern paralleles Denken beizubringen- zumindest nicht in der Weise, dass sie damit irgendwann in der Lage wären, paralleles Arbeiten in CPUs und FPGAs zu verstehen, geschweige denn, Programme dafür zu entwickeln - es sein denn mit den eingeschränkten Möglichkeiten von LV.
Gerd schrieb >Hier mag es hilfreich sein, sich die Definition eines Computerprogramms >in der Wikipedia genauer anzusehen: >"Ein Computerprogramm oder kurz Programm ist eine den Regeln einer >bestimmten Programmiersprache genügende Folge von Anweisungen" https://de.wikipedia.org/wiki/Computerprogramm Jürgen S. >>Du engst den Begriff "Programm" ein, indem du auf die Teilmenge >>"Computerprogramm" verweist, ziehst dir von dort die eingeschränkte >>Erklärung, um sie dann auf den allgemeinen Begriff zu extrapolieren. So richtig glücklich bin ich mit der Definition auch nicht. Ich hatte eigentlich nach einer Referenz zum Begriff "programmieren" gesucht, dazu aber leider nichts belastbares gefunden. Das nächstliegende war dann die Wikipedia-Referenz "Computerprogramm". Wenn hier jemand als einen Link- oder Referenz dazu hätte, wäre ich durchaus dankbar. Jürgen S. >Merkst du, was du machst? Das ist mit Verlaub ein ziemlich gravierender >logischer Fehler, für jemanden der anderen etwas beibringen will. :-) >Und hier kommt der nächste Denkfehler, gepaart mit einem Lesefehler: Interessanterweise sehe ich das mit dem Lesefehler ähnlich, allerdings in umgekehrter Rollenverteilung. Wenn du es also noch einmal nachlesen möchtest ( Beitrag "Re: FPGAs in der Lehre" ) Dort hatte ich die Parallelität schon erwähnt. Der Vergleich mit dem Veranstaltungsprogramm passt eigentlich recht gut zur optischen Darstellung in Scratch: dort kann man auch zwei Abläufe parallel zeichnen, die dann auch parallel laufen.
Gerd schrieb: > So richtig glücklich bin ich mit der Definition auch nicht. Ihr diskutiert ja immer noch um völlig realitätsferne Definitionen anstatt euch um die Qualität der Lehre Gedanken zu machen. Naja, wenn es euch weitaus wichtiger ist, die ultimative Abgrenzung von eurem Begriff vom "Programmieren" vom Rest der Welt zu finden als daß ihr euch darum bemüht, die Sparte der FPGA's und anderen programmierbaren Logik-Bausteinen den jungen Leuten zu vermitteln, dann ist das eben ein weiterer Beitrag dazu, daß der Horizont des Nachwuchses sich auf solche Dinge wie "Digitalwrite" und "millis" konzentriert und der technische Fortschritt woanders stattfindet. W.S.
Jürgen S. schrieb: > Es muss auch kein Prozessor zwei threads gleichzeitig zu bearbeiten. Er > macht sie nacheinander fertig, im Wechsel. Für den Nutzer sieht es so > aus, als seinen sie gleichzeitig. Das widerspricht nicht der > Parallelität. Man muss hier Parallelität auf Datentaktebene und > Systemtaktebene auseinanderhalten. Übrigens auch bei FPGAs. Eben. "Parallelität ist nicht ganz der passende Begriff für diese Besonderheit beim FPGA-Entwurf, die sich garnicht oder nur schwer mit C-nachgestellten Konstrukten beschreiben lässt. Passend wäre "Datapath". Während der Datenpfad bei einer (General Purpose) CPU fix ist, passt man sich diesen beim (kundenspezifischen) Digitalentwurf als erstes an die Anforderungen an. Dann optimierten man diesen in dem man mal eine ASAP und eine ALAP Resourcenallocation annimmt und so den finalen (weil effizienten) Control/DataFlußGraph (CDFG) findet. Und dann erst beginnt die Implementierung in VHDL. https://cse.usf.edu/~haozheng/teach/soc/slides/control-data-flow.pdf
Gerd schrieb: > Interessanterweise sehe ich das mit dem Lesefehler ähnlich, allerdings > in umgekehrter Rollenverteilung. Weil du verschwommen argumentierst und dich in deinen eigenen Beiträgen verhaspelst: DEIN Einwand war, ICH hätte eine angebliche Nichtparallelität beim Programmieren aufgeworfen, was aber nicht stimmt und du nur falsch verstanden hast. Seltsamerweise zitierst du DICH, um das nachzuweisen. Richtig aber wäre es, MICH zu zitieren und zwar mit einem Beitrag, wo das angeblich durchklingt, was du mir angekreidet hast. > Gerd schrieb: > So richtig glücklich bin ich mit der Definition auch nicht. Was es noch unlogischer macht, es als Argumentationshilfe beizuziehen.(?) Du argumentierst also mit Aussagen, die erstens inhaltlich nicht passen und zweitens von dir selber sogar als formell unzureichend eingestuft werden. Wenn solche Leute anderen Logik(-schaltungen) erklären wollen, kann man nur kapitulieren. :-) Ich bin da jetzt raus. Wie sagte einst Herr Drosten: Ich habe Besseres zu tun :-) W.S. schrieb: > Ihr diskutiert ja immer noch um völlig realitätsferne Definitionen > anstatt euch um die Qualität der Lehre Gedanken zu machen. Naja, sinnvolle Definitionen für Begriffe sind aber schon irgendwie wichtig, wenn es um Lehre geht, finde ich. Die meisten Sachen sind im Übrigen auch geklärt. Es hören nur viele nicht genau hin, wenn sie es selber lernen, vergessen und misverstehen es und geben es dann falsch weiter. In den Lehrbüchern sind viele Dinge, über die sich Halbwissende herumstreiten, längst gekärt und durchaus geradlinig und richtig dargestellt. Es reicht manchmal aber schon, etwas minimal falsch zu lesen und zu kommunizieren. Nehmen wir das klassische Beispiel für die Begriffe: True <-> False Logisch 1 <-> Logisch 0 High <-> Low Drei verschiedene Begriffsebenen für ähnliche Dinge aber auf unterschiedlichen logischen Ebenen, nämlich Funktion (Verhalten), Realisation (Codierung) und Physik (Pegel). Ist in allen Büchern über Digitaltechnik, die ich kennen, richtig und sauber getrennt erklärt. Trotzdem vermischen es 2/3 aller Digitaldesigner und verwenden es falsch. Inklusive der Firma Xilinx. Das Ergebnis sind (not Resets), die als "low aktive Signale" deklariert werden.
Mcn schrieb: > Passend wäre "Datapath". Ja, dabei es allerdings so, dass bei komplexeren Anwendung der data path mehrdimensional ist, insbesondere, wenn man resourcen sparen möchte. Die Mimik ist vom Prinzip genau dieselbe wie in einer völlig virtuellen Datenpfadvielfalt eines C++ System- nur mit dem Unterschied, dass der FPGA 2 Raumdimensionen hat, einige davon zu ersetzen: Während die CPU Datenpfade nur in einer Dimension auf mehrere Cores und Threads verteilen kann, besitzt der FPGA Fläche und Struktur in der Breite, also für eine Vervielfachung durch Mehrfachinstanziierung und auch in der Tiefe durch pipeline-Architekturen. Diese haben beide das Potenzial, virtuelle Datenpfade aufzunehmen und das obendrein an unterschiedlichen Stellen des design in unterschiedlicher Konfiguration. Ein Beispiel dafür hatte ich hier mal gepostet: Beitrag "Re: Effizienz von MATLAB und HLS bei VHDL" Das ist mit dem klassischen kontrollierten Datenpfad nur ansatzweise erklärt, weil der aus dem, was ich Taktebene nenne, einfach per enable die Datentaktebene ausmaskiert. Das reicht deshalb nicht, weil z.B. die Randbedingungen möglicher loops nicht definiert werden und auch nicht erklärt wird, welche Modelle der Dateneinspeisung und Rückopplungen für Iterationen und Rekursionen exisitieren. Ein kontrollierter Datenpfad, so wie er üblicherweise gelehrt wird, hat die Option, jedes Modul zu jedem Zeitpunkt an beliebieger Stelle anzuhalten. Das schafft maximale Flexibilität, reduziert aber die Möglichkeiten eines FPGA auf die Vorgehensweise einer dynamisch sequenziellen Arbeitsweise, wie sie in Prozessoren bekannt ist. Damit wird der FPGA auf CPU-Niveau abgebremst und automatisch ineffektiv. Das wird man nur dort einsetzen, wo es eben nicht anders geht. Das Thema FSM hatte ich dazu oben schon eingeworfen: Diese realisieren jeden Schritt parallel, arbeiten aber immer nur einen möglichen Schritt "an einer anderen Stelle ab" und das macht nur Sinn, wenn die FSMs klein sind. Ansonsten wäre das Virtualisieren mit einer CPU effektiver. Oder man hat eben mehrere Prozesse, die von derselben FSM abgearbeitet werden: Sobald die Zahl der Prozesse in die Größenordnung der Länge der pipeline kommt, welche sich aus der Vereinigungsmenge der möglichen beschrittenen logischen Pfade ergibt, wird das sehr effektiv und auch super schnell. Solche Konzepte habe ich aber noch nirgends publiziert gefunden - jedenfalls nicht für FSMs. Die die mehrere Kanäle verarbeiten möchte, machen es meistens sequenziell, arbeiten also alle Kanäle nacheinander ab oder bauen die FSMs voll parallel auf. Dazwischen kennen sie nichts.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.