Heute mal probiert, was CGPT so an VHDL auswirft, wenn man ihn/sie/es beauftragt, einen Audio-Filter zu bauen. Nach drei Versuchen und Beantwortung von Rückfragen kam "das Tschättende" dann mit ordentlichem Code rüber. Zuvor gab es Standard von der Stange.
Der Code ist im Prinzip komplett und kommt auf Wunsch mit Testbench, wenngleich die nicht wirklich das testet, was das Problem bei solchen Filtern wäre. Da muss man selber ran. Oder gfs nochmal konkreter befragen.
Das Entscheidende sind die Skalierungen und die Berechnung der Koeffizienten. Das scheint zu passen, jedenfalls klappt das Filtern. Wie genau die ausgerechnet wurden, ist aber nicht dargelegt und auch nicht so ganz durchsichtig - so weichen die Werte etwas von dem ab, was man mit einem Filterdesigner rausbekommt, insbesondere bei biquad-IIR. Er wechselt auch mittendrin von DF1 auf DF2-Form. Die Begründung war ein Überlauf und das das besser passt.
Das Interessanteste ist, daß er für FPGAs was andere empfiehlt, als für INT-Operationen im Prozessor - bei gleichen Randbedingungen. Hm ... (?)
Was er nicht kann, ist die Koeffizientenoptimierung auf ideale Breiten und versteckte Skalierungen, also erhöhte Zwischenauflösungen bei späterer Division. Besonders das Optimieren auf Ganzzahlen oder Binärzahlen wäre ja ein Ziel beim VHDL. Einen Butterfly für Audio-AA bei z.B. 24kHz hat er so z.B. zwar richtig hinbekommen (Frequenzgang passt!), allerdings braucht er fast doppelt so viele Multiplier und frisst insgesamt mehr Platz. Das liegt vor allem an den zunächst viel zu kleinen b-Koeffizienten im 1000er Bereich, die dann ungenaue Ergebnisse liefern. Die finale Version mit hoher Genauigkeit hoppelt auf 55 Bit-Verktoren.
Ohne weiteres Zutun mit FFs packt er auch nur 110 MHz, während meiner auf 200 kommt, da skalierte 42 Bit-Vektoren. Zudem ist das Teil erst einmal nur für einen Kanal geeignet, pipelinen kennt er offenbar nicht. Jedenfalls hat er dazu nichts liefern können.
Von daher ähnelt das Ganze ziemlich den open source Implementierungen, die so herumschwirren. Der Wert ist daher eher marginal, denn Werte ausrechnen und als Koeffs reinschmeißen kann man ja immer, wenn man den Filter einmal hat. Werte Optimieren muss man dann auch, wenn Bedarf.
Ich denke mal, wer gar kein VHDL kann und/oder nichts im Köcher hat, kriegt da aber durchaus gute Prototyping-SW hin.
Code im Chat zu generieren – ich vermute das war dein Ansatz – nutzt die Möglichkeiten der KI heutzutage aber nicht mal mehr ansatzweise aus. Spannend wird es, wenn du der KI Sythese- und Simulationstools an die Hand gibst. Probier das doch mal aus. Würde dann aber gleich Claude Code oder Kiro mit Opus 5 empfehlen. Die 20 Euro (pro Monat) sind gut investiertes Geld – zumindest einmalig für die Lernerfahrung.
Mich würde auch interessieren, welche ChatGPT-Variante verwendet wurde, auch ob ohne oder mit Anmeldung.
Erst ab letzteren kannn man auch files hochladen, was mglw. sinnvoll sein kann, den Generator durch Beispiele in eine gewünschte Richtung "zu schubsen".
Ein Problem bei FPGA ist, das es mit dem VHDL-Code nur funktional getan ist, oft muss man auch an den constraints (*.xcf o.ä.) (fürs timing closure) drehen und "Architekturunabhängiger Code" ist IMHO ein vergeblicher Wunschtraum. Also sinnvollerweise muss man immer dien Ziel-FPGA mitangeben, was dann die Aufgabe für die AI oft unmöglich beherrschbar macht.
Ein Problem bei FPGA ist, das es mit dem VHDL-Code nur funktional getan
ist, oft muss man auch an den constraints (*.xcf o.ä.) (fürs timing
closure) drehen und "Architekturunabhängiger Code" ist IMHO ein
vergeblicher Wunschtraum. Also sinnvollerweise muss man immer dien
Ziel-FPGA mitangeben, was dann die Aufgabe für die AI oft unmöglich
beherrschbar macht.
Der vergebliche Wunschtraum wird recht flott Realitaet, wenn man es mit einer Python-basierten generativen HDL probiert. Dann produziert sogar ChatGPT u.U. ganz effizienten Code in derselben Session in der er mit einer solchen DSL eingelernt wurde.
Wo es eben hapert, ist Pipelining, das Beispiel IIR habe ich schon mal woanders angefuehrt. Wenn man die Freiheiten hat, mehrere Datenspuren parallel in "Slots" zu verarbeiten (alias mehrere Zyklen pro Stufe), geht das teils ohne manuellen Eingriff in das DSL-Resultat gut. Wenn die Pipeline zu lang fuer die Rekursion wird, realisiert die KI typischerweise die Verletzung der Kausalitaet schon mal nicht. Lookahead-Transformationen kann sie aufloesen, aber je nach Filter klappt das dann mit der numerischen Stabilitaet ueberhaupt nicht mehr per KI.
Was man sich allerdings im Zusammenhang damit fragen sollte, ist, ob man die KI mit solchen Eckdaten und seinem Knowhow ueberhaupt trainieren will. Je nach Modell ist die Begierigkeit zu lernen eher gruselig als hilfreich.
Was man sich allerdings im Zusammenhang damit fragen sollte, ist, ob man
die KI mit solchen Eckdaten und seinem Knowhow ueberhaupt trainieren
will. Je nach Modell ist die Begierigkeit zu lernen eher gruselig als
hilfreich.
Was man sich allerdings im Zusammenhang damit fragen sollte, ist, ob man
die KI mit solchen Eckdaten und seinem Knowhow ueberhaupt trainieren
will. Je nach Modell ist die Begierigkeit zu lernen eher gruselig als
hilfreich.
Wenn du es nicht willst, tun es andere.
Dann koennen sich die "anderen" ja hiermit mal ueberlegen, wie sie das in Zukunft hantieren wollen, sprich, den Haien ihre Broetchen in den Rachen schmeissen, oder lieber einen eigenen Acker bewirtschaften wollen.
Und der Rest der Welt darf gern der KI bei ihrem fortschreitenden Inzest zugucken oder sogar dabei behilflich sein.
Hach, die Jugend heutzutage mit diesen neuartigen „Messern“. Wo soll das denn noch hinführen, wenn keiner mehr lernt, seine Beute mit dem Faustkeil auszuweiden?
Mich würde auch interessieren, welche ChatGPT-Variante verwendet
wurde, auch ob ohne oder mit Anmeldung.
Erst ab letzteren kannn man auch files hochladen, was mglw. sinnvoll
sein kann, den Generator durch Beispiele in eine gewünschte Richtung "zu
schubsen".
Es macht bei ChatGPT auch einen Riesenunterschied, ob man nur das normale Webinterface verwendet und ihm dort kleine Codehäppchen vorwirft, ihm ein öffentlich zugängliches Git-Repository als Vorlage nennt oder es gleich richtig macht. Letzteres geht nämlich mit dem lokal zu installierenden OpenAI-Client, der neben ChatGPT auch Codex mitbringt. Und Codex kann auf lokalen Sandboxes und auch auf Projekten mit mehreren (Git-)Repositories arbeiten.
Ich nutze derzeit Codex im Plus-Abonnement mit 5.6 Sol, für einfache Aufgaben mit Medium-Aufwand. Und für richtig komplexe Aufgaben liefert der Ultra-Aufwand dann Ergebnisse, die sich beeindruckend sind. Für solche Ergebnisse reicht es natürlich nicht, mal schnell irgendeinen Prompt hinzurotzen, sondern (schon allein auf Grund der Kosten) formuliere ich locker eine Stunde oder mehr an meinem Prompt herum. Und anschließend ist Codex dann auch noch ein bis zwei Stunden mit der Arbeit beschäftigt.
Vor einigen Tagen habe ich so einen Treiber für Zephyr generieren lassen, für einen Baustein mit grottenschlecht formuliertem Datenblatt mit furchtbarer und inkonsister Registerbeschreibung. Vorher hatte ich mich selbst schon monatelang vergeblich daran versucht. Schon dieser erste Treiber war wesentlich aufgeräumter als andere ähnliche Treiber und auch meine Versuche. Aber leider passte der Treiber noch nicht ganz in das Gerüst anderer ähnlicher Treiber.
Und richtig gut wurde es dann, als ich vor einigen Tagen dann einen Prompt formulierte, in dem Codex alles zusammen betrachten sollte, d.h. alle etlichen von mir geschriebenen, aus den Treibern für andere ähnliche Bausteine und seinem ersten (schon einwandfrei laufenden!) Versuch. Dabei kam dann etwas heraus, was sehr sauber strukturiert ist, einwandfrei funktioniert, vollständig implementierte Fehlerbehandlungen auch für Fälle beinhaltete, die mir nicht einmal im Ansatz einfielen, und eben ins Standargerüst passt. Und natürlich auch noch per Zepyhr-Shell verwendbare Testfunktionen, die sämtliche Funktionalität nutzen.
Im nächsten Schritt habe ich dann (in einem recht langen Prompt) beschrieben, dass alles in einem eigenen Prozess mit einer umfangreichen FSM laufen soll und die Shell-Kommandos dann mittels k_msg mit dem Prozess kommunizieren sollen. Auch das funktionierte auf Anhieb und läuft derzeit seit 31 Stunden in einem Dauertest, ohne jeglichen Fehler.
Das normale ChatGPT-Webinterface hat nämlich keinen Zugriff auf die Buildumgebung, so dass es noch häufiger z.B. zu Typenfehlern kommt, usw.. Codex startet bei wichtigen Zwischenschritten immer selbst einen Buildvorgang, wertet die Meldungen aus, korrigiert Fehler und Warnungen, und das über eine Handvoll Iterationen.
Ich muss einräumen, dass Codex mittlerweile besser ist als ich selbst, insbesondere wegen des iterativen Vorgehens. Kein Softwareentwickler würde einfach mal so seinen Code komplett überarbeiten und dabei so pedantisch an als die Sonderfälle denken.
Codex hat nur einen einzigen winzigen Fehler gemacht: das Register mit der Hardwarekennung und -version des Bausteins wurde bei der Initialisierung ausgelesen und gegen den Wert laut Datenblatt verglichen. Mein Board hat jedoch eine andere Maskenversion des Bausteins, die allerdings nicht im Datenblatt publiziert war. Ich vermutete einen gefälschten Chip. Im ChatGPT-Modus fragte ich nach meiner Vermutung und solte ein Foto hochladen. Hierzu gab es dann auch gleich eine längliche Analyse, wobei es sich offenbar nicht um eine Fälschung handelte, sondern mein Baustein aus einem bestimmten Fertigungslos stammte, das aus einer Übergangsphase während der Übernahme des Herstellers durch einen anderen stammte. Und es wurde auch gleich eine Quellcodestelle im Linux-Kernel genannt, in der beide Hardwarekennungen aufgeführt wurden. Codex bot mir daraufhin an, meinen generierten Treiber auch gleich entsprechenden anzupassen, was ich aber ablehnte, weil ich die Änderungen schon selbst eingebaut hatte. Der "Fehler" bestand also nur darin, dass Codex sich nur an Datenblatt und Referenzimplementierungen gehalten hatte, aber trotz besseren Wissens nicht diesen Workaround aus dem Linux-Kernel mit eingebaut hat.
Da es sich um ein laufendes Kundenprojekt handelt, nenne ich an dieser Stelle nicht den Baustein.
Hach, die Jugend heutzutage mit diesen neuartigen „Messern“. Wo soll das
denn noch hinführen, wenn keiner mehr lernt, seine Beute mit dem
Faustkeil auszuweiden?
Kein Vergleich ist zu blöd um ihn nicht doch irgendwie in der unpassendsten Situation anzubringen.
Und der Rest der Welt darf gern der KI bei ihrem fortschreitenden Inzest
zugucken oder sogar dabei behilflich sein.
Die Ergebnisse sind einfach beeindruckend gut, müssen aber natürlich durch den Entwickler ganz genau untersucht werden. Die eigentliche Kunst besteht darin, den Prompt hinreichend präzise zu formulieren, aber nicht zu überspezifizieren.
Vor ca. zwei Jahren diente KI-generierter Code eher der Belustigung und erfüllte keinerlei Qualitätsansprüche. Ich hatte damals(tm) auch mal einen Treiber generieren lassen. (ChatGPT 4o)
Vor ca. einem Jahr eignete sich KI-generierter C-Code schon ganz gut dazu, sich Programmierbeispiele liefern zu lassen, insbesondere wenn die API-Dokumentation eher spärlich und weit verstreut war. Aber damals gab es noch massive Probleme z.B. mit nicht initialisierten und falsch verwendeten Pointern, die zu länglichen Fehlersuchen führten. Als API-Demo ganz gut, aber nicht produktiv einsetzbar. (ChatGPT Plus 5.0? Hoch)
Und aktuell ist es besser als handgeschriebener C-Code, siehe oben. (Codex Plus 5.6 Sol Ultra)
Fuer die, die es nicht mitbekommen haben: ich nutze "KI" ausgiebig seit nunmehr 20 Jahren. Mit den heutigen LLMs hat(te) das allerdings nicht immer etwas zu tun. Museale Faustkeilvergleiche waeren somit komplett neben der Spur, gehoeren aber ohnehin zu dem Geunke aus dem eher mittelmaessig gewachsenem Gebuesch.
Somit duerfte klargeworden sein, was mit dem eigenen Acker gemeint ist. Warum also sollte ich gegen Bezahlung - geschweige denn gratis - ein Modell eines Uebersee-Techkonzerns mit meinem Knowhow trainieren?
Dann koennen sich die "anderen" ja hiermit mal ueberlegen, wie sie das
in Zukunft hantieren wollen, sprich, den Haien ihre Broetchen in den
Rachen schmeissen, oder lieber einen eigenen Acker bewirtschaften
wollen.
Und der Rest der Welt darf gern der KI bei ihrem fortschreitenden Inzest
zugucken oder sogar dabei behilflich sein.
In einem Lobby-Unternehmen aus Mundwerkern ist es auch keine Hürde den Grossteil der Mit"arbeiter" durch Blafassel-Generatoren zu ersetzen, bei Handwerkern sieht es anders aus.
Vielleicht schaffen es demnächst die "Roboter", die werden uns ja schon seit ca 50 Jahren als Arbeitsplatz-Vernichter angekündigt.
In einem Lobby-Unternehmen aus Mundwerkern ist es auch keine Hürde
den Grossteil der Mit"arbeiter" durch Blafassel-Generatoren zu ersetzen,
bei Handwerkern sieht es anders aus.
Ja, das sehen wir ja gerade bei den großen strategischen Unternehmensberatungen, die ja traditionell Scharen an superschmierigen "Junior Consultants" für Schreibarbeiten und zum Kaffeekochen in der Welt verteilen, natürlich zu abenteuerlichen Stundensätzen. Und letztendlich entstehen dabei dann eine Hanvoll Hochglanz-Powerpoint-Folien auf der Basis von irgendwelchen Standardvorlagen. Das eigentliche Ergebnis solcher Beratungen wird ja meist schon durch den Auftraggeber vorab festgelegt.
Abgesehen vom Kaffeekochen sind das alles Tätigkeiten, die jedes Large-Label-Modell schon deutlich besser und billiger hinbekommt, bei höherer Qualität. Und fürs Kaffeekochen gibt es ja mittlerweile Automaten.
Vielleicht schaffen es demnächst die "Roboter", die werden uns ja schon
seit ca 50 Jahren als Arbeitsplatz-Vernichter angekündigt.
Die Aufgaben verschieben sich eben, so wie schon Jahrzehnten auch schon.
Der wesentlich Punkt wird aber in dem Cartoon völlig vergessen, nämlich die kompetente Instruierung der KI. Trotzdem ist er lustig. Allerdings beantwortet der menschliche Mitarbeiter die Frage des Chefs genauso schlecht wie ein LLM sie vor drei Jahren beantwortet hätte.
Ja, bei einem me-too Schaumschlaegerunternehmen mag das durchaus sein. Etablierte Unternehmen, die solche Experimente bereits durchhaben, ueben sich in Schadensbegrenzung, nennen darf ich hier z.B. Klarna.
Ich bin uebrigens weit vom Jammern entfernt, eher amuesiert, wieviele "Experten" die Gebetsmuehle bedienen, was denn in 2-3 Jahren alles moeglich ist - wenn die Blase nicht platzt.
Die nahe Zukunft sieht eher so aus, dass die KI-Dienstleister baldigst zugeben werden muessen, dass sie durchaus breitbandig weiterlernen, man also davon ausgehen kann, dass der Code (beauftragt oder vom Kunden selber) implizit auch bei der Konkurrenz landen kann.
Bei 0815 Statemachines ist das kaum relevant, bei einem cleveren Algo schon.
Die andere Variante ist die, dass die gebotenen Loehne fuer spezialisierte AI-Trainer irgendwann so astronomisch werden, dass man den Scheiss halt macht, und dann auf Klimatechnik umsattelt. Hat mehr Zukunft :-)
Da es sich um ein laufendes Kundenprojekt handelt, nenne ich an dieser
Stelle nicht den Baustein.
Und Du hast keine Datenschutzbedenken?
Der KI-Betreiber kennt ja nun auch Ross & Reiter (Chip & Code).
Um die Kosten zu drücken (bzw. den Gewinn zu maximieren) wird er dieses Wissen auch zu Geld machen wollen...
... Allerdings beantwortet der menschliche Mitarbeiter die Frage des Chefs genauso schlecht wie ein LLM sie vor drei Jahren beantwortet hätte....
IMHO beantwortet er die (dumme) Frage des Chefs gemau richtig, die Metrik LoC/min ist komplett Banane und das nicht erst sit dem LLM-Zeitalter. Schon der CoreGen erator der ISE vor 25 Jahren ballerte anständig viel VHDL/Verilog Code auf Knopfdruck raus, "Generate Output Products" beim Vivado Block designer toppt das nochmal.
Wie man damit ein stabiles System bastelt ist 'ne ganz andere Frage ...
Und fürs Kaffeekochen gibt es ja mittlerweile Automaten.
Naja, es gibt ja durchaus auch Kaffeemaschinen, die nicht so teuer sind, ordentlichen Kaffee kochen und dann auch noch lange halten. Aber: bei Rossmann bei uns gibt es immer noch (zum Glück) Equip, um Kaffeepulver von Hand (mit Filteraufsatz oder ohne) zu überbrühen. Eine andere Sache wäre noch die Kaffeegramm-Ausmessung, z.B. zwischen 35g und 55g pro Liter, wer lieber dünneren Kaffee trinkt, und wer lieber starken Kaffee trinkt. Das ist individuell recht unterschiedlich. Eventuell kann man aber mit mehreren Leuten einen Kompromiss ausdiskutieren (z.B. 42g ;).
Grundsätzlich ist der Thread hier von J.S. auch ein guter Ansatz, der dazu inspiriert, mehr mit den KIs herumzuprobieren. Das ist wichtig - denn teilweise haben die kein Gedächtnis, so dass man die immer direkt aktuell verbessern, oder auf Hindernisse hinweisen oder auf Korrigierungen hinweisen muss. Das heißt, auch wir brauchen Übung und die Zusammenarbeit mit den KIs sollte aktuell auch verbessert werden - das geht aber nur mit viel Übung und Know How.
Und fürs Kaffeekochen gibt es ja mittlerweile Automaten.
Naja, es gibt ja durchaus auch Kaffeemaschinen, die nicht so teuer sind,
ordentlichen Kaffee kochen und dann auch noch lange halten. Aber: bei
Rossmann bei uns gibt es immer noch (zum Glück) Equip, um Kaffeepulver
von Hand (mit Filteraufsatz oder ohne) zu überbrühen. Eine andere Sache
wäre noch die Kaffeegramm-Ausmessung, z.B. zwischen 35g und 55g pro
Liter, wer lieber dünneren Kaffee trinkt, und wer lieber starken Kaffee
trinkt. Das ist individuell recht unterschiedlich. Eventuell kann man
aber mit mehreren Leuten einen Kompromiss ausdiskutieren (z.B. 42g ;).
In Unternehmen, in denen bisher die schmierigen Junior Consultants der großen Unternehmensberatungen herumlaufen, gibt es kaum konventionelle Kaffeemaschinen, sondern nur noch große Vollautomaten, deren Betrieb in ein eigenes "Profit Center" oder Subunternehmen ausgelagert wurde. Und Handfilter sind in solchen Läden natürlich auch schon lange durch die Abteilung für Arbeitssicherheit verboten worden, weil man sich damit die Finger verbrühen kann. Einfache, billige Kaffeemaschinen dürfen nicht mehr in den Büros und Kaffeeküchen wegen der Brandgefahr bei defektem Thermoschalter betrieben werden.
Bei einem Kunden habe ich selbst die Neiddebatten mitbekommen, weil auf Flur 1 ein modernerner Vollautomat steht als auf Flur 2. Daraus wurden dann gleich irgendwelche Vorschwörungserzählungen konstruiert. Und manche Leute rannten dann extra in einen anderen Gebäudeteil, um dort ihren Kaffee zu holen, um es "denen da oben" zu zeigen, dass sie es sich nicht bieten lassen, nur einen veralteten Kaffeeautomaten vorgesetzt zu bekommen. Diese Leute räumten durchaus ein, dass beide Kaffees völlig gleichwertig waren, aber es ging natürlich ums Prinzip. Ich vermute auch mal, dass die Automaten gar nicht durch das Unternehmen selbst betrieben wurden, sondern einen Automatenaufsteller, der einen Automaten dann ersetzt, wenn er defekt ist und die Reparatur nicht mehr lohnt. Und nicht, um damit zu zeigen, dass Sachbearbeiter A über Sachbearbeiter B aus der Nachbarabteilung stünde.
Es spielt keine Rolle was ich, oder jeder einzelne darüber denkt. Es ist ein verdammt nützliches Werkzeug, das mittlerweile in der Lage ist, einen Großteil der Trivialaufgaben gut umzusetzen. Ob es "am Besten" ist, interessiert für diese Aufgaben oft gar nicht, weil es nicht auf die optimale Lösung ankommt.
Ich habe vor nem Jahr eine App für ein Tablett programmieren lassen. Klar musste ich viel Händchen halten, aber das Ding läuft bis heute stabil.
Es ist mir vollkommen egal, ob der Code elegant, oder umständlich ist; er ist funktionial. Mehr interessiert mich dabei gar nicht.
Und ich hatte damals von Java genauso viel Ahnung, wie heute.
Ich hätte die App auch selbst programmieren können, aber alleine die Recherche fürs Android SDK hätte mir vielfach mehr Zeit gekostet, als die komplette App entwickeln zu lassen.
Findet euch damit ab; die Zeiten des 08-15-Entwicklers sind längst angezählt.
In Unternehmen, in denen bisher die schmierigen Junior Consultants der
großen Unternehmensberatungen herumlaufen, gibt es kaum konventionelle
Kaffeemaschinen, sondern nur noch große Vollautomaten, deren Betrieb in
ein eigenes "Profit Center" oder Subunternehmen ausgelagert wurde.
Ach ja. Die tollen Unternehmsberater. Vor allem Disneyland hat sich damit so richtig böse die Finger verbrannt.
In Unternehmen, in denen bisher die schmierigen Junior Consultants der
großen Unternehmensberatungen herumlaufen, gibt es kaum konventionelle
Kaffeemaschinen, sondern nur noch große Vollautomaten, deren Betrieb in
ein eigenes "Profit Center" oder Subunternehmen ausgelagert wurde.
Ach ja. Die tollen Unternehmsberater. Vor allem Disneyland hat sich
damit so richtig böse die Finger verbrannt.
Genau. Und deren Geschäftsmodell bricht gerade gewaltig zusammen, was ich auch nicht unbedingt schlimm finde.
Da wäre die Frage was man jeweils hoch laden sollte, kann und darf - denn nicht alles möchte eine Firma aus der Hand geben.
Hier ging es ja zunächst nur um die Generation eines Filters auf der Basis rudimentärer Angaben.
Allerdings kommen wir dann schon zu meinem Punkt, wieviel ich an Aufwand treiben muss, bis AI verstanden hat, was ich brauche. Bei Filtern ist das noch ein einfaches Informationsinterface, würde ich sage, wobei es auch da die unterschiedlichsten Optionen gibt, vor allem im Hinblick auf Parallelisierung / Sequentialisierung und Anpassung an die eigene Architektur.
So sieht es aus. Im Grunde ist es eigentlich einfach, die Strategie zu applizieren, WIE man sowas pipelinen muss, um rotierend Daten zu behandeln, allerdings geht das nur eindimensional, weil bei Rekursionen und Iterationen unterschiedliche Randbedingungen greifen. Die zumindest müsste man ja definieren, wenn das Ergebnis passen soll. Und da ist im eigenen Kopf die Lösung binnen Sekunden da, muss nur noch umgesetzt werden. Will man das aber so vorzeichnen, daß ein anderer es hinbringt, sitzt man zur vollständigen Formulierung erst einmal eine Weile.
Bei MATHWORKS zumindest steht die seit 15 Jahren auf Anfang. Die grundsätzlichen Probleme sind nämlich immer dieselben, nämlich den Beschreibungsaufwand zu leisten, der nötig ist, um die Vielzahl möglicher Lösungen einzugrenzen. Die IIR-Filter die der Coder auswirft sind nach wie vor nicht wirklich effizient.
Aber sobald sich jemand
dem Thema annimmt, ändert sich das
Habe ich mir angesehen: Ist alles richtig, aber auch das löst nicht das Grundproblem:
Der Aufwand eine Lösung so einzugrenzen dass sie 100% passt, wächst mit der Komplexität gewaltig und es ist eben oft nur eine Frage von Sekunden, mit dem Wissen aller Randbedinungen eine passende Lösung im Kopf zu erdenken und vielleicht 1h sie zu skizzieren, um sie mit Kollegen zu verifizieren und die sich ergebenden Effekte auf HW, SW und FW anderer abzugleichen.
Um es aber so zu formulieren, dass es jemand bauen kann, braucht es Stunden oder Tage.
Daher wird das ja oft gar nicht gemacht, sondern der Code reingetippt und notdrüftig dokumentiert.
Bei vielen Arbeiten in VHDL ist es ja nur Code reinkopieren, anpassen oder einen Core-Gen-Wrapper zu instanziieren, weil es die Funktion schon gibt. Das sind Minuten. Die meiste Zeit geht fürs Konfigurieren des Core-Gens drauf. Die Info braucht die KI auch.
Und sie braucht noch mehr:
Sie braucht alle Randbedingungen des Projektes wie Kosten, Zeitreserven, Hardwarestrukturen und geplante SW-Abläufe. Das alles müsste man übergeben werden, wenn die Lösung optimal sein soll. Das wirft aber wieder das o.g. Problem 1 auf, daß man einer fremden Intelligenz / Institution sehr viel an eigenem Knowhow übergeben müsste.
Code-Erstellung auf AI-Basis eignet sich daher nur für konkrete abgekoppelte Module, die auch mit wenig Text und info zu beschreiben sind. Allerdings sehe ich auch da technische Probleme. Ich werde da gfs mal ein Beispiel bringen.
Sie braucht alle Randbedingungen des Projektes wie Kosten, Zeitreserven,
Hardwarestrukturen und geplante SW-Abläufe. Das alles müsste man
übergeben werden, wenn die Lösung optimal sein soll.
Das ist in der Softwareentwicklung allerdings längst Realität. Du sagst der KI "Implementier mal den Feature Request 1234", die KI holt sich selbständig die Beschreibung, die Projekt-Doku, Anforderungen, Abhängigkeiten, liest noch mal die aktuellen Diskussionen aus dem Team-Messenger, setzt die Buildumgebung auf, etc., und was rauskommt ist der Pull Request; passt der dir nicht, gibst du Feedback und die KI arbeitet das ein. Eben genau so, wie man mit einem (Junior-)Entwickler zusammenarbeiten würde – nur dass du das Ergebnis schon nach einer Stunde bekommst. Sicher sind in der Hardwareentwicklung die Prozesse etwas weniger agil, aber im Grunde sollte das ja auch so funktionieren.
Das wirft aber
wieder das o.g. Problem 1 auf, daß man einer fremden Intelligenz /
Institution sehr viel an eigenem Knowhow übergeben müsste.
Da musst du dir die Verträge ansehen. Standard bei Anthropic ist m.W. dass Interaktionen nicht gespeichert werden. Wenn du dich darauf nicht verlassen willst, ok, aber eine realistische Risikoeinschätzung wird da wohl auch nicht schlechter aussehen als bei dem EDV-Dienstleister von Nebenan. Und am Ende wird das ganz einfach so laufen: wer da seine Produktivität mit zu vielen Bedenken einschränkt – unabhängig wie begründet die im Einzelfall sein mögen – wird von der Konkurrenz abgehängt.
Ja, Softwareentwicklung wo man durch Compilerwahl, Prozessorvorgaben und zeitliche Randbedingungen sehr viel vorgeben kann, was die möglichen Strukturen angeht. Das gilt auch für die hier im Strang erwähnten Beispiele der Treiber. Da ist es auch für einen Entwickler relativ linear möglich, die SW mehr oder weniger hinzuschreiben.
Noch klarer formuliert: Es entsteht aus wenig Beschreibung viel Code. Was die Requirementanalyse angeht, steht und fällt das dann mit der Vollständigkeit der REQs und bei der SW ist auch die recht gut linear und isoliert zu formulieren.
Bei HW (in VHDL oder elektrisch) sieht das aber deutlich anders aus. Da steht vieles nicht als REQ fest, sodaß man es als Rahmen für die SW nehmen kann, sondern muss auch erstmal erdacht und eben formuliert werden. Wenn ich aber die Lösung sehe, schreibe ich sie rein und formuliere nicht mit 10-fachem Aufwand das Problem, um das Finden der KI zu überlassen.
Ich bringe wie gesagt dazu ein Beispiel. Muss dazu nur noch was vorbereiten.
KI-Chats werden die Leute wohl wieder dazu bringen, sich richtig
ausdrücken,
sprich ganze Sätze und umfassend formulieren zu können.
paar Smilies und "öj digga" reichen da eben nicht.
Wunschdenken. Wenn Du Teenagerkinder hättest wüsstest du, das die KI problemlos auch Jugendsprache verarbeitet - und sie besser versteht als der durchschnittliche Erziehungsberechtigte....
Der Knackpunkt ist bei VHDL (und Verilog), dass die KI architektonisch viel leisten muss, um eine sinnvoll verzahnte Mimik zu stemmen, und dann noch korrekte Syntax auszugeben. Die KI-Agenten sind typischerweise schnelle und praezise Coder, aber keine guten Architekten (diese pauschale Aussage ist debattierbar :-) ). Das muss die DSL (domain specific language) leisten.
Das laeuft meiner Erfahrung nach auf folgendes raus:
Abstraktion des Reset-Modells (wie es schon myhdl vorfuehrt), Zaehlern, usw.
Abstraktion von Pipelining (cyrite HLS)
Duales Sprachmodell: Ausfuehrung und Transpilation je nach Target
Klare Trennung von funktionaler Beschreibung und Inferenz
Also mehr in Richtung abstrakter, aber expliziter HLS-Konstrukte/Klassen.
Dann ist die KI auch in der Lage, den allfaelligen Unfug, den sie ausgibt, zu verifizieren.
Als Beispiel der Workflow zu einer simplen Formel, wie z.B. ein Filter:
1
1) KI gibt ein Python-Snippet inkl. Plot aus, verifiziert per Testdaten
2
2) Refine: Gib es in der (beigebrachten) DSL aus
3
3) Verify: Verifiziere die korrekte Funktion per a) reine Ausfuehrung, b) Simulation der inferierten HW-Elemente
4
4) Iterate: Probiere diverse Inferenzvarianten (Pipelined, Multi-lane, FSM), und finde die beste fuer den entsprechenden Target
5
5) Co-Simulate: Verifiziere die Formel aus der originalen Anwendung gegen die virtualisierte HW-Komponente
Die DSL deckt dann per Trennung in Beschreibung und Designregeln die eigentliche Generierung der Architektur ab.
Punkte 3-5 kann ChatGPT natuerlich nicht. Aber er lernt sehr wissbegierig die DSL und wendet sie bis auf einige Eckfaelle richtig an.
Die Schleife ueber die Verifikation kann der Agent auch legal per GHDL/icarus vollziehen, wird auch schlussendlich fuer den Schritt "Transpilation" gemacht, denn auch da koennte ja die DSL Mist bauen. Das ist als laufende Verifikation fuer die KI ziemlich resourcenhungrig, ich glaube nicht, dass die teuren Modelle das auf die klassische Art effizient stemmen werden - solange ihnen diese gewisse Basis fehlt.
Spannend waere mal noch ein Vergleich mit Spade. Falls jemand mal Lust hat...
Der KI-Betreiber kennt ja nun auch Ross & Reiter (Chip & Code).
Um die Kosten zu drücken (bzw. den Gewinn zu maximieren) wird er dieses
Wissen auch zu Geld machen wollen...
Es handelt sich im konkreten Fall um ein absolutes Nischenprodukt. Die Zephyr-Treiber für die fehlenden Komponenten wurden und werden von mir eh veröffentlicht und landen dann im Mainline-Zephyr-Repository. Es handelt sich also höchstens um einen minimalen zeitlichen Vorsprung. Der Vorteil, dass fortan solche veröffentlichten Treiber dann auch "automatisch" immer zum neuesten Zephyr passend gehalten werden, überwiegt die Nachteile, die aus der Veröffentlichung entstehen, ganz erheblich. Im konkreten Fall läuft auf dem betreffenden Microcontroller eh nicht die schützenswerte Anwendung meines Kunden, d.h. sie wird auch nicht OpenAI zum Fraß vorgeworfen.
Und am Ende wird das ganz einfach so laufen: wer da seine
Produktivität mit zu vielen Bedenken einschränkt – unabhängig wie
begründet die im Einzelfall sein mögen – wird von der Konkurrenz
abgehängt.
Willkommen in Deutschland! Es muss eben alles so verbürokratisiert werden, dass das sinnvollste Projekt zwar nicht komplett scheitert, sondern eben unter der Last von Bedenken und Formalismen langsam erstickt. Und niemand will daran Schuld gehabt haben, denn jeder hat ja nur vorsichtig gewarnt.
Die großen KI Modelle beruhen meines Wissens nach alle auf geklauten
Medien. Dem Dieb nicht zu vertrauen ist naheliegend.
Es werden bei dieser Betrachtung häufig völlig falsche Maßstäbe angesetzt. Einem menschlichen Absolventen wirft man ja auch nicht vor, er hätte nur das vermittelte Wissen aus den Lehrveranstaltungen und den Lehrbüchern geklaut, um sich anschließend in seinem Beruf daran zu bereichern.
Wer etwas veröffentlicht, so dass Dritte es sich anschauen, anhören, lesen, sonstwas können, muss immer davon ausgehen, dass sich derjenige einige Inhalte merkt und sie später verwendet, auch ohne immer angeben zu können, woher dieses Wissen stammt. Oder erwartest Du etwa eine vollständige Quellenangabe zu jedem Pups? Fange ich doch gleich mal an: Grundschule, 1. Klasse, Frau Krönert. Gymnasium, 5. Klasse, Herr Schuldt.
Der Knackpunkt ist bei VHDL (und Verilog), dass die KI architektonisch
viel leisten muss, um eine sinnvoll verzahnte Mimik zu stemmen, und dann
noch korrekte Syntax auszugeben
Das ist das kleinste Problem, denke ich. Mit mehr Wissen und Training können auch die AI-Modelle in die Lage versetzt werden, Polarion zu durchforsten und die Entwicklungsprozesse abzubilden, um SW und HW zu definieren. Auch eine elektronische Schaltung sollten sie entwerfen können, wenn sie genug in der LIB haben. Oft ist das Schaltungsdesign auch nur ein Aneinanderkleben bekannter Module.
Das Problem ist ein anderes:
Man muss die HW auch irgendwann haben und es testen, d.h. das muss sich in das Gefüge der Entwicklung einpassen lassen. Da hängt es oft genug davon ab, was eine Firma an Messtechnik hat, was sie bereits an Modulen besitzt und was sie an Knowhow und Manpower hat, um all das in Betrieb zu nehmen. All das bestimmt den Lösungsansatz. Vielfach muss entschieden werden, etwas selbst zu bauen oder zu kaufen.
Einem menschlichen Absolventen wirft man ja auch nicht vor, er hätte nur
das vermittelte Wissen aus den Lehrveranstaltungen und den Lehrbüchern
geklaut,
Das ist ein wenig etwas anderes:
Der Absolvent ist kaum an Frontentwicklungen eingesetzt und macht Standardsachen.
Was er an Wissen mitbringt, ist auch Lernwissen das jedem zugänglich ist.
Wovon hier die Rede aber war, ist das Spezialwissen der Firma, also ihre IP, mit der sie Geld verdient. Ausgelagert an Anfänger und externe Dienstleister wird meistens das Doing! als die Umsetzung. Wir geben z.B. VHDL und Schaltplanentwicklung raus, aber das ist das VHDL-Treiberpaket, glue-Logic und einfach FSMs die das Verschalten. Das wird von der Firma aber so nebenbei miterledigt, weil sie das Meiste schon haben. An einem ADC-Auslese-Code ist nicht viel Geheimes dran.
Das Entscheidende ist, WAS mit dem ADC eingelesen wird, welche Bedeutung es hat und warum es 12Bit sind. Das weiß der Zulieferer nicht.
Und es gibt noch einen Punkt:
Einen Zulieferer kann ich dazu verpflichten, die Daten geheime zu halten - eine AI nicht, weil nicht nachweisbar ist, wann die was wo erlernt oder mitgenommen haben könnte.
Wer etwas veröffentlicht, so dass Dritte es sich anschauen, anhören,
lesen, sonstwas können, muss immer davon ausgehen, dass sich derjenige
einige Inhalte merkt und sie später verwendet
Daher werden kritische und wichtige Dinge eben nicht herausgegeben. Nicht an Menschen auch auch nicht an Maschinen. Besonders nicht, wenn sie in den USA sind, nach Hause telefonieren und der dortige Regierungschef Dekrete erlässt, wonach diese Firmen jederzeit Kundendaten preisgeben müssen.
Was man sich allerdings im Zusammenhang damit fragen sollte, ist, ob man
die KI mit solchen Eckdaten und seinem Knowhow ueberhaupt trainieren
will. Je nach Modell ist die Begierigkeit zu lernen eher gruselig als
hilfreich.
Wenn du es nicht willst, tun es andere.
Was man dabei nicht vergessen darf:
Die AI-Hersteller wollen Geld verdienen. Wenn wieder zuviele Nutzer da sind, die damit billiger produzieren können, macht keiner von denen mehr Gewinne, weil zwar mit den Kosten runterkommen, das die anderen aber auch tun und das unterbieten zum Preisverfall am Endprodukt führt. Das haben wir ja durch praktisch alle Innovationen, sei es C-Compiler gegen Assembler, Python gegen C, MATLAB HDL-Coder gegen Inder.
Es wird also einen Punkt geben, wo es sich nicht mehr rechnet, mehr für AI auszugeben, als sie wirklich hilft und die Trainierei kostet viel Zeit und Geld. Momentan investieren viele dort, um die Ersten zu sein, das wird sich aber beruhigen.
Was VHDL betrifft, werden die Synthesetools weiter intelligenter werden. Das superschnelle Compilieren und der große Zeitgewinn gehen aber mit Mehrkosten beim Silizium einher. Schon jetzt verzichtet die Synthese auf Feinoptimierungen, um Zeit zu sparen, damit die immer größer werdenden FPGAs noch in akzeptablen Zeiten gebaut werden.
Wer etwas veröffentlicht, so dass Dritte es sich anschauen, anhören,
lesen, sonstwas können, muss immer davon ausgehen, dass sich derjenige
einige Inhalte merkt und sie später verwendet, auch ohne immer angeben
zu können, woher dieses Wissen stammt. Oder erwartest Du etwa eine
vollständige Quellenangabe zu jedem Pups? Fange ich doch gleich mal an:
Grundschule, 1. Klasse, Frau Krönert. Gymnasium, 5. Klasse, Herr
Schuldt.
Du mußtest eine Grundschule und ein Gymnasium besuchen, um Pupsen zu lernen? :-)
Einen Zulieferer kann ich dazu verpflichten, die Daten geheime zu halten
eine AI nicht, weil nicht nachweisbar ist, wann die was wo erlernt
oder mitgenommen haben könnte.
Eine AI lernt aber keine Daten, sondern Zusammenhänge. Ein Token wie "sammen" ist für sie nur ein n-dimensionales Array aus Zahlen und nur das Word Embedding stellt die Verbindung zwischen den beiden her -- das aber nicht einmal Bestandteil des eigentlichen AI-Modells, sondern nur dessen Pre- und Postprocessing ist.
Einen Zulieferer kann ich dazu verpflichten, die Daten geheime zu halten
[...]
Daher werden kritische und wichtige Dinge eben nicht herausgegeben.
Nicht an Menschen auch auch nicht an Maschinen.
Sowohl Mitarbeiter des Zulieferers als auch die eigenen Mitarbeiter erfahren hierbei aber einen Haufen Dinge, die sie später für andere Tätigkeiten verwenden können. Und es gibt keine legale Möglichkeit, diese Mitarbeiter daran zu hindern, dies zu tun. Natürlich darf dabei nichts mitgenommen und 1:1 kopiert werden, aber spätestens auf der Konzeptebene wird es unmöglich, die Nutzung dieser Erfahrung zu unterbinden, egal ob irgendwelche Geheimhaltungsvereinbarungen unterzeichnet wurde. Auch vertragliche Bestimmungen, die einem untersagen, für Konkurrenten tätig zu werden, sind üblicherweise unwirksam bzw. nur für sehr kurze Zeit möglich. In Deutschland steht das Grundrecht über die freie Berufswahl über den Interessen alter Arbeitgeber.
Gewerbliche Schutzrechte (Patente, Gebrauchsmuster, Topologien, usw.) verhindern auch nicht im gerinsten, dass Erfahrungen genutzt werden, sondern decken einen anderen Sachverhalt ab.
Da mein Brötchengeber einen ganzen Zoo von Modellen für uns verfügbar macht, kann ich bissl probieren. Cloude Opus macht VHDL/Verilog am sinnvollsten und kennt auch viele Zusammenhänge. Aktuell lasse ich mir da bei JESD204 stark helfen, das erleichtert schon enorm die Arbeit, wenn einem jemand das ganze Geschriebsel abnimmt.
Da mein Brötchengeber einen ganzen Zoo von Modellen für uns
verfügbar macht, kann ich bissl probieren. Cloude Opus macht
VHDL/Verilog am sinnvollsten und kennt auch viele Zusammenhänge. Aktuell
lasse ich mir da bei JESD204 stark helfen, das erleichtert schon enorm
die Arbeit, wenn einem jemand das ganze Geschriebsel abnimmt.
Ja, Ich mache auch mehr mit AI, und claude/code macht da mal schon ganz vernünftiges code, und da macht claude schon gut zusammenarbeit mit Vivado für syntax check und simulation. Mit TCL kann claude auch viel helfen.
Das werde ich wohl auch mal testen. Heute war erst mal wieder GPT dran:
Ich habe mir erlaubt, mal zu testen, ob er meine spezielle Sinusapproximation hinbekommt. Er kommt mit allerlei Ansätzen rüber um sich da ranzutasten, bringt auch das richtige, versteht sogar meinen Zentriertrick, den Bitspartrick durch minimale Bereichseinschränkung und versucht immer wieder den jeweils erzeugten Code zu optimieren.
Das allerdings wird etwas Langwierig und man fragt sich, warum er das nicht gleich bringt - die eigentlichen Anforderungen ändern sich ja nicht. Er scheint immer mal wieder eine Seite zu finden, wo sich was Neues ergibt. Z.b hat er im Nachhinein Auflösungen hochskaliert, um sie dann wieder runter zu skalieren. hm.
Am Ende kam dann nach einer letzten Optimierung, wo er ein fertiges VHDL nochmal auf die Xilinx-Multiplier optimieren und testen wollte, plötzlich das hier, nachdem er den LSB-Fehler ausrechnen sollte:
ChatGPT schrieb während der Session:
Beim Durchprüfen des letzten VHDL-Entwurfs habe ich zwei echte Fehler gefunden, die wir vor einer Synthese korrigieren sollten
Quadranten-/Vorzeichenpipeline war falsch ausgerichtet
valid war nicht um die gesamte Rechenlatenz verzögert
Aha! Der ganze Quark vorher war falsch. Habe es simuliert und in der Tat passt das pipelinen nicht. Hinten und vorne nicht. Er nennt auch das ledigliche Hintereinanderkleben direkt "pipelinen" sorgt aber nicht für einen geraden Fluß. Da muss man selber ran.
Da habe ich abgebrochen und ihm meine Lösung verbal hingeschrieben. Die hat er dann sofort gut gefunden und als es nach 2,3 Korrekturen lief, hat er es auch optimieren können.
Je nach Iterationstiefe kamen dann optimierte Versionen, die sich insgesamt etwas voneinander in den Koeffizienten unterscheiden, weil der jeweils fehlende Rest durch Abbruch der Iteration durch die anderen etwas ausgeglichen wird. Das System hat er aber nicht verstanden, er konnte nicht selber die nächste Iteration bestimmen - obwohl es aus dem Schema der Beispiele, meines Erachtens ablesbar ist.
Man hat etwas den Eindruck, dass er von mir mehr lernt, als ich von ihm :-)
Trotzdem ist das natürlich ein Vorteil: Ich habe jetzt die Versionen für unterschiedliche Qualitäten explizit daliegen. Und: Zu jedem gibt es eine eigene Testbench. Nachdem man ihm nämlich erklärt hat, was er machen soll, baut er die für alle Teile formal korrekt auf.
Das ist natürlich sehr bequem, sich die Schreiberei zu sparen. Vor allem die umständlichen Records und Funktionen mit / in Packages sind Ruckzuck da, während man sonst 1/2h tippt.
die zuletzt von ihm generierte und optimierte Version hat leider auch einen Fehler - obwohl er ja behauptet das erkannt zu haben. Sie liefert keinen Sinus mehr, sondern an zwei Stellen unter / überläufe und hat einen Rechenfehler. Man muss also aufpassen, was dort gebaut wird und wie es optimiert wird.
Auch eine meiner Versionen packt nicht ganz den gewünschten Bereich. Die Optimierungen die er anhand eines selbe generierten Python-Scripts im Hintergrund vornimmt, scheinen ihn zu überfordern. Da geht es in die Wiese.
Abgesehen davon liegt in dem pauschalen Optimieren einer sochen Funktion auch noch ein Denkfehler: Je nach benutzter Frequenz werden bestimmte Phasen abgetastet, die man im Vorhinein nicht kennt. Daher kann man die Fehler, die dann in Summe in der generierten Frequenz auftauchen, nicht optimieren.
... eine der vorherigen funktionierenden Versionen vor der Optimierung meldet:
[DRC REQP-1723] DSP_Abus_sign_bit_restriction: sin_1/ARG__2: When using the PreAdder and USE_DPORT is TRUE, the A operand should be restricted to 24 bit two's complement (and sign extended) to avoid over/underflow in the pre-add stage.
... synthetisiert aber zu einem funktionierenden design. Bohrt man die falsch optimierte VHDL wieder auf, hat man auch keine Fehler mehr. Es läuft korrekt! Allerdings ist der resourcen-Bedarf ein Witz:
zwei Stellen unter / überläufe und hat einen Rechenfehler. Man muss
also aufpassen, was dort gebaut wird und wie es optimiert wird.
Das sehe ich als grosses Problem bei KI an. Wenn man nur noch auf Promptebene arbeitet und irgend ein Detail verbessert dann kann es jederzeit passieren das etwas anderes dabei kaputt geht. Im viel staerkeren Masse wie bei normaler Programmierung.
Deshalb hab ich erstmal beschlossen nur noch Teilaspekte, z.B Klassen bei c++ erstellen zu lassen.
irgend ein Detail verbessert dann kann es jederzeit passieren das etwas
anderes dabei kaputt geht.
Das finde ich erschreckend und zugleich seltsam! Angeblich kann die KI das doch selber überprüfen und liefert sogar Testumgebungen. Wieso ist sie nicht in der Lage, das zu erkennen?
Kann es sein, daß die Simulation zu lange dauert und übergangen wird oder abgekürzt?
Ich habe auch schon Code generieren lassen, bekamt eine Testbench und konnte dann selber simulieren. Das war denn der Hauptteil. Dann konnte ich der KI sagen, was nicht funktioniert und sie hat es dazugebaut.
Im viel staerkeren Masse wie bei normaler
Programmierung.
Bedenklich!
Deshalb hab ich erstmal beschlossen nur noch Teilaspekte, z.B Klassen
bei c++ erstellen zu lassen.
Spechen wir da vom FPGA ode allgemein?
Die Klassenerstellung klapte bisher bei mir sehr gut, wo es hakt, ist das Modell der Software insgesamt. Das gilt besonders für ARM-Code in Zynq: Da schiebt es entweder alles in die eine- oder in die andere Richtung. Er verteilt z.B. keine PS/PL.
Und was man sagen muss: Die Hauptarbeit bei der Simulation ist am Ende doch die Arbeit mit Questa. Die bleibt. Damit wird die gesammte Entwicklungszeit nicht wesentlich kürzer. Bei Ingenieuren soll KI aber immerhin noch 10% der Arbeitspltze einsparen:
Beitrag "Auswirkung von KI auf den Arbeitsmarkt für Ingnieuere und Informatiker"
