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 abschaltenBitte 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.