FPGAs in der Lehre

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.

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

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.

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:

>"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

https://de-de.facebook.com/WOTV2/videos/der-streit-um-die-badewanne-ente-k%C3%B6stlicher-loriot-humor/852440344788783/