Forum: FPGA, VHDL & Co. neues FPGA buch: "FPGA für alle"


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


Lesenswert?

Ein buch über FPGA entwicklung für ganz anfänger, 472 seiten.
Beispiele mit MAX10 FPGA und VHDPlus.

findet man bei dem verlag:
https://www.bombini-verlag.de/

oder mit google suche nach ISBN: 9783946496359

von He. (Gast)


Lesenswert?

Warum wird dafür geworben? Weil es so gut ist? Oder hat der Autor eine 
Verbindung zum Hause Trentz?

von Gustl B. (gustl_b)


Lesenswert?

Heiko E. schrieb:
> Warum wird dafür geworben?

Warum sollte man nicht dafür werben?

Heiko E. schrieb:
> Oder hat der Autor eine Verbindung zum Hause Trentz?

Was wäre daran verwerflich?
Wir sollten Bücher nur nach ihrem Inhalt beurteilen und nicht nach 
Autor. Trenz machen viel mit FPGAs und kennen sich da wohl aus. Das ist 
eine gute Voraussetzung um ein Lehrbuch zu schreiben.

von Rene V. (creep)


Lesenswert?

Prinzipiell sehr interessant. Ein gutes aktuelles Buch, was vor allem 
den Bastler stärker mit FPGA vertraut macht, würde ich mir gern kaufen. 
Ich hatte es gerade auch schon fast im Amazon Einkaufswagen.

Was mich hier jedoch abschreckt, ist, daß es anscheinend auf ein FPGA 
Board maßgeschneidert ist, was nicht oder nur für Buchkäufer in der 
Stückzahl "1" erhältlich ist.

Ich hätte mir gewünscht, so ein Buch so aufzusetzen, daß man z.B. einen 
Tang Nano oder ein Icebreaker oder ähnliches einsetzen kann und dabei 
ein wenig bei den nötigen Anpassungen an die Hand genommen wird. Dann 
würde ich es sofort kaufen. So zögere ich noch.

von Antti L. (trioflex)


Lesenswert?


von He. (Gast)


Lesenswert?

Gustl B. schrieb:
> Warum sollte man nicht dafür werben?
Das war eine ganz normale Rückfrage ohne Hintergedanken.

Rene V. schrieb:
> was nicht oder nur für Buchkäufer in der
> Stückzahl "1" erhältlich ist.
Wahrscheinlich kannst du es beim Hersteller in Stückzahlen 10 besorgen.
Womit ich nicht gesagt haben will, dass da Taktik hinterliegt.

Wie auch immer. Ich dachte eigentlich, zu FPGAs gäbe es genug Bücher. 
Und: Man sollte in der Lage sein, das Gelernte auf jedes andere board zu 
übertragen. Meine ich naiv.

von Antti L. (trioflex)


Lesenswert?

Ist viel mit Intel MAX10 FPGA und VHDPlus verknüpft und mit IO 
constraints setzen für MAX1000, aber sollte mit jeden MAX10 board gehen 
die beispiele von da.

von Rene V. (creep)


Lesenswert?

Heiko E. schrieb:

> Wie auch immer. Ich dachte eigentlich, zu FPGAs gäbe es genug Bücher.
> Und: Man sollte in der Lage sein, das Gelernte auf jedes andere board zu
> übertragen. Meine ich naiv.

Theoretisch ja. Vor allem, wenn man gelernt hat, wie man VHDL bzw. 
constraints auf andere Boards portiert. Wenn ich das sowieso kann, 
brauche ich das Buch wahrscheinlich auch nicht mehr.

Ich beschäftige mich seit gefühlten 10 Jahren immer mal wieder mit 
FPGAs. Kurz, weil es gerade interessant ist. Trotzdem ist es jedes Mal 
eine Herausforderung, z.B. für Grant Searles Multicomp statt auf dem 
Cyclone3 Chinaboard SRAM-Zellen auf einem Tang zu definieren. Natürlich 
findet man alles im Internet. Aber ein Buch, was auf sowas eingeht und 
erläutert, wie man systemunabhängig bei so etwas vorgeht, findet 
bestimmt Abnehmer und gibt das nötige Rüstzeug.

von He. (Gast)


Lesenswert?

Antti L. schrieb:
> VHDPlus
ohoh ... ein Totes Pferd wird geritten, bis es quietscht!

Niemand in der Industrie benutzt das. Kein Aas.

von DSGV-Violator (Gast)


Lesenswert?

Antti L. schrieb:
> Ein buch über FPGA entwicklung für ganz anfänger, 472 seiten.
> Beispiele mit MAX10 FPGA und VHDPlus.


In welchen Fachzeitschrift sind bisher Rezensionen zu diesem Buch 
erschienen respektive stehen wann dort zu erwarten?

von Antti L. (trioflex)


Lesenswert?

der buch ist 3 tage raus nur, glaube nicht das es Rezensionen schon 
gibt.

Es ist wirklich alles von ANFANG an erkläert für jemanden der von 
elektronik keine Ahnung hat.

Wenn jemand schon ETWAS mit FPGA gemacht hat, dann ist dieses buch nicht 
interessant. Ein D-flip-flop ist auf seite 216, für mich ist es zu 
langsam :)

von DSGV-Violator (Gast)


Lesenswert?

Antti L. schrieb:
> der buch ist 3 tage raus nur, glaube nicht das es Rezensionen schon
> gibt.

Es ist nicht unüblich, das man den Fach-Redaktionen Probe-Exemplare mit 
der Bitte um Vorstellung, kritische Bewertung und Veröffentlichung 
zuschickt.

+++
> Es ist wirklich alles von ANFANG an erkläert für jemanden der von
> elektronik keine Ahnung hat.
>
> Wenn jemand schon ETWAS mit FPGA gemacht hat, dann ist dieses buch nicht
> interessant. Ein D-flip-flop ist auf seite 216, für mich ist es zu
> langsam :)

Also in "meinem" Fachbuch zur Digitalen Schaltungstechnik wird das D-FF 
auf S. 132 beschrieben (Seifart: "Digitale Schaltungen", ISBN: 
3-341-0000148-4).

Es ist also nicht ungewöhlich das zuerst über hundert Seiten Information 
nötig sind, bis die Grundlagen zum Verständniss des primitivsten FF 
vermittelt wurden.

Und es soll nicht Wenige geben, die glauben, man müße sich nicht mit 
Kleinkram wie FF-Typen auseinandersetzen, es genüge ein Crash-Kurs in 
der "Programmiersprache VHDL".

von Antti L. (trioflex)


Lesenswert?

Ich lag etwas falsch, FlipFlop selber ist auf seite 21, auf seite 216 
ist VHDL von flip flop...

Das buch ist meistens REINES VHDL von dem VHDPLus ergänzunge ist nicht 
so viel da drin. Das VHDL teil sollte für beliebige FPGA's OK sein.

von Leon B. (leonbeier)


Lesenswert?

Rene V. schrieb:
> Was mich hier jedoch abschreckt, ist, daß es anscheinend auf ein FPGA
> Board maßgeschneidert ist, was nicht oder nur für Buchkäufer in der
> Stückzahl "1" erhältlich ist.

Hier ein paar Quellen sollte der MAX1000 mal wo ausverkauft sein:
https://shop.trenz-electronic.de/de/TEI0001-04-DBC83A-MAX1000-IoT-Maker-Board-8kLE-8-MByte-SDRAM-8-MByte-Flash-6-15-x-2-5-cm
https://shop.vhdplus.com/product/max1000/
https://www.arrow.de/products/max1000/arrow-development-tools

Heiko E. schrieb:
> Antti L. schrieb:
>> VHDPlus
> Niemand in der Industrie benutzt das.

Die VHDPlus IDE wird vor allem an Universitäten und bei Hobbyanwendern 
genutzt. Studenten und Hobbyentwickler sind auch eine Hauptzielgruppe 
für das Buch. Für Firmenkunden entwickeln wir gerade basierend auf der 
VHDPlus IDE eine neue Software.

von Andreas U. (Gast)


Lesenswert?

Antti L. schrieb:
> sollte bald wieder da sein, keine beschränkung wieviel sie kaufen.

Darf ich hier auch für die von meiner Firma angebotenen FPGA-CPU-Systeme 
werben, wenn ich auf ein Buch verweise, in denen die erwähnt werden?

Oder eine Ausgabe der Elektronik-Praxis? Da war nämlich ein Artikel 
drinne.

Rene V. schrieb:
> Ein gutes aktuelles Buch, was vor allem
> den Bastler stärker mit FPGA vertraut macht,
Fürs Basteln braucht es eigentlich keine Bücher und wenn man mehr 
möchte, als Basteln, sollte man sich mit den Grundlagen und tausenden 
Details befassen.

DSGV-Violator schrieb:
> Und es soll nicht Wenige geben, die glauben, man müße sich nicht mit
> Kleinkram wie FF-Typen auseinandersetzen, es genüge ein Crash-Kurs in
> der "Programmiersprache VHDL".
Ja, so wie ein crash-Kurs bei C reicht.

Wozu studieren wir eigentlich Jahrelang und bilden Berufserfahrung aus, 
wenn man das in einem einzigen Buch erlernen kann.

Das Buch MUSS ich haben.

von Gustl B. (gustl_b)


Lesenswert?

Andreas F. schrieb:
> Darf ich hier auch für die von meiner Firma angebotenen FPGA-CPU-Systeme
> werben

Klar, mach doch.

Andreas F. schrieb:
> Fürs Basteln braucht es eigentlich keine Bücher

Sehe ich genau anders. Auch für das Basteln muss man Dinge lernen und da 
sind Bücher gut geeignet.

Andreas F. schrieb:
> wenn man mehr möchte, als Basteln

Was ist denn mehr als Basteln und worin unterscheidet sich das genau?

Andreas F. schrieb:
> Wozu studieren wir eigentlich Jahrelang und bilden Berufserfahrung aus,
> wenn man das in einem einzigen Buch erlernen kann.

Es wird eben im Studium nicht beigebracht weil die Zeit fehlt. Ein Buch 
ist ein guter Punkt für einen Einstieg. Wer dann mehr will muss ich das 
dann aus weiteren Büchern oder sonst wie beibringen.
Ich behaupte jedenfalls ohne das Buch zu kennen, dass es deutlich über 
das hinausgeht was man im Etechnik Studium zu FPGAs lernt. Und zwar weil 
ich weiß was man in Studium lernt und das ist sehr wenig.

von Andreas U. (Gast)


Lesenswert?

Gustl B. schrieb:
> Es wird eben im Studium nicht beigebracht weil die Zeit fehlt.

Wenn du das, was dir im Studium beigebracht wird, verstanden hast, 
brauchst du keine Bücher, um VHDL-Schaltungen zu entwerfen oder eine 
FPGA-Software bedienen zu lernen, sondern schreibst welche. Ganz im 
Ernst: Wie man ein ISE bedient, erlernt man sukkzessive Schritt für 
Schritt aus der mitgelieferten Anleitung. Wie man VHDL benutzt, erlernt 
man ebenfalls aus Anleitungen, nämlich der Syntax. Wie man Schaltungen 
baut, lernt man im E-Technik Studium.

Jede einzelne dieser 3 Komponenten erfordert das Hineinlesen in mehr als 
ein paar Seiten, die ein Buch mitbringt.  Das ist viel zu oberflächlich.

von DSGV-Violator (Gast)


Lesenswert?

>> Es wird eben im Studium nicht beigebracht weil die Zeit fehlt.
>
> Wenn du das, was dir im Studium beigebracht wird, verstanden hast,
> brauchst du keine Bücher, um VHDL-Schaltungen zu entwerfen oder eine
> FPGA-Software bedienen zu lernen, sondern schreibst welche.

Je nachdem von welchem Studienfach man spricht, Elektrotechnik oder 
Informatik, braucht manLiteratur/beschäftigung um Digitaltechnik mit 
programmierbarer Logig zu konstruieren.

IMHO tun sich Infirmatiker, die ebenden Fokus auf Sprache aber nicht auf 
Technik/Hardware haben deutlich schwerer als Elektrtechnikstudenten, die 
Schaltungstechnik und Computerchnik vom Gatter auf gelernt haben und bei 
denen Computersprachen nur Beiwerk/Tools sind.

von Gustl B. (-gb-)


Lesenswert?

Andreas F. schrieb:
> Wenn du das, was dir im Studium beigebracht wird, verstanden hast,
> brauchst du keine Bücher

Andreas F. schrieb:
> Jede einzelne dieser 3 Komponenten erfordert das Hineinlesen in mehr als
> ein paar Seiten, die ein Buch mitbringt.  Das ist viel zu oberflächlich.

Schöner Widerspruch.

Soll man jetzt lesen oder doch nicht? Und wie sieht es mit Leuten aus 
die das wie ich nicht studiert haben? Ich habe Bücher und Userguides 
gelesen, dann sehr viel selber ausprobiert im Hobby (hier im Forum viel 
gefragt, diskutiert, Projekte vorgestellt, ...), und jetzt mache ich 
beruflich "irgendwas mit FPGA".

von N. B. (charlie_russell)


Lesenswert?

Schön das es eine Leseporbe gibt. Leider nicht mehr selbstverständlich.
Jedoch ist das allen ernstes in Times-New-Roman gesetzt?

von Gustl B. (-gb-)


Lesenswert?

Was ist an der Schriftart schlecht?

von Andreas U. (Gast)


Lesenswert?

Gustl B. schrieb:
> Soll man jetzt lesen oder doch nicht? Und wie sieht es mit Leuten aus

Du sollst die Fachliteratur lesen.

1) Digitaltechnik - von den Digitalprofis
2) VHDl - aus den allgemein zugänglichen Quellen (u.a. Coding Styles)
3) Toolbedienung: vom Toolhersteller

So ist ein Buch also nur eine Zusammenstellung von alten Wissen.

von Gustl B. (-gb-)


Lesenswert?

A. F. schrieb:
> Du sollst die Fachliteratur lesen.

Ja, kann man so sehen. Das macht auch Sinn wenn das Ziel ist Profi zu 
werden. Denn mit so einem Ziel ist man bereit viel Zeit zu investieren.

Aber was wenn man nicht dieses Ziel hat? Anscheinend wollen genug Leute 
"was mit FPGAs" machen, aber keine Profis werden oder zumindest nicht 
direkt so tief einsteigen.
Das ist auch ein Nachteil von der Fachliteratur: Man ist am Anfang 
deutlich langsamer. Klar, man lernt mehr Tiefe, aber kann am Anfang 
längere Zeit nicht selber was machen.

FPGA ist heute (leider oder auch nicht leider) oft ein Zusammenklicken 
von fertigen Komponenten. Man muss kein VHDL können und kein E-Technik 
verstanden haben um ein SoC zu generieren das die gewünschte 
Funktionalität hat. Es gibt für echt viel Zeug fertige IP. Oft auch 
gratis. Gerade im Hobbybereich. Kann man finden wie man will.

Und dann gibt es die Leute die selber auch was schreiben können wollen, 
für das Hobby, aber nicht viel Zeit haben oder auch nicht bereit sind 
die Zeit zu investieren weil ist ja nur Hobby. Und da ist so ein Buch 
eben passend.

von Christoph Z. (christophz)


Lesenswert?

A. F. schrieb:
> 1) Digitaltechnik - von den Digitalprofis

Da gibt es ein paar gute Bücher, die schon im Studium empfohlen werden 
um die generelle Herangehensweise zu lernen.
Dann gibt weniger Bücher, die einem spezifische Sachen beibringen 
können, so wie der Oppenheimer für digitale Signalverarbeitung.

Danach sieht es aus meiner Sicht mau aus.
Man ist dann angewiesen auf Zugänge zu wissenschaftlichen Papers, da 
gibts dann noch was. Ellenlange Abhandlungen zu Multiplizierern (ist ja 
schon auch relevant aber hat schon jemand für mich im DSP Block 
eingebaut) aber wie ich z. B. gescheit eine 2D-Datenverarbeitung 
strukturiere wüsste ich jetzt nichts.

> 2) VHDl - aus den allgemein zugänglichen Quellen (u.a. Coding Styles)

Haha, VHDL und allgemein zugänglich in einem Satz. Du weisst selber gut 
genug, dass das allermeiste das relevant ist oder spannend wäre davon zu 
lernen gehütet wird wie schwarze Magie und Geheimwissen.

Die Gaisler Grlib ist da eine der Ausnahmen.

Ich kenne Opencores und so. Aber das ist komplett kein Vergleich, wie 
wenn ich lesen und erfahren kann wie man z. B. C, C++ oder Jaba macht 
für Milliarden Geräte (Linux, Android, QT).

Unser Coding Style hier ist im Prinzip von der ETH Zürich. Nicht mal der 
ist öffentlich, musst im ETH Netz sein um den zu lesen...

> 3) Toolbedienung: vom Toolhersteller

Um dann danach selber in TCL einen Toolflow zu bauen (und Make, Python 
oder was auch immer drum herum) weil das Schreikrämpfe auslöst, wenn man 
das Produktiv genau so machen soll, wie die das da beschreiben.

von DSGV-Violator (Gast)


Lesenswert?

> Haha, VHDL und allgemein zugänglich in einem Satz. Du weisst selber gut
> genug, dass das allermeiste das relevant ist oder spannend wäre davon zu
> lernen gehütet wird wie schwarze Magie und Geheimwissen.

Häh?

Allgemein Zugänglich heisst nicht "für lau Perlen vor die Säue 
geworfen".
Aber ja, es gibt auch viel Kostenlose VHDL-Bücher ...

* https://tams-www.informatik.uni-hamburg.de/vhdl/vhdl.html
* https://de.wikibooks.org/wiki/VHDL-Tutorium
* https://en.wikibooks.org/wiki/Programmable_Logic/VHDL
* https://www.fpga4fun.com/files/card_vhdl.pdf

Oder man geht als Ingenieurs-student mal in die Fachbibliothek, dann 
kommt man auch an IEEE-Transactions u.ä.

Aber "allgemein zugänglich" heisst eben nicht, das es jeder 
lernunwillige Döddel HDL jemals beherrschen kann. Wahrscheinlich erfüllt 
höchstens 1% der Bevölkerung die Bildungstechnischen Vorraussetzungen 
für die VHDL-Entwicklung. Der Grossteil der Bevölkerung benutz ihre 
EDV-Anlage nur zum "Gamen" und "Onanie Beschleunigung", SCNR

> Und dann gibt es die Leute die selber auch was schreiben können wollen,
> für das Hobby, aber nicht viel Zeit haben oder auch nicht bereit sind
> die Zeit zu investieren weil ist ja nur Hobby.

Mancherorst werden solche Leute -Ohne Anstrengung Meisterwerke 
abkupfern- Schmarotzer genannt.

von He. (Gast)


Lesenswert?

Demnächst bauen also alle FPGAs, weil sie in einem Bastelbuch gelesen 
haben, wie vorgefertige Komponenten zusammengeschoben und verbunden 
werden können.

Wofür dann noch Ingenieure?

von Klaus K. (Gast)


Angehängte Dateien:

Lesenswert?

So, dann rezensiere ich mal dieses Werk:

Das Buch hat sich zur Aufgabe gemacht, die FPGA-Technologie Bastlern 
ohne Fachspezifische Kenntnissen nahe zubringen. Auch wenn sich der 
Autor dafür 480 (sehr gut gemachte) Buchseiten Raum nimmt, gelingt das 
nur, weil der Lehrstoff kräftig zusammenstrichen und "Hilfsmittel" zur 
Vereinfachung einsetzt wurden. Diese Hilfsmittel sind hier:

* Verwendung des (IMHO stark amputierten) VHDLplus syntax statt einer 
"Industrie-etablierten" Fpga-modellierung wie VHDL 2008, Verilog oder 
System-Verilog.

-Verwendung einer (Detail-reduzierenden) Ersatz-Gui (ebenfalls in 
VHDLplus) enthalten) statt der im Industrie-umfeld tatsächlich 
eingesetzten Tool-Chains wie Quartus, Xilinx-ISE oder Vivado

-starke Verkürzungen bis zu Falschdarstellungen  im Bereich Toolchain, 
eben "Compilation" statt dem realen Codeeingabe/-generierung - Synthese 
- mapping -place - route - timing analyse - Programmierfile-Generierung

-weitgehendes Ignorieren komplexerer Schaltungen als Niveau Multiplexer 
und Data-FF

Diese Vorgehensweise erinnert stark an Bücher a la "Arduino 
(Mikrocontroller) for dummies", die sicher geeignet sind, um 
Gelegenheits-Bastlern erste Erfolgserlebnisse zu garantieren. Allerdings 
stellt sich die Frage, ob es für "fortgeschrittene professionelle" 
FPGA-Anwendung nicht eher hinderlich ist, da beispielsweise das 
Teilgebiet "essenzielle IO-Constraints" unter der Einsatz von VHDLplus 
und einem speziellen FPCA-Board versteckt wird.

Die Vorgabe konkreter Hardware eröffnet allerdings auch den Weg zu einen 
tatsächlichen "Hardware Bastel Buch". Im Unterschied zu Büchern aus dem 
"Akademischen Umfeld" wird hier 'richtig gelötet' und Kabel gesteckt, 
aber die tatsächliche Bastelei bleibt auf dem Niveau 
"Mikrocontrollerbasteln mit LED. Was u.U. zu bedauern ist, weil der 
eigentliche Grund für den Einsatz von FPGA's eben solche Anwendungen 
sind, die sich nicht mit einem Mikrocontroller realisieren lassen 
(bspw.: Video, High-End-DSP).

Fazit: Ein gut gemachtes Buch für den Bastler, der einen 
"Ballast"-"reduzierten Zugang sucht, aber kein Ersatz für das Studium 
der Datasheets und Userguides der jeweiligen FPGA-Hersteller wie es für 
den professionellen Einsatz der FPGA-Technoloie nötig ist - also bei 
einen FPGA-Freiberufler macht sich dieses Buch im Regal eher 
kontraproduktiv für die Auftrags-akquise aus.

PS: Der Seitenscan im Anhang soll zeigen, wieviel Gestaltungsaufwand 
(Illustrationen) aufgewandt wurde und das die praktische Anwendung auf 
einem Steckbrett hier wesentlich ist.

von J. S. (engineer) Benutzerseite


Lesenswert?

Klaus K. schrieb:
> So, dann rezensiere ich mal dieses Werk:
> Das Buch hat

Eine Buchrezension über FPGA-Literatur. Was Marcel Reich-Ranicki wohl 
dazu gesagt hätte :-)

Klaus K. schrieb:
> der einen "Ballast"-"reduziert
Diese Phrase kenne ich auch aus der Argumentation "Pro G8" und "Pro 
Dual" sowie "Pro Bachelor".

Nur ist das, was der jeweilige Autor als Ballast deklariert oft einfach 
nötig, um die Hintergründe zu verstehen und es gab ja mal Gründe, es 
einzuführen. So wird das immer dünner und oberflächlicher - mit den 
bekannten Konsequenzen.

Beispiel:
Beitrag "Spannung erhöhen via Dioden?"

: Bearbeitet durch User
von Mark B. (markbrandis)


Lesenswert?

Klaus K. schrieb:
> So, dann rezensiere ich mal dieses Werk

Besten Dank für die Rezension.

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


Lesenswert?

Klaus K. schrieb:
> Der Seitenscan im Anhang
Wenn da beim dargestellten Code-Beispiel einfach mit div/mod 10, 100 und 
1000 drauflosgewerkelt wird, würde mich interessieren, ob im weiteren 
Verlauf auch mal der Ressourcenverbrauch betrachtet und eine 
platzsparendere Lösung vorgestellt wird.

von Rick D. (rickdangerus)


Lesenswert?

Klaus K. schrieb:
> PS: Der Seitenscan im Anhang soll zeigen,
Aua!
Nicht wegen dem Layout, sondern wegen dem Code :-(

von Klaus K. (Gast)


Angehängte Dateien:

Lesenswert?

> mich interessieren, ob im weiteren
> Verlauf auch mal der Ressourcenverbrauch betrachtet und eine
> platzsparendere Lösung vorgestellt wird.


Analyse der Logs von Synthese-/Implementierungstools habe ich nicht im 
Buch entdeckt, es wird aber gezeigt wie man durch VHDLplus hindurch den 
RTLview von Quartus erreicht (für das Beispiel Schieberegister).

Es ist halt ein Ersterfahrungsbuch und kein (vollwertiger) Ersatz einer 
durchdacht gestaffelten Bibliothek aus 
Digital/Computersrchitektur-Lehrbüchern, Mathewerken  und 
Hersteller-Userguides/Application Notes.

PS:
Es gibt auch eine webseite zum Buch, auf der bspw. die Projekte als 
Download liegen. Vielleicht finden sich darin die logs: 
https://www.erik-bartmann.de/?Downloads___FPGA

PSS:
da finden sich in dem zip-Haufen tatsächlich die reports, hab mal das 
für 7 seg angehangen.

von Thomas B. (thomas2)


Lesenswert?

Klaus K. schrieb:
> Die Vorgabe konkreter Hardware eröffnet allerdings auch den Weg zu einen
> tatsächlichen "Hardware Bastel Buch". Im Unterschied zu Büchern aus dem
> "Akademischen Umfeld" wird hier 'richtig gelötet' und Kabel gesteckt,
> aber die tatsächliche Bastelei bleibt auf dem Niveau
> "Mikrocontrollerbasteln mit LED. Was u.U. zu bedauern ist, weil der
> eigentliche Grund für den Einsatz von FPGA's eben solche Anwendungen
> sind, die sich nicht mit einem Mikrocontroller realisieren lassen
> (bspw.: Video, High-End-DSP).

Das ist leider richtig, nur besteht dieses Problem scheinbar bei allen 
Büchern und Kursen zum Thema. Da werden aufwendig die Sprachen 
beschrieben und die Grundlagen der Digitaltechnik wiedergekäut, aber die 
Anwendungsbeispiele beschränken sich dann auf Dinge, die man ohne FPGA 
viel einfacher und preiswerter realisieren kann. Wirklich sinnvolle 
praktische Anwendungen für FPGAs werden irgendwie nirgendwo behandelt. 
Kennst du Literatur, die in dieser Hinsicht besser ist?

: Bearbeitet durch User
von Gerhard H. (Gast)


Lesenswert?

Thomas B. schrieb:
> Wirklich sinnvolle praktische Anwendungen für FPGAs werden irgendwie
> nirgendwo behandelt.

Insofern ist im Titel "für alle" schon ziemlich übertrieben. In aller 
Regel ist ein Mikrocontroller -für alle- die bessere Wahl.

von Papa Schlumpf (Gast)


Lesenswert?

Thomas B. schrieb:
> Wirklich sinnvolle
> praktische Anwendungen für FPGAs werden irgendwie nirgendwo behandelt.
> Kennst du Literatur, die in dieser Hinsicht besser ist?
Die Hochschulbibliotheken sind voll damit. Praktisch jeder Prof, der in 
dem Sektor aktiv ist, hat ein Buch geschrieben.

von Rick D. (rickdangerus)


Lesenswert?

Klaus K. schrieb:
> da finden sich in dem zip-Haufen tatsächlich die reports, hab mal das
> für 7 seg angehangen.
4x lpm_divide:div und 4x lpm_divide:mod
Mach in Summe ein kombinatorisches Gattergrab von reichlich 1200 LUTs.
Das entspräche ca. 300 diskreten 74LS00 um eine vierstellige Zahl für 
eine Multiplex-Siebensegmentanzeige anzupassen.

Ich wiederhole mich:
Rick D. schrieb:
> Aua!

Gerhard H. schrieb:
> In aller
> Regel ist ein Mikrocontroller -für alle- die bessere Wahl.
Sorry. Nein. Nur mit Mikrocontrollern könnte ich die Anforderung an 
meine Projekte niemals erfüllen. Wenn exaktes Timing im Bereich von 
Nanosekunden gefordert ist, kann ich nicht warten bis ein Prozessor mal 
Zeit für meinen Interrupt hat. Auch wenn es darum geht z.B. mehr als 
zwei ADC und DAC-Kanäle mit Sampleraten von 1 MS/s aufwärts zu bedienen, 
wird es mit einem Mikrocontroller eng...

von Klaus K. (Gast)


Lesenswert?

> Wirklich sinnvolle
> praktische Anwendungen für FPGAs werden irgendwie nirgendwo behandelt.
> Kennst du Literatur, die in dieser Hinsicht besser ist?

Spontan fallen mir Branchen-periodika wie die "Elektronik" aus dem 
"Markt &Technik" Verlag ein, die immer mal wieder Beispiele für 
ASIC/FPGA basierte Geräte vostsellen.

Und irgendwann weiss man als Ingenieur/FPGA-Entwickler eben, das in 
manchen Gerätschaften wie Computertomographen, Mobilfunk-Basestations, 
Radar Phase array Technik, Laseransteuerung (Galvanometer), 
Ultraschall-Prüftechnik, Digitaloszilloskope spezialisierte IC stecken, 
weil ein Mikrocontroller eben zu seriel-langsam dafür ist.

Auch nennt man solche IC einfach ASIC und nicht FPGA weil es grad egal 
ist. Prototypen werden gern als FPGA gebaut.

Literatur für diese in FPGA/ASIC realisierten Algorithmen
 findet man dann in der Abteilung "Numerische Rechnen" oder Digitale 
Signalverarbeitung/Nachrichtentechnik etc pp.

Das Xilinx Hausmagazin Xcell ist voll mit solchen Praxisbeispielen und 
ist auch als pdf zugänglich:

https://www.xilinx.com/publications/archives/xcell/Xcell68.pdf
https://www.google.com/search?q=xcell+magazin+xilinx+pdf+download

Altera hatte wohl auch so ein InHouse-Magazin, im US-Bereich findet man 
von dergleichen einiges: 
https://www.magazines007.com/pdf/Design007-Mar2018.pdf

Und spontan an Büchern zu mehr 2praktischen" Problemen:
"The Design Warrior's Guide to FPGAs" - Clive Maxfield
"Hardware/Firmware Interface Design" - Gary Stringham

Deutschsprachig gibt es wenig und manchmal sehr "therielastig":

ISBN: 978-3446212886

Aber vielleicht ist es ja das wesentliche an der Praxis das man diese 
nicht aus Büchern kennen lernen kann. bei Messen wie beispielsweise die 
SPY in zwei Wochen ode der Embedded kann man auch einiges an 
FPGA-Anwendungsgebieten kennenlernen. Und eben "learning by doing".

von Papa Schlumpf (Gast)


Lesenswert?

Rick D. schrieb:
> Mach in Summe ein kombinatorisches Gattergrab von reichlich 1200 LUTs.

Somit könnte der Autor guten Gewissens Anteile am Gewinn der 
FPGA-Hersteller verlangen, weil diese auf diese Weise mehr Fläche 
verkaufen, falls es gelingt, diese Basteltechnik unter den Entwicklern 
zu etablieren. Bei den CPUs ist es genau so gelaufen: Immer mehr 
Hochsprachen und weniger Fokus auf Effizienz und ratzfatz muss der 
nächst teurere Chip bestellt werden.

Vor über 50 Jahren sind Menschen mit 8-Bit-Prozessor-Technik auf den 
Mond geflogen. Alles was gerechnet wurde, war so effizient gemacht, dass 
es nur wenig Silizium bedurfte. Heute ginge das nicht mehr. Der bachelor 
der das System als Thesis bauen würde, lässt sich mit Simulink ein 
fertiges Prozessor-Design zusammenbauen mit allem Pipapo, das den 
fettesten FPGA im Markt beansprucht, um überhaupt anlaufen zu können. Es 
wäre mit USB steuerbar, hätte einen MP3-Player drin und bediente noch 
die Gyrosensoren, um frei im Raumschiff zu schweben. Dazu würde es die 
Zeit als Sprachnachricht verschicken, sich mit 100 irdischen Alexas 
gleichzeitg unterhalten und Kaffee kochen.

Zum Mond käme man damit aber nicht mehr, weil infolge des hohen 
Stromverbauchs nach wenigen Stunden die Batterie leer ist, wenn es sich 
nicht schon total verflogen hat, weil die Software, wie heute üblich, 
voller bugs ist.

von Christoph M. (mchris)


Lesenswert?

E. S. (elektroschlumpf)
26.10.2023 17:18

>Vor über 50 Jahren sind Menschen mit 8-Bit-Prozessor-Technik auf den
>Mond geflogen.

Das erinnert mich an das Gejammer der Softwareentwickler bei der 
Einführung der Computermaus und der graphischen Oberflächen und warum 
diese die Produktivität senken würden (ja, ich habe die Zeit erlebt).
Oder der Übergang von Assembler zu C oder die Einführung von 
Computersprachen mit virtuellen Maschinen im Hintergrund wie Java, C# 
oder Python und deren vermeintliche Ineffizienz.

Die Entwicklung in der Elektronik und Informatik ist schnell und heute 
hat jeder bessere Mikrocontroller KI-Beschleunigungseinheiten eingebaut. 
Darüber könnte man nun auch Jammern oder einfach die Möglichkeiten der 
neuen Technologien verstehen und sinnvoll nutzen lernen und einfach 
akzeptieren, dass sich die Welt weiter dreht und technologisches Wissen 
aus dem Röhrenzeitalter nur noch wenig gefragt ist und schlicht 
veraltet.

von Christoph M. (mchris)


Lesenswert?

Auf lange Sicht gesehen wird sich die FPGA-Entwicklung deren Tools 
ohnehin verändern.

Kommando an ChatGPT: "Schreibe einen Zähler in VHDL"
1
library IEEE;
2
use IEEE.STD_LOGIC_1164.ALL;
3
use IEEE.STD_LOGIC_ARITH.ALL;
4
use IEEE.STD_LOGIC_UNSIGNED.ALL;
5
6
entity Counter is
7
    Port ( clk : in STD_LOGIC;
8
           reset : in STD_LOGIC;
9
           count : out STD_LOGIC_VECTOR(3 downto 0));
10
end Counter;
11
12
architecture Behavioral of Counter is
13
    signal counter_reg : STD_LOGIC_VECTOR(3 downto 0) := "0000";
14
begin
15
    process (clk, reset)
16
    begin
17
        if reset = '1' then
18
            counter_reg <= "0000";
19
        elsif rising_edge(clk) then
20
            counter_reg <= counter_reg + 1;
21
        end if;
22
    end process;
23
    
24
    count <= counter_reg;
25
end Behavioral;

An ChatGPT: "Mache daraus einen 5Bit Zähler"

==>
Um den 4-Bit-Zähler in ein 5-Bit-Modell umzuwandeln, können Sie einfach 
die Größe des counter_reg-Signals auf 5 Bits ändern und den Ausgang 
entsprechend anpassen. Hier ist der aktualisierte VHDL-Code für einen 
5-Bit aufwärtszählenden synchronen Binärzähler:
1
library IEEE;
2
use IEEE.STD_LOGIC_1164.ALL;
3
use IEEE.STD_LOGIC_ARITH.ALL;
4
use IEEE.STD_LOGIC_UNSIGNED.ALL;
5
6
entity Counter is
7
    Port ( clk : in STD_LOGIC;
8
           reset : in STD_LOGIC;
9
           count : out STD_LOGIC_VECTOR(4 downto 0));
10
end Counter;
11
12
architecture Behavioral of Counter is
13
    signal counter_reg : STD_LOGIC_VECTOR(4 downto 0) := "00000";
14
begin
15
    process (clk, reset)
16
    begin
17
        if reset = '1' then
18
            counter_reg <= "00000";
19
        elsif rising_edge(clk) then
20
            counter_reg <= counter_reg + 1;
21
        end if;
22
    end process;
23
    
24
    count <= counter_reg;
25
end Behavioral;

von Klaus K. (Gast)


Lesenswert?

Christoph M. schrieb:
> Auf lange Sicht gesehen wird sich die FPGA-Entwicklung deren Tools
> ohnehin verändern.

* Offtopic
* suboptimaler code da asynchroner reset
* kommentare fehlen komplett
* schlecht wartbarer Code,bspw.:  keine parametrisierte 
bitbreitenänderung (Generic, package, others => '0')

*VHDL code schreiben ist der geringste Teil bei der FPGA Entwicklung.

Für ein ladbares FPGA-design braucht es timing and pinout constraints 
sowie eine passend configurierte Toolchain. Manche scheitern schon an 
der Eingabe des richtigen FPGA-Typ ihres Evalboards.

Ganz zu schweigen vom Erstellen einer Testbench und Simulation mit 
ausreichend hoher Testabdeckung resp. Tiefe.

FPGA-Designs sind eben Hardware-entwicklung und keine 
softwarerum-sourcerei.

von Christoph M. (mchris)


Lesenswert?

Ja die KIs sind noch in ihren Anfängen..

An ChatGPT:
Kommentiere den VHDL-Code des 5Bit Beispiels
Kannst Du einen synchronen Reset hinzufügen?

=>

Hier ist der kommentierte VHDL-Code für den 5-Bit aufwärtszählenden 
synchronen Binärzähler:
1
library IEEE;
2
use IEEE.STD_LOGIC_1164.ALL;
3
use IEEE.STD_LOGIC_ARITH.ALL;
4
use IEEE.STD_LOGIC_UNSIGNED.ALL;
5
6
entity Counter is
7
    Port (
8
        clk : in STD_LOGIC;              -- Takteingang
9
        reset : in STD_LOGIC;            -- Synchroner Rücksetzeingang
10
        count : out STD_LOGIC_VECTOR(4 downto 0) -- Ausgang für den Zählerstand (5 Bits)
11
    );
12
end Counter;
13
14
architecture Behavioral of Counter is
15
    signal counter_reg : STD_LOGIC_VECTOR(4 downto 0) := "00000"; -- Internes Zählerregister mit 5 Bits
16
begin
17
    process (clk)
18
    begin
19
        if rising_edge(clk) then
20
            if reset = '1' then
21
                counter_reg <= "00000"; -- Bei Aktivierung des synchronen Resets den Zähler auf Null setzen
22
            else
23
                counter_reg <= counter_reg + 1; -- Bei steigender Taktflanke den Zähler um 1 erhöhen
24
            end if;
25
        end if;
26
    end process;
27
    
28
    count <= counter_reg; -- Den Ausgang mit dem Zählerstand verknüpfen
29
end Behavioral;

In den Kommentaren werden die verschiedenen Teile des Codes erklärt:

    Die entity-Deklaration definiert die Schnittstellen (Ports) des 
Zählers, einschließlich des Takteingangs (clk), des Rücksetzeingangs 
(reset) und des Ausgangs (count), der den Zählerstand ausgibt.

    Die architecture-Deklaration definiert die interne Funktionsweise 
des Zählers.

    Im Prozessblock erfolgt die eigentliche Zählerlogik. Der Zähler wird 
bei steigenden Flanken des Taktsignals inkrementiert, und bei 
Aktivierung des Resets wird er auf Null zurückgesetzt.

    Schließlich wird der Ausgang count mit dem Wert des internen 
Zählerregisters counter_reg verknüpft, um den Zählerstand nach außen zu 
führen.

Dieser Kommentar soll Ihnen helfen zu verstehen, wie der 5-Bit-Zähler 
funktioniert und wie die verschiedenen Teile des VHDL-Codes 
zusammenarbeiten.

    Das reset-Signal wird nun innerhalb des rising_edge(clk)-Zweigs 
überprüft. Dadurch wird sichergestellt, dass der Reset nur bei einer 
steigenden Flanke des Taktsignals wirksam wird.

    Wenn der synchronische Reset (reset = '1') aktiv ist, wird das 
Zählerregister auf Null zurückgesetzt.

Mit dieser Änderung wird ein synchroner Reset hinzugefügt, der 
sicherstellt, dass der Zähler in einer definierten Weise zurückgesetzt 
wird, und zwar nur bei einer steigenden Taktflanke.

von Christoph M. (mchris)


Lesenswert?

Die Parametriesierbarkeit hatte ich vergessen ..

An ChatGPT:
Kannst du die Anzahl der Zählerbits parametriesierbar machen?

=>
1
library IEEE;
2
use IEEE.STD_LOGIC_1164.ALL;
3
use IEEE.STD_LOGIC_ARITH.ALL;
4
use IEEE.STD_LOGIC_UNSIGNED.ALL;
5
6
entity Counter is
7
    generic (
8
        COUNTER_WIDTH : integer := 5   -- Anzahl der Zählerbits (Standardwert ist 5)
9
    );
10
    Port (
11
        clk : in STD_LOGIC;                  -- Takteingang
12
        reset : in STD_LOGIC;                -- Synchroner Rücksetzeingang
13
        count : out STD_LOGIC_VECTOR(COUNTER_WIDTH - 1 downto 0) -- Ausgang für den Zählerstand
14
    );
15
end Counter;
16
17
architecture Behavioral of Counter is
18
    signal counter_reg : STD_LOGIC_VECTOR(COUNTER_WIDTH - 1 downto 0) := (others => '0'); -- Internes Zählerregister mit COUNTER_WIDTH Bits
19
begin
20
    process (clk)
21
    begin
22
        if rising_edge(clk) then
23
            if reset = '1' then
24
                counter_reg <= (others => '0');  -- Bei Aktivierung des synchronen Resets den Zähler auf Null setzen
25
            else
26
                counter_reg <= counter_reg + 1;  -- Bei steigender Taktflanke den Zähler um 1 erhöhen
27
            end if;
28
        end if;
29
    end process;
30
    
31
    count <= counter_reg; -- Den Ausgang mit dem Zählerstand verknüpfen
32
end Behavioral;

von Klaus K. (Gast)


Lesenswert?

Immer noch komplett Offtopic in Bezug zum Thread-Thema "Re: neues FPGA 
buch: "FPGA für alle"" ->

Starte doch bitte einen neuen Thread unter dem Subject "Mit ChatGPT vom 
dummen Jungen zum FPGA-Experten" o.ä.
Source code als Anhang ist auch besser weiterverarbeitbar als 
Copy-Paste.

Und wie bereits gesagt, VHDL-Code-Generierung ist der kleinste Teil der 
FPGA-Entwicklung.

von Christoph M. (mchris)


Lesenswert?

E. S. (elektroschlumpf)
26.10.2023 17:18

>Vor über 50 Jahren sind Menschen mit 8-Bit-Prozessor-Technik auf den
>Mond geflogen.

Der Vollständigkeit halber sei dies noch angemerkt:

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

Apollo Guidance Computer
..
Der Prozessor arbeitete intern mit 16-Bit-Datenworten (14 Bit Daten, 1 
Überlaufbit und 1 Vorzeichenbit (Einerkomplement)). Bei der Verwendung 
als Programmbefehl waren 3 Bit für den Opcode und 12 Bit für die Adresse 
reserviert.

von Christoph M. (mchris)


Lesenswert?

Und hier noch die schöne Begründung, warum man heutzutage 
leistungsfähigere Prozessoren baut und Programmiersprachen verwendet, 
die in Anführungszeichen "Rechenzeit" verschwenden, die eben nicht mehr 
in einen Prozessor mit 4KiB Ram passen:

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

Software
========

Die Informatikerin Margaret Hamilton vor der ausgedruckten 
Apollo-Flugsoftware, die am MIT von ihr und ihrem Team entwickelt 
wurde[2]

Nachdem die Entwicklung von Software für den AGC ursprünglich im Plan 
und Budget des Apollo-Programms nicht vorgesehen war, arbeiteten 
schließlich über 300 Personen daran.

von Papa Schlumpf (Gast)


Lesenswert?

Christoph M. schrieb:
> waren 3 Bit für den Opcode
Macht 8 Befehle. Die Zahl hatte ich im Hinterkopf. Dann war das ja 
sozusagen, ein RISC :-)

Christoph M. schrieb:
> Nachdem die Entwicklung von Software für den AGC ursprünglich im Plan
> und Budget des Apollo-Programms nicht vorgesehen war, arbeiteten
> schließlich über 300 Personen daran.

Hört sich nach einem Zeitproblem an, weil die Projektleitung gepennt 
hat. Es ist grundsätzlich jede Software auch von einer einzigen Person 
zu machen und daher dürfte diese gewaltige Zahl einfach der Komplexität 
geschuldet sein.

Die Tatsache, dass Prozessoren schneller rechnen, bedeutet nicht, dass 
man deshalb schneller programmieren kann. Das Ausmaß der Verbesserung, 
die man dadurch gewinnen kann, dass einer verschwenderischer mit 
CPU-Leistung umgeht, liegt in der Größenordnung 2-3. Mehr ist da nicht 
zu erzielen.

Zum Chat-Zeug habe ich mich bereits umfassend geäußert. Ein Punkt noch:

Christoph M. schrieb:
> Mit dieser Änderung wird ein synchroner Reset hinzugefügt, der
> sicherstellt, dass der Zähler in einer definierten Weise zurückgesetzt
> wird, und zwar nur bei einer steigenden Taktflanke.

Dass er synchron zurückgesetzt wird, ist nicht von Bedeutung. Die 
Schaltung dürfte so oder so anhalten. FPGAs können sich in dem Punkt von 
realen Schaltungen nicht unterscheiden. Der Knackpunkt ist, dass der 
Reset auch synchron losgelassen wird. Das müsste der Chatter 
kommentieren.

Ich sehe aber schon wohinh das führt:

Der Jung-Softwareentwicklung kloppt nur noch Gelumpe in die IDE, die es 
dann an Google schickt zum kommentieren. Google selber lässt Algorithmen 
drüberlaufen, optmiert den Code und stellt kostenpflichtig umfangreiche 
C-Bibliotheken zur Verfügung, sendet aber nur mittelmäßige Kommentare 
und Erklärungen heraus.

Die Entwickler verdummen weltweit und am Ende muss Google die IT 
liefern. Am Ende steckt überall deren Zeug drin und sie regieren die 
Welt.

Spätestens dann benötigen wir einen Terminator, der in der Zeit 
zurückreist und die Erfinder von ChatGP, Google und Microsoft entsorgt.

von J. S. (engineer) Benutzerseite


Lesenswert?

Klaus K. schrieb:
> *VHDL code schreiben ist der geringste Teil bei der FPGA Entwicklung.
Das ist das Problem. Es wird immer wieder auf die Codierung abgehoben, 
dabei sind diese Standardsachen entweder als IP-Core, als automatisch 
generierbarer Code oder per Copy& Paste verfügbar. Praktisch alles, was 
man so typisch in einem Projekt benötigt, ist oft schon in anderen 
Projekten vorhanden oder habe ich irgendwo rumliegen.

Christoph M. schrieb:
> Hier ist der kommentierte VHDL-Code für den 5-Bit aufwärtszählenden
> synchronen Binärzähler:
Das ist keine Leistung. In jedem VHDL-Code hat es Zähler, die der 
Entwickler nur von einer Ecke in die andere kopiert. Er hat dabei aber 
auch gleich Code in einer Formulierung an der Angel, der dem 
Coding-Style der Firma entspricht und wo die verwendeten Signalnamen zum 
Rest des Projektes passen. Niemand braucht Universal-Code, den man 
anpassen und überarbeiten muss. Ich brauche auch keine standardisierte 
Einladungs-mail, wo ich Sinn, Namen und Datum selber eintragen muss, um 
dann noch den Text individuell anzupassen. Komplett selber tippen ist 3x 
schneller.

von J. S. (engineer) Benutzerseite


Lesenswert?

Klaus K. schrieb:
> Ganz zu schweigen vom Erstellen einer Testbench und Simulation mit
> ausreichend hoher Testabdeckung resp. Tiefe.

Eben, das Denken und Definieren der Struktur im FPGA ist die eigentliche 
Arbeit. Das nimmt einem aber selbst das MATLAB nicht ab, welches ja in 
der Lage ist, nach den gegebenen Definition allen erdenklichen Code zu 
erzeugen und das sogar nach individuellen Vorgaben, die von der Firma 
für die jeweils gültige Branche nach Notwendigkeit erlassen wurden - 
inklusive prefixes, subfixes, Einrückungen und anderer formeller Punkte. 
Aber auch MATLAB braucht den richtigen Input.

Diese Beispiele, die eine angebliche Vereinfachungen und Erleichterung 
propagieren, indem sie Code raushauen, verstellen nur den Blick auf die 
eigentlichen Aufgaben, was dazu führt, dass FPGA-Entwicklung immer mehr 
unterschätzt wird: Man kann das seit Jahren sehen, dass Projektgeber 
immer öfters mit der Info "Ich habe auch was mit FPGAs gmacht" ankommen 
und dann Planungen darlegen, die zeigen, dass die Hauptarbeit das 
Tippeln von Code gewesen sein muss, für Blinkschaltungen, IP-Anbindung 
und einfache Logic.

Das hat aber mit FPGA-Schaltungsentwicklung nichts zu tun. Das ist am 
Ende nur VHDL-Code-Eingabe.

> FPGA-Designs sind eben Hardware-entwicklung und keine
> softwarerum-sourcerei.
Unter "Entwicklung" verstehe ich hauptsächlich erst einmal, das Problem 
zu verstehen und mir auszudenken, welche Signalverarbeitung man dafür 
braucht. Wie sie dann technisch aussieht, ergibt sich dadurch schon zur 
Hälfte und der Rest ist Anpassung an Hardware und geschicktes Umgehen 
mit den Randbedingungen Taktung, Stromverbrauch, Rechenzeit, 
Rechenresourcen, Designsicherheit, technische Redundanz, funktionale 
Sicherheit, Strahlungssicherheit aber auch Entwicklungszeit, 
Entwicklungskosten.

Ich habe bis heute noch bei keinem tool eine Maske gefunden, wo ich 
diese Randbedingungen und ihre gegenseitigen Abhängigkeiten hätte 
eintragen können, damit das tool mit die Lösung dafür ausgibt.

von J. S. (engineer) Benutzerseite


Lesenswert?

Klaus K. schrieb:
> Immer noch komplett Offtopic in Bezug zum Thread-Thema "Re: neues FPGA
> buch: "FPGA für alle"" ->
> Starte doch bitte einen neuen Thread unter dem Subject "Mit ChatGPT vom
> dummen Jungen zum FPGA-Experten" o.ä.

Also ich finde schon, dass es da einen Zusammenhang gibt:

Solche Automatisierungen auf Konzeptebene durch KI oder was auch immer, 
werden meistens von Leuten vorgeschlagen und propagiert, die keine 
tiefgreifende technische Entwicklung betrieben haben und auch nicht 
beherrschen und die gleiche vereinfachende Prämisse finde ich bei 
solchen Büchern: Man schraubt an einfachen Dingen herum und vermittelt 
der Leserschaft, das Thema sei ein Einfaches, indem man das 
Allereinfachste voranstellt. Solche Ansätze führen oft genug dazu, dass 
Personen ohne tiefes Verständnis drauflos basteln und sich subjektiv 
kompetent fühlen, aber kein tiefes Wissen aufbauen. Am Ende haben sie 
einfach den falschen Fokus und genau bei diesen findet man die Haltung, 
möglichst viel zu automatisieren und eine Offenheit gegenüber 
automatischer Code-Erzeugung und auch KI. Unterhält man sich mit 
erfahrenen FPGA-Entwicklern, winken die bei beidem ab.

Automaten können Tippfehler verhindern, aber keine Denkfehler und schon 
gar nichts Planungsmängel. Ein Kriterium, das die KI nicht kennt, weil 
es ihr für das aktuelle Problem nicht als nötig kenntlich gemacht wurde, 
da es Teil einer Definition ist und eben nicht durch eine 
Schlussfolgerung erzeugt wurde, die die KI oder ein Mensch herleiten 
kann, kann sie grundsätzlich nicht berücksichtigen. Die Definition muss 
aus den Randbedingungen gezogen und gegeben werden und irgendjemand muss 
sie ins Projekt/Design einleiten.

Und da haben wir die Dualität zum Nicht-KI-Mensch mit Bastelerfahrung: 
Es fehlt der Blick für das Wichtige und Richtige. Am Ende gibt es einen 
Code, der aber das falsche Problem löst. BTST

Wenigstens liefert die KI ein weiteres Gegenargument für die in dem 
Zusammenhang auch zu nennenden "programming challenges, bei denen ich 
schon zweimal in jüngster Zeit angefragt wurde, doch bitte mitzumachen, 
um ein "Projekt zu gewinnen". Diese sind doppelt weit weg von dem 
Nötigen, weil das simple Tippen ja bald durch die KI erledigt werden 
soll (Haha) aber das wichtige, das Denken eben nicht erledigt. Eine 
schwäbische Instrumentenfirma, die mich bat, doch da mitzumachen, hat 
von mir als Gegenantwort eine Denk-Challenge bekommen, mit der Aufgabe, 
ein konkretes Rechen-/Schaltungsproblem zu lösen. Ich warte bis heute 
auf die Antwort, dass sie mir erklären, wie man das macht.

von Christoph M. (mchris)


Lesenswert?

>Christoph M. schrieb:
>> Hier ist der kommentierte VHDL-Code für den 5-Bit aufwärtszählenden
>> synchronen Binärzähler:
> J. S. (engineer)
>Das ist keine Leistung. In jedem VHDL-Code hat es Zähler, die der
>Entwickler nur von einer Ecke in die andere kopiert.

Selbstverständlich ist es klar, dass das von ChatGPT gezeigt das Ende 
der KI-Entwicklung darstellt und es keinesfalls wird sich die 
Softwarewelt die nächsten 5 Jahre gravierend verändern. 
Selbstverständlich sind die milliardenschweren Investitionen der großen 
Konzerne wie Microsoft, Google Amanzon und ähnliche verlorenes Geld. 
Selbstverständlich benutzt kein Entwickler Microsofts Co-Pilot und die 
Entwicklungstools der großen FPGA Hersteller werden niemals 
benutzerfreundlicher sein als im heutigen Zustand. Und 
selbstverständlich können die FPGA-Entwickler weiterhin ihre veralteten 
Methoden benutzen und sollten sich keineswegs mit neuartigen 
Technologien befassen. Schließlich ist die FPGA Entwicklung in 
Deutschland so kostengünstig und kann nur von deutschen Spezialisten 
durchgeführt werden, sodass es keinerlei Grund gibt, diese nach Indien 
zu verlagern. Schließlich sieht man keinerlei Youtube-Videos über 
indische FPGA-Entwicklung und es gibt überhaupt keinen Grund zur 
Produtivitätssteigerung durch neuartige Tools.

von Christoph Z. (christophz)


Lesenswert?

Christoph M. schrieb:
> und die
> Entwicklungstools der großen FPGA Hersteller werden niemals
> benutzerfreundlicher sein als im heutigen Zustand.

Ist seit 20 Jahren tatsächlich so. Alles andere erkenne ich als Ironie 
(Und bin weitestgehend deiner Meinung) :-)

Generell spannender als die Diskussion um ChatGPT in diesem Bereich 
finde ich, was bei den Chiplayout Tools passiert:
https://www.tomshardware.com/news/ai-chip-layout-tool-has-helped-design-over-100-chips

https://www.forbes.com/sites/karlfreund/2021/08/09/using-ai-to-help-design-chips-has-become-a-thing/

https://www.eenewseurope.com/en/synopsys-tools-tape-out-2nm-chips-at-tsmc/

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


Lesenswert?

Christoph M. schrieb:
> =>
> ... viele Zeilen Code mit einem std_logic als Zähler ...
Lass den Automaten doch mal was abseits von Copy&Paste machen. Frag ihn 
mal nach einem Lauflicht oder einem DCF-77 Decoder.

Christoph M. schrieb:
> Selbstverständlich
... haben schon zu jeder Zeit Menschen sich und ihre Fähigkeiten 
überschätzt.

> keinesfalls wird sich die Softwarewelt die nächsten 5 Jahre gravierend
> verändern.
Das mit den 5 Jahren und der Technikgläubigkeit kenne ich aus dem 
Beitrag "Re: Alle Teslas sollen per Software-Update zu vollautonomen Fahrzeugen werden können - realistisch?"

Und allein den blinden Glauben daran, dass Megakonzerne die Technik von 
sich aus so voranbringen, dass das Ergebnis (m)einem gewünschten Ziel 
entspricht, finde ich gewagt.



Zurück zum Buch und noch ein Wort zum ersten Satz der oben im 
Beitrag "Re: neues FPGA buch: "FPGA für alle"" gescannten 
Buchseite: da steht verniedlichend, dass im FPGA "über eine if-Anweisung 
ein Code mit 100 Hz aufgerufen" werde. Ein sehr viel falscheres Bild von 
Hardwaredesign kann man kaum vermitteln.

: Bearbeitet durch Moderator
von Andreas U. (Gast)


Lesenswert?

Gustl B. schrieb:
> Denn mit so einem Ziel ist man bereit viel Zeit zu investieren.
> Aber was wenn man nicht dieses Ziel hat?
Dann wird es auch nichts mit dem "Profi werden" oder dem "FPGA für 
alle".

Mit einfachen Büchern für alle werden Anfänger nur in die falsche 
Richtung geschickt. Siehe auch hier:

Lothar M. schrieb:
> ein Code mit 100 Hz aufgerufen" werde. Ein sehr viel falscheres Bild

Der Code wird nur in der Simulation mit 100Hz aufgerufen und dann auch 
nur mit den internen virtuellen 100Hz / Zeitskalierung mit der der 
Simulator läuft. Das alles ist also irgendwie richtig und zugleich 
falsch. Die Realität bleibt dem Leser verborgen. Streng genommen wird 
sie durch solche Darstellungen sogar zugenagelt.

von Andreas U. (Gast)


Lesenswert?

Christoph M. schrieb: eine Menge Phrasen, die wenig 
Zusammenhang haben und der Ordnung bedürfen:

> und es keinesfalls wird sich die
> Softwarewelt die nächsten 5 Jahre gravierend verändern.
Die Softwarewelt wird sich selbstredend ändern, aber die Versuche, 
Softwareerstellung zu vereinfachen beziehen sich allesamt auf Codierung 
und das Ersparen des langweiligen und fehlerträchtigen Erstellens. Als 
Ergebnis verlagert sich das Tun vom Programmieren hin zum Denken. Damit 
wird aber der Anspruch für den Entwickler eher steigen.

Um so weniger machen solche Ansätze wie in diesem Buch Sinn, Codierung 
zu erlernen. Elektronik und Konzeptdenken müsste man Lehren.

> Selbstverständlich sind die milliardenschweren Investitionen der großen
> Konzerne wie Microsoft, Google Amanzon und ähnliche verlorenes Geld.
In irgendetwas müssen die ja investieren. Besonders Amazon, die immer 
weniger selber verkaufen, weil die Chinesen es mit Alibaba besser 
können.

> Selbstverständlich benutzt kein Entwickler Microsofts Co-Pilot
Wir setzen Co-Pilot ein und sehen, was es kann. Es kann helfen, 
Code-Fehler zu erkennen, hilft aber nicht, dass der Code überhaupt das 
Richtige tut. Es tut sich aber beim Erkennen auch schon ein Effekt auf:

Was durch Code-Prüfer gecheckt ist, wird als gesund angesehen und nicht 
mehr weiter betrachtet. Schon schleichen sich die ersten Fehler ein. Die 
Entwickler verlieren Fähigkeiten und brauchen die Software, so wie 
manche nicht mehr richtig schreiben können, da sie immer die 
Rechtschreibkorrektur benutzen und viele ohne Navi nicht mehr ans Ziel 
kommen. Eklatante Wortfehler sind die Folge, sowie Autos in Flüssen.

> selbstverständlich können die FPGA-Entwickler weiterhin ihre veralteten
> Methoden benutzen und sollten sich keineswegs mit neuartigen
> Technologien befassen.
Zeige mir bitte ein tool, das ein Lastenheft eines Auftraggebers lesen 
kann, die fehlenden und falschen Vorgaben findet und ergänzt, um zu 
entscheiden, was von im Haus gemacht wird und was extern vergeben wird. 
Das ist doch der Anfang des Projektmanagements und diese Entscheidungen 
setzen sich bei Aufteilung in Hardware und in Software fort.

Ich habe beispielsweise kürzlich entschieden, eine Komponente mit einer 
Software so auszustatten, dass wir alten Code nehmen können. Kann das 
die Software?

In einem anderen Fall ist die Entscheidung so, dass die Software so 
umgestaltet wird, dass sie in Zukunft auf einem ZYNQ laufen kann, in 
einem anderen Fall lasse ich sie auslaufen.

> Schließlich ist die FPGA Entwicklung in
> Deutschland so kostengünstig und kann nur von deutschen Spezialisten
> durchgeführt werden, sodass es keinerlei Grund gibt, diese nach Indien
> zu verlagern.
Ach du meinst, dass Deutsche mit KI-Softwareerzeugung wieder billiger 
werden, als Inder mit KI-Erzeugung, die Zugang zu denselben Tools haben?

von Markus K. (markus-)


Lesenswert?

Andi F. schrieb:

>> selbstverständlich können die FPGA-Entwickler weiterhin ihre veralteten
>> Methoden benutzen und sollten sich keineswegs mit neuartigen
>> Technologien befassen.
> Zeige mir bitte ein tool, das ein Lastenheft eines Auftraggebers lesen
> kann, die fehlenden und falschen Vorgaben findet und ergänzt, um zu
> entscheiden, was von im Haus gemacht wird und was extern vergeben wird.
> Das ist doch der Anfang des Projektmanagements und diese Entscheidungen
> setzen sich bei Aufteilung in Hardware und in Software fort.

Dabei geht es aber erst mal weniger darum, ob die KI das kann, sondern 
wie man ihr die Information zukommen lassen kann. Denn wenn sie die 
Information nicht hat, dann kann sie daraus natürlich auch keine 
Schlüsse ziehen.

Das sehe ich dabei als einer der größeren Probleme beim Einsatz der KIs. 
Die Informationen sind weit verstreut oder nirgends niedergeschrieben. 
Welcher Entwickler kann VHDL und Python? Welche Informationen vom Kunden 
stecken in den Requirements, welche in irgendwelchen 
Gesprächsprotokollen und welche nur den Köpfen der Entwickler? Was in 
den "lessons learned" vom vorigen Projekt? Wie lange braucht ein 
typischer Entwickler für ein bestimmtes Problem?

von Markus K. (markus-)


Lesenswert?

Andi F. schrieb:
> Zeige mir bitte ein tool, das ein Lastenheft eines Auftraggebers lesen
> kann,

Prompt: Prüfe folgende Anforderungen auf Konsistenz und Widersprüche.
- Es soll ein Fenster dargestellt werden. Breite 400 Pixel.
- in der Mitte soll ein blauer Button dargestellt werden.
- Die Breite des Buttons soll 100 Pixel betragen.
- Links und rechts vom Button soll der Abstand zum Fensterrand jeweils 
mindestens 200 Pixel betragen.
- Die Farbe des Buttons soll rot sein.

Antwort von ChatGPT 4.0 (September 25 Version):

Lassen Sie uns die Anforderungen durchgehen:

1. Das Fenster soll 400 Pixel breit sein.
2. In der Mitte des Fensters soll ein blauer Button dargestellt werden.
3. Die Breite des Buttons soll 100 Pixel betragen.
4. Links und rechts vom Button soll der Abstand zum Fensterrand jeweils 
mindestens 200 Pixel betragen.
5. Die Farbe des Buttons soll rot sein.

Hier sind die festgestellten Widersprüche:

1. Es gibt einen Widerspruch bezüglich der Farbe des Buttons: In 
Anforderung 2 wird gesagt, dass der Button blau sein soll, und in 
Anforderung 5 wird gesagt, dass er rot sein soll.
2. Wenn der Button 100 Pixel breit ist und der Abstand zu beiden Seiten 
des Fensters jeweils mindestens 200 Pixel beträgt, ergibt das eine 
Gesamtbreite von 500 Pixel (100 + 200 + 200). Das widerspricht der 
Anforderung 1, dass das Fenster nur 400 Pixel breit sein soll.

Zusammenfassend gibt es zwei Widersprüche in den Anforderungen: die 
Farbe des Buttons und die Gesamtbreite von Button und Abständen im 
Verhältnis zur Fensterbreite.

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


Angehängte Dateien:

Lesenswert?

Markus K. schrieb:
> (September 25 Version)
Und die kannst du schon im Oktober '23 befragen?    ;-)

Die heutige Version bringt da noch nichts Brauchbares zuwege, aber sie 
sieht schon mal ein, dass da Nachholbedarf besteht.

: Bearbeitet durch Moderator
von 900ss (900ss)


Angehängte Dateien:

Lesenswert?

Christoph M. schrieb:
> Bei der Verwendung als Programmbefehl waren 3 Bit für den Opcode

OT (damit bin ich hier aber in guter Gesellschaft):
3 Bit Opcode gibt es heute auch wieder, siehe den Assembler der 
Raspberry Pi Pico PIOs. :)

Siehe Anhang Bit 13-15.

von Markus K. (markus-)


Angehängte Dateien:

Lesenswert?

Lothar M. schrieb:
> Die heutige Version bringt da noch nichts Brauchbares zuwege, aber sie
> sieht schon mal ein, dass da Nachholbedarf besteht.

Welche Version hast Du befragt? 3.5 oder 4.0? Die 4.0er ist deutlich 
besser. Das was es da bei Bing gibt ist zwar irgendwie auch eine 4er, 
aber schlechter als die 4.0er bei openai.com. Die aber auch Geld kostet.

Wenn Du Dich fragst, wo die genaue Version steht: bei 
https://chat.openai.com ist das ganz unten auf der Seite, unterhalb des 
Eingabefeldes.

von Christoph M. (mchris)


Lesenswert?

>Welche Version hast Du befragt? 3.5 oder 4.0? Die 4.0er ist deutlich
>besser.

Ich finde das wirklich erstaunlich. Sagt man über ChatGPT nicht, dass es 
nur Wortwahrscheinlichkeiten verwendet und aus bekannten Sätzen das 
nächst wahrscheinlich Wort auswählt?
Wenn ich mir dein Experiment anschaue, frage ich mich, wie ChatGPT den 
Widerspruch entdecken kann. Das sieht fast nach einem Verständnis für 
den Text aus.

von Markus K. (markus-)


Lesenswert?

Christoph M. schrieb:
>>Welche Version hast Du befragt? 3.5 oder 4.0? Die 4.0er ist deutlich
>>besser.
>
> Ich finde das wirklich erstaunlich. Sagt man über ChatGPT nicht, dass es
> nur Wortwahrscheinlichkeiten verwendet und aus bekannten Sätzen das
> nächst wahrscheinlich Wort auswählt?

Ich glaube nicht, dass es ganze Sätze gespeichert hat.
Die Wahrscheinlichkeit für das nächste Wort geht auch nicht nur über 
einen Satz, sondern über einen viel größeren Bereich. Sowohl beim 
Training als auch bei der Benutzung. Wenn man z.B. eine Aufgabe mit 10 
Sätzen auf Deutsch stellt und ein Satz ist dabei, dass die Antwort auf 
Englisch sein soll, dann wird die Antwort auf Englisch sein. Das geht 
natürlich nur, wenn es die gesamten 10 Sätze gleichzeitig als Input für 
den Output nimmt.

Man kann sich bei den Fragen auch auf vorherige Antworten (aus dem 
selben Dialog) beziehen, d.h. die vorherigen Antworten gehen auch in die 
Wortwahrscheinlichkeiten ein. Konkret ist der Kontext typischerweise 
4000 Tokens, was ca. 2000 Worte sind, d.h. die Wahrscheinlichkeit für 
das nächste Wort wird aus den vorigen 2000 Wörtern in dem Dialog 
berechnet.

Man darf sich das aber nicht so vorstellen, dass da eine große Tabelle 
mit 4000 Spalten für die Tokens ist und ganz rechts das 
wahrscheinlichste nächste Wort. So eine Tabelle wäre ja viel zu groß.

> Wenn ich mir dein Experiment anschaue, frage ich mich, wie ChatGPT den
> Widerspruch entdecken kann. Das sieht fast nach einem Verständnis für
> den Text aus.

Was ist denn Verständnis? Ich würde sagen: Die richtige Verknüpfung von 
Informationen. Es reicht nicht, willkürlich Informationen zu verknüpfen.
Wenn jemand mit einem roten Golf von A nach B zum Essen fahren möchte, 
dann spielt die Farbe, der Hersteller des Autos usw. keine Rolle. Wie 
lange die Fahrt dauert, ob das Restaurant geöffnet hat usw. dagegen 
schon. Welche Informationen wichtig sind hat ein Mensch halt gelernt.

ChatGPT kann recht gut Informationen irgendwie verknüpfen. Es ist 
bekannt, dass es bei bei einer falschen Antwort helfen kann, wenn man es 
bittet, die Antwort Schritt für Schritt zu erklären. Dann kommt die 
richtige Antwort raus. Ich interpretiere das so, dass es bei den 
Einzelschritten leichter ist die richtigen Verknüpfungen zu finden.

Bei dem ganzen Themenkomplex Intelligenz, Verständnis usw. hat man das 
Problem, dass man im Prinzip nur den Menschen und sehr eingeschränkt 
Tiere als Referenz hat. Deswegen ist es sehr schwierig gute Definitionen 
zu finden. KIs sind recht gut darin menschliche IQ-Tests zu beantworten, 
aber das liegt meiner Meinung nach weniger daran, dass sie so 
intelligent sind, sondern dass die IQ-Tests für Menschen gar keine 
Intelligenz messen, sondern irgendwas anderes, was bei Menschen halt mit 
Intelligenz korreliert.

Falls meine o.g. Definition von Verständnis richtig ist, dann haben KIs 
sehr wohl Verständnis. Ich glaube aber insbesondere, dass Verständnis 
nicht binär ist (hat Verständnis/hat kein Verständnis), sondern ein 
Spektrum ist. Wenn die KI Verständnis hat, aber weniger als ein 
durchschnittlicher Mensch, dann würde man erwarten, dass es manche 
Verständnisaufgaben lösen kann, aber weniger als ein Mensch. Genau das 
sehen wir hier.

von J. S. (engineer) Benutzerseite


Lesenswert?

Markus K. schrieb:
> Die Informationen sind weit verstreut oder nirgends niedergeschrieben.
Das ist das Problem. Auch wenn es heute Management-Systeme und 
Wiki-Seiten gibt wie Confluence, ist das Wissen um die konkrete 
Anforderungsstruktur verteilt. Man kann sie auch nicht jedes mal 
ausdrücklich präzisieren, sondern muss sie einfach beim Erdenken der 
Lösung intuitiv anwenden. Will man das alles einer SW mitteilen, damit 
sie richtige Schlussfolgerungen ziehen kann, ist der Aufwand größer, als 
es gerade selber zu formulieren.

Und man muss berücksichtigen, dass viele Kunden (intern wie extern) das 
eben nicht können, weil sie mit Texten nicht gut umgehen oder weil sie 
es schlicht einfach nicht machen wollen.

D.h. schon das Erstellen und Formulieren des Lastenheftes funktioniert 
nicht.

Beim Umsetzen ist es nochmals problematischer:

Schon der Umfang, einem simplen Tool wie MATLAB mitzuteilen, welche 
Randbedingungen es zu berücksichtigen hat, um aus einem möglichen 
Spektrum von Lösungen das richtige C zu generieren, ist oft mit mehr 
Aufwand verbunden, als es selber zusammenzukopieren. Bei VHDl ist es 
nochmals ungleich schwieriger. Ich hatte zu den Betrachtungen dazu 
bereits mehrfach Stellung genommen, auch hier im Forum, und 
verdeutlicht, wie weit weg man da vom automatisierten Finden von 
Lösungen ist. Das automatisiere Generieren des Codes, wenn man die 
Lösung selber vorgibt, funktioniert schon nicht mehr zielführend und 
fehlerfrei.

> Welcher Entwickler kann VHDL und Python?
Da sehe ich kein Problem. Das können inzwischen die Meisten. Das hilft 
aber beim Finden von Lösungen auch nicht. Python ist ja auch nur eine 
Sprache, um Sachverhalte dediziert vorgeben zu können. Es hilft 
natürlich, einen Code bauen zu lassen, wenn man genau vor Augen hat, was 
der tun soll. wxPython kann man sich dazu mal ansehen, wen es 
interessiert.

Der Hund liegt aber wie gesagt woanders begraben:

Eine Aufgabe kann je nach Einschränkung hunderte unterschiedliche 
Lösungen haben.

Das hier :
> Welche Informationen vom Kunden stecken in den Requirements,
> welche in irgendwelchen Gesprächsprotokollen
> und welche nur den Köpfen der Entwickler?
ist da nur ein Teil des Problems. Das Konzept muss zur 
Geschäftsstrategie passen, Risiken von Zulieferern berücksichtigen, 
Kostenschätzung erlauben, auf Änderungen reagieren oder die 
Notwendigkeit von Änderungen ausschließen.

Das hat Konsequenzen bis ins Kleinste:

Eine VHDL-Komponente die in eine Testbench wandert muss anders aussehen, 
als eine die als Test ins System wandert, sie muss wieder anders 
aussehen, wenn sie in einen ASIC soll und sie muss wieder anders 
aussehen, wenn der Code durch den ASIC-Entwickler verstanden werden 
soll, damit er ihn weiterberarbeiten kann oder ob der sein kann /oder 
muss wie will, weil der ihn nicht verstehen muss oder soll.

Eine Lösung für das gefundene Konzept muss z.B. auch zu dem passen, was 
es schon gibt:

Die VHDL-Komponente soll auch von den Entwicklern verstanden werden, die 
sie in ihrem Code weiterverwenden, muss Funktionen und Strukturen für 
die Zukunft enthalten, damit sie divergiert oder konvergiert werden 
kann. Selbiges kann der Entwickler ad hoc entscheiden, es durchführen 
wenn die Zeit dafür passt oder es auch unterlassen, wenn Zeitdruck ist 
und eine Abkündigung kommt.

WER BITTE SOLL ALL DIESE RANDBEDINUNGEN VORHER INS PROJEKT TREIBEN, 
DAMIT KIs DAS AUSWERTEN UND LASTENHEFTE, PFLICHTENHEFTE UND CODE 
SCHREIBEN KÖNNEN?

Nehmen wir ein einfaches Beispiel:

Wieviel Programmieraufwand hat man, um einem Auto beizubringen, einen 
zum Bäcker zu fahren um Brötchen zu holen?  Es müssen dabei alle 
Situationen des Lebens berücksichtigt werden, die stören können, 
inklusive Ausfall des Autos, Raubüberfall während der Fahrt, dem 
Herzinfarkt eines Passanten auf dem Weg dahin wo man helfen muss, dem 
Anruf des Chefs, dass er dich sofort braucht und das Frühstück bezahlt, 
wenn du kommt - ALLES, was passieren kann und was ein Mensch binnen 
Sekunden entscheiden muss.

Das geht schon in den Rechner des Autos nicht hinein, geschweige denn 
das es wirtschaftlich wäre, ein Auto herzustellen, dass das alles kann.

KI ist am Ende auch durch Kosten und Wirtschaftlichkeit begrenzt. Diese 
KI muss irgendwo laufen. Sie kostet Zeit, Geld und Strom und produziert 
CO2.

Autos, die alles können, alleine irgendwo rumfahren, Unfälle vermeiden 
und einem zum Bäcker bringen, existieren in den Hirnen der Firma Audi, 
wo Manager sitzen, deren Denke nicht ausreicht, um auch nur 1% der 
möglichen Ausfallsszenarien zu definieren, geschweige denn sie zu 
formulieren, dass die Entwickler sie umsetzen können.

Die Fähigkeiten der Entwickler reicht derzeit nicht einmal aus, um eine 
simple Sprachsteuerung hinzubekommen, die Einparkhilfe hinzudrehen und 
die Kameras vernüftig auszuwerten.

Und statt dort das Allheilmittel zu suchen, sollte man lieber Geld in 
die Hand nehmen und das jetzt schön Mögliche an Medizingeräten bauen. 
Das ist nämlich auch weit hinter dem zurück was wir jetzt schon - GANZ 
OHNE KI - können. Und es ist zurück, weil es die Kosten sind, die 
verhindern, dass es eingebaut wird.

von J. S. (engineer) Benutzerseite


Lesenswert?

Markus K. schrieb:
> Das Fenster soll 400 Pixel breit sein.

Das was dort zum Fenster steht, hat mit Lastenheften nichts zu tun, 
sondern ist Design-Spec. Obendrein ist es ein Auffinden von trivialen 
Gegensätzen. Schon wenn man es umformuliert und statt Fenster einfach 
"Öffnung" verwendet, was dasselbe sein kann, aber nicht muss, wenn man 
Ränder betrachtet oder gar  "FOV" und "FOI" einführt, ist der Chatter 
überfordert. Spätestens, wenn Ränder hinzukommen mit dynamischer Größe, 
das Auffinden möglicher Ganzzahlrasterungen, das Trennen von sinnvollem 
und unsinnigem, ist Ende, weil da wieder Definitionen reinkommen, deren 
Fehlen man erst einmal erkennen muss, weil sie nicht ausdrücklich als 
fehlend erkennbar sind.

Am Ende hat der Chatter 10 Rückfragen, um Randbedingungen einzusammeln, 
damit er die möglichen Lösungen ausmaskieren kann.

von Markus K. (markus-)


Lesenswert?

J. S. schrieb:

> Wieviel Programmieraufwand hat man, um einem Auto beizubringen, einen
> zum Bäcker zu fahren um Brötchen zu holen?  Es müssen dabei alle
> Situationen des Lebens berücksichtigt werden, die stören können,
> inklusive Ausfall des Autos,

Sicherheitskritische Systeme können natürlich mit Ausfällen umgehen.

> Raubüberfall während der Fahrt,

Du möchtest eine Waffenerkennung? Wären da gepanzerte Fahrzeuge nicht 
viel sinnvoller? Wie oft bist Du denn schon während der Fahrt überfallen 
worden? Müssen nicht viel mehr die Räuber lernen, dass es sinnlos ist, 
autonome Fahrzeuge zu überfallen?

> dem
> Herzinfarkt eines Passanten auf dem Weg dahin wo man helfen muss,

Bisher: Menschlicher Fahrer konzentriert sich auf den Verkehr, bemerkt 
nicht, dass rechts neben ihm auf dem Gehweg jemand zusammenbricht.
Neu: Auto konzentriert sich auf den Verkehr. Mensch schaut in der Gegend 
rum und bemerkt den Notfall. Hält das Auto an und eilt zu Hilfe.

> dem
> Anruf des Chefs, dass er dich sofort braucht und das Frühstück bezahlt,
> wenn du kommt

Telefone werden natürlich in autonomen Autos weiterhin funktionieren.

> - ALLES, was passieren kann und was ein Mensch binnen
> Sekunden entscheiden muss.

Schau Dir einfach mal an, wie viele Unfälle es gibt, weil Menschen in 
eher einfachen Situationen falsch reagiert haben.

> Das geht schon in den Rechner des Autos nicht hinein, geschweige denn
> das es wirtschaftlich wäre, ein Auto herzustellen, dass das alles kann.
>
> KI ist am Ende auch durch Kosten und Wirtschaftlichkeit begrenzt. Diese
> KI muss irgendwo laufen. Sie kostet Zeit, Geld und Strom und produziert
> CO2.

Schau Dir an, was z.B. Teslas Autopilot kann (mit m.M. unzureichender 
Sensorik) mit 20 TOPS Rechenleistung in den neuroalen Netzen und 
bedenke, das man heutzutage schon wesentliche schnellere Systeme 
kaufen kann, z.B. NVIDIA Jetson AGX Orin mit 275 TOPS. Die 60W, die es 
benötigt, sind im Vergleich zum Motor sehr wenig. Bis in 10 Jahren ist 
man da wahrscheinlich nochmal eine Größenordnung schneller.

von Markus K. (markus-)


Lesenswert?

J. S. schrieb:
> Markus K. schrieb:
>> Das Fenster soll 400 Pixel breit sein.
>
> Das was dort zum Fenster steht, hat mit Lastenheften nichts zu tun,
> sondern ist Design-Spec.

Außer wenn der Kunde das so verlangt. Dann ist das Teil vom Lastenheft.

> Obendrein ist es ein Auffinden von trivialen Gegensätzen.

Triviale Gegensätze in Lastenheften müssen nicht gefunden werden bzw. 
kommen nicht vor? Vielleicht denk ich mir ein anspruchsvolleres Beispiel 
aus.

> Schon wenn man es umformuliert und statt Fenster einfach
> "Öffnung" verwendet, was dasselbe sein kann, aber nicht muss,

Das ist falsch. Ich habe statt Fenster "Öffnung" geschrieben und es hat 
die Aufgabe trotzdem gelöst.

> wenn man
> Ränder betrachtet oder gar  "FOV" und "FOI" einführt, ist der Chatter
> überfordert.

Die Systeme sind recht gut darin auch mit eher unüblichen Begriffen 
umzugehen. Wenn sie sehr unüblich sind, dann müssen sie natürlich vorher 
definiert werden. Damit können sie aber natürlich auch umgehen.

von Klaus K. (Gast)


Lesenswert?

Lothar M. schrieb:

> Zurück zum Buch und noch ein Wort zum ersten Satz der oben im
> Beitrag "Re: neues FPGA buch: "FPGA für alle"" gescannten
> Buchseite: da steht verniedlichend, dass im FPGA "über eine if-Anweisung
> ein Code mit 100 Hz aufgerufen" werde. Ein sehr viel falscheres Bild von
> Hardwaredesign kann man kaum vermitteln.

Ja, eine solche "Buchsprache" dient auch nicht der "Vermittlung von 
Hardware-theorie" (das macht die (Hochschul-)Ingenieursausbildung) 
sondern soll den Leser bei seinem aktuellen Wissenstand, hier 
Mikrocontroller-Gebastel. abholen.
Das ist IMHO völlig OK; einer, der zum Zeitvertreib mit einer 
Modelleisenbahn spielt, macht das ja auch nicht um damit ein Studium des 
Logistikswesens zu ersetzen.

Man kann es auch mit den verschiedenen "Zugängen" zur Alpinen 
Hochgebirgswelt vergleichen. Man muss nicht früh aufstehen um in 
Wanderstiefeln die Felsen raufkraxeln wie man es im Kletterkurs gelernt 
hat. Man kann auch im Cabrio zum Parkplatz fahren und sich von der 
Seilbahn raufbringen lassen. Bei letzteren hat man am Schluß auch ein 
falsches Bild von der Bergsteigerei gewonnen, kann aber trotzdem mit 
Recht behaupten, das man auf den Berg gewesen ist.

Und schließlich ist man hier bei "mikrocontroller.net" - wie kann man da 
den Theorieverweigern von der Arduino-Künszler-Fraktion ihren 
Freizeitspass mit FPGA verwehren ;-)

von J. S. (engineer) Benutzerseite


Lesenswert?

Markus K. schrieb:
> Das ist falsch. Ich habe statt Fenster "Öffnung" geschrieben und es hat
> die Aufgabe trotzdem gelöst.

Du hast das Problem nicht verstanden. (und dein chat-vieh auch nicht). 
Ein Fenster in einem Bild hat einen Rahmen. Die Öffnung ist 
Fensteraußenbreite - Rahmen. Das hätte man erkennen müssen.

Markus K. schrieb:
> das man heutzutage schon wesentliche schnellere Systeme
> kaufen kann,
Wir können seit 20 Jahren Besseres kaufen, als in Navis verbaut wird, 
aber es wird eben nicht verbaut, weil nicht bezahlbar. Es gibt kaum eine 
Sparte mit soviel Kostendruck wie die Autobranche. Dass man etwas 
grundsätzlich bauen kann, heißt nicht, dass es den Weg ins Produkt 
findet. Der Trend geht auch derzeit zu weniger Auto und weniger 
Schnickschnack. Schau dir einfach mal  die Absatzzahlen der Luxusautos 
an. Und sieh dir mal an, wer ein Navi im Auto hat. Das sind immer 
weniger, sowohl fest verbaute Systeme, als auch mobile. Wenn, nutzen die 
Menschen ihre Mobiltelefone und da ist wieder dasselbe Problem: Man 
kriegt theoretisch einen Superrechner, bekommt es aber nicht unter oder 
kann es nicht bestromen, weil die Akkus leerlaufen. Für das, was Viele 
mit ihrem schlanken Fone machen, brauchen 12% jetzt schon einen 
Power-Pack.

Die Technologie, Autos per Kamera zu führen, haben wir seit Ende der 
1990er, inklusive Objekterkennung und Abstandshalten. Und? Haben wir es 
drin? Nein, weil keiner möchte, dass sein Auto zuviel Abstand hält und 
die Geschwindigkeitsbegrenzung einhält. Es hab für beides immer wieder 
Autofirmen, die das einführen wollten, aber die Kunden haben 
signalisiert, dass sie ein so entmilitarisiertes Auto nicht kaufen 
werden.

von Rick D. (rickdangerus)


Lesenswert?

J. S. schrieb:
> Die Technologie, Autos per Kamera zu führen, haben wir seit Ende der
> 1990er, inklusive Objekterkennung und Abstandshalten. Und? Haben wir es
> drin? Nein, weil keiner möchte, dass sein Auto zuviel Abstand hält und
> die Geschwindigkeitsbegrenzung einhält.
Nein, das ist deswegen noch nicht drin, weil das noch nicht mal auf der 
Nordschleife funktioniert...

von Andreas U. (Gast)


Lesenswert?

Markus K. schrieb:
> Das sehe ich dabei als einer der größeren Probleme beim Einsatz der KIs.
> Die Informationen sind weit verstreut oder nirgends niedergeschrieben.

Mehr noch, es gibt kaum eine Möglichkeit, den Wert der Information zu 
prüfen. Sieh dir die in Foren wie diesen die Information an. Mehr Müll 
als sonst was.

von J. S. (engineer) Benutzerseite


Lesenswert?

Rick D. schrieb:
> Haben wir es
>> drin? Nein, weil keiner möchte, dass sein Auto zuviel Abstand hält und
>> die Geschwindigkeitsbegrenzung einhält.
> Nein, das ist deswegen noch nicht drin, weil das noch nicht mal auf der
> Nordschleife funktioniert...

Es ist so wie ich es geschrieben habe: Die Technik war 1998 ausgereift 
und wurde u.a. Audi präsentiert. Diese und vor allem auch BMW haben sich 
ausdrücklich gegen eine Einführung in ihren Fahrzeugen entschieden, weil 
eben eine Studie besagtes Ergebnis hatte, nämlich dass die tpyischen 
Nutzer dieser Fahrzeuge Angst haben, von langsameren Fahrzeugen, die 
nicht gebremst werden, auf der Autobahn rechts überholt werden, weil 
diese noch dicht auffahren und einscheren können, wodurch sie selber 
dann ausgebremst würden.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.