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
Warum wird dafür geworben? Weil es so gut ist? Oder hat der Autor eine Verbindung zum Hause Trentz?
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.
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.
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 sollte bald wieder da sein, keine beschränkung wieviel sie kaufen.
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.
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.
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.
Antti L. schrieb: > VHDPlus ohoh ... ein Totes Pferd wird geritten, bis es quietscht! Niemand in der Industrie benutzt das. Kein Aas.
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?
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 :)
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".
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.
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.
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.
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.
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.
>> 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.
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".
Schön das es eine Leseporbe gibt. Leider nicht mehr selbstverständlich. Jedoch ist das allen ernstes in Times-New-Roman gesetzt?
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.
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.
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.
> 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.
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?
Angehängte Dateien:
-
Buchseite_7Seg_s.jpg
170 KB
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.
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
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.
Klaus K. schrieb: > PS: Der Seitenscan im Anhang soll zeigen, Aua! Nicht wegen dem Layout, sondern wegen dem Code :-(
> 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.
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
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.
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.
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...
> 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".
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.
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.
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; |
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.
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.
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; |
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.
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.
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.
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.
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.
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.
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.
>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.
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
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
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.
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?
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?
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.
Angehängte Dateien:
-
Passt_soweit.PNG
26 KB -
Welche_Version_bist_du.PNG
11 KB
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
Angehängte Dateien:
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.
Angehängte Dateien:
-
Version.png
88 KB
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.
>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.
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.
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.
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.
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.
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.
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 ;-)
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.
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...
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.