ChatGPT kann schon VHDL oder verilog generieren aber sobald es mehr als LED blinky ist, funktioniert die code meistens nicht, und es ist nicht leicht die fehler der ChatGPT zu beheben. Im grunde genommen ist ChatGPT nutzlos für FPGA entwicklung. Da ist aber interessant das RapidSilicon eigene FPGA AI generator vorgestellt hat, es war anfangs direct auf der Rapidsilicon website, jetzt ist es aber abkoppelt und anscheinend hat man eine neue firma dafür gegründet: https://primis.ai/ Das ist die neue firma, das product heisst aber immer noch RapidGPT. Den RapidGPT habe ich ausprobiert, anfangs war es schlimmer als ChatGPT, aber dann haben die RapidGPT leute ein paar tricks gemacht und dann kam aus dem RapidGPT schon relative komplexes code raus, fast fehler frei. Das RapidGPT gibt es nur als kostenlosen version, später wollen die bezahlte optionen auch haben. So wie ich verstanden habe sollten die RapidSilicon FPGA tools auch den RapidGPT funktion haben, aber bin da nicht ganz sicher, vielleicht ist es doch entkoppelt. Der RapidGPT ist nicht mit RapidSilicon FPGA's verbunden, es generiert code für egal welchen FPGA.
Vor 22 Jahren sagte der Gruppenleiter der AMD-ChipdesignAbteilung in Dresden (DDC) zu mir, das das langwierigste an seiner Arbeit die Spezifikation/Konzept ist. Ist es erstmal klar, was die Logik tun soll ist die dazu passende Statemachine schnell runtergeschrieben. Da liegt also die Fokus der Arbeit eindeutig vor der HDL-Code-erstellung. Aber auch nach der HDL-Codeerstellung läuft es nicht einfach durch, dann hat man mit Bugs/Eigenheiten der Software zu kämpfen. Da dauert es oft Tage bis man irgendwo den Tipp findet, irgendwo eine magische Zahl zu setzen, das die Tools wenigstens als workaround durchläuft. Vom Tool-Hersteller bekommt man dann die "Gratulation" das man einen Bug gefunden hat, der in einer zukünftigen Tool-version gefixt sein könnte. Bsp: https://www.intel.com/content/www/us/en/support/programmable/articles/000083704.html Für diese zeitfressenden Arbeiten nach der Coderstellung wäre eine Suchbeschleunigung in der Knowledgebase etc. IMHO sehr sinnvoll. Essentielle Optimierungen verlangen oft größere Änderungen, beispielsweise, angepasstes pinout (IO-Bankaufteilung) oder Minimierung/Elimination des Reset-Netzwerkes. Das sind dann auch Änderungen, die nicht im HDL-code liegen, also auch hier wird "der Schraubenschlüssel an der falschen Stelle" angesetzt, wenn man eine HDL-Code-plappernde AI einsetzt. Zitate aus der AI-FAQ: "RapidGPT can assist hardware designers by providing intelligent code suggestions and generating Verilog code based on design intent." "Does RapidGPT provide code optimization suggestions? Yes, RapidGPT can identify potential errors or inconsistencies in your code and provide suggestions for optimization." In letzterem wird "Optimierung" mit "debugging" verwechselt. Und nach beiden Zitaten wird es keine "solution" sondern eine "suggestion" geben. Also munteres Rätselraten statt Problemanalyse und Vorbereitung der Entscheidungsfindung. Weil eben die Problemanalyse/Optimierung bei der FPGA-Entwicklung erfordert, das man sich die logs von Synthese, mapping, placer, simulation und STA anschaut. Da hilft bloßes Starren auf den blanken HDL-Code nicht weiter. -> was man braucht, wären Tipps von einem erfahrenen Designer, der Tools, den FPGA-Chip und die Probleme damit kennt. Und keine AI die im HDL-Code stochert resp. stochern lässt.
Antti L. schrieb: > Im grunde genommen ist ChatGPT > nutzlos für FPGA entwicklung. Diese Chat-Zeug ist nutzlos für jede Art von Entwicklung! Weil: - es nur Informationen reproduzieren kann, und ... - dies auch nur dann, wenn diese genügend oft vorliegt und so als "gesichert" = "richtig" angesehen wird - was aber wieder nur dann der Fall ist, wenn viele das schon in ähnlicher Art gepostet haben Dann aber braucht es nicht entwickelt zu werden, weil es ja schon da und bekannt ist. Obendrein ist es mittelmäßig, da von Vielen akzeptiert. -> BLÖDSINN!
Gustl B. schrieb: > Schlumpf schrieb: >> es nur Informationen reproduzieren kann, und ... > > Und schon falsch. alles was eine KI produziert ist letztenendes Schlussfolgerung auf der Basis der Erlernten und das ist immer Folge des Inputs durch Menschen
Ersetze bei deinem letzten Satz "KI" durch "Mensch". Also sind auch Menschen nicht kreativ weil die Ergebnisse eines kreativen Prozess auch nur auf Erlerntem basieren? Was ist eigentlich "kreativ"?
:
Bearbeitet durch User
Gustl B. schrieb: > Ersetze bei deinem letzten Satz "KI" durch "Mensch". > > Also sind auch Menschen nicht kreativ weil die Ergebnisse eines > kreativen Prozess auch nur auf Erlerntem basieren? > Was ist eigentlich "kreativ"? Die Kreativität des Menschen ist eine gänzlich andere. Sie ist in der Lage, Dinge, die ad hoc einfallen, zu plausibilisieren und mit anderen Erfahrungen zu korrellieren, infolge lebenslangen Lernens. Die Kreativität der KI ist darauf beschränkt, was ihr strukturell einprogrammiert und erlaubt wurde. Sie hat nicht die Erfahrung des Menschen, sondern die Durchschnittserfahrung mehrerer Menschen. Damit fallen die Ränder weg. Das Ergebnis sind Systeme, die die meisten Dinge sehr schnell richtig machen, sofoern trainiert, und einige wenige Grundfalsch. Beispiel ist der Tesla, der in eine Strasse einbiegt, weil er eine Lücke sieht und nicht kapiert, dass es ein sehr großer Laster war. Kein Mensch hätte das gemacht.
Es kommt daher daruf an, die KI als Zusatzsicherheit hinzuzuschalten, z.B. durch die Kameras im Auto, die die Verkehrszeichen sehen. In keinem Fall wird eine KI einen Menschen qualitativ ersetzen. Dort wo das scheinbar klappt, handelt es sich um Vorteile, die infolge quantitativer Vorteile ermöglicht wurde. Z.B. können solche System Arztdiagnosen stellen, weil sie eine Datenbank an Wissen dahinter haben, die von mehreren Hirnen erarbeitet wurde. Es bleibt aber dabei, dass damit immer nur das als gesichert weitergegeben wird, was von Vielen so angesehen wird. Damit hat man eine stabile Haltung, die durch die KI noch untermauert wird. Abweichungen von der Norm werden immer mehr ignoriert und übersehen.
Schlumpf schrieb: > Sie hat nicht die Erfahrung des Menschen, sondern die > Durchschnittserfahrung mehrerer Menschen. Damit fallen die Ränder weg. Hängt ganz von den Trainingsdaten ab. Schlumpf schrieb: > Kein Mensch hätte das gemacht. Nein? Wenn man mal bei Google Bilder sucht, dann findet man sehr viel Autos die unter LKWs stecken. Meist von hinten. Gut, Tesla hat da vielleicht ein Problem die Seite korrekt zu erkennen, Menschen haben aber dann das Problem den LKW von hinten zu erkennen und rechtzeitig zu bremsen.
Papa Schlumpf schrieb: > alles was eine KI produziert ist letztenendes Schlussfolgerung auf der > Basis der Erlernten und das ist immer Folge des Inputs durch Menschen KIs können z.B. Muster erkennen, wo Menschen keine Muster finden, z.B. in der Proteinfaltung. Das ist zu aufwändig um es zu simulieren und die anderen Verfahren (z.B. Kristallröntgen) sind auch sehr aufwändig. Die KI (Alphafold) hat es aber geschafft, die Faltungen richtig vorherzusagen. Das hat kein Mensch geschafft.
Papa Schlumpf schrieb: > Antti L. schrieb: >> Im grunde genommen ist ChatGPT >> nutzlos für FPGA entwicklung. > > Diese Chat-Zeug ist nutzlos für jede Art von Entwicklung! Weil: > > - es nur Informationen reproduzieren kann, und ... Das ist völlig ok. Vielleicht hast Du ja ein perfektes Gedächtnis, aber ich muss regelmäßig Dinge nachschlagen. > - was aber wieder nur dann der Fall ist, wenn viele das schon in > ähnlicher Art gepostet haben > > Dann aber braucht es nicht entwickelt zu werden, weil es ja schon da und > bekannt ist. Ich verstehe gar nicht, warum VW Autos baut. Mercedes baut doch auch schon Autos, da könnten sie sich doch den ganzen Aufwand sparen.
Klaus K. schrieb: > Weil eben die Problemanalyse/Optimierung bei der FPGA-Entwicklung > erfordert, das man sich die logs von Synthese, mapping, placer, > simulation und STA anschaut. Da hilft bloßes Starren auf den blanken > HDL-Code nicht weiter. Sowas kann man einer KI natürlich auch beibringen. Auch wenn RapidGPT das vielleicht nicht kann. > -> was man braucht, wären Tipps von einem erfahrenen Designer, der > Tools, den FPGA-Chip und die Probleme damit kennt. Und keine AI die im > HDL-Code stochert resp. stochern lässt. Large Language Models (LLM) gibts schon länger. Der große Durchbruch kam, als man angefangen hat, die Antworten von Menschen bewerten zu lassen und damit die KI korrigiert hat. Das ist doch genau das, was Du möchtest: Erfahrende Entwickler sollen weiterhelfen. Warum nur Dir und nicht der KI?
Ich habe mir RapidGPT einmal angeschaut: https://github.com/cpldcpu/LLM_HDL_Design/blob/main/VerySimple16bit_RapidGPTOct2023.md Vorher hatte ich bereits ähnliche Experimente mit Copilot und GPT4 durchgeführt: https://github.com/cpldcpu/LLM_HDL_Design/blob/main/VerySimple16bit_Oct2023.md RapidGPT kommt etwas besser als Copilot mit Verilog zurecht. Copilot scheint aktuell Verilog fast zu verweigern. Insgesamt liefert GPT4 aber doch noch konsistenteren Code. Ich vermute, RapidGPT ist einfach ein verfügbares LLM mit etwas finetuning? (CodeLLama? GPT3.5?). Das Hauptproblem ist einfach der Workflow. Aktuell funktioniert zero-shot Generation für HDL einfach noch nicht wirklich gut - zumindest deutlich schlechter als für z.B. Python. Wenn mann iterativ arbeitet, kann die vorhandenen Fehler nach- und nach beseitigen. Dafür fehlt aber irgendwie ein sauberer Workflow, der die verifikation automatisiert*. Am einfachsten ist es noch, sich ein Beispiel per AI erzeugen zu lassen und danach händisch weiter zu machen... *Siehe Code Interpreter
:
Bearbeitet durch User
Papa Schlumpf schrieb: > alles was eine KI produziert ist letztenendes Schlussfolgerung auf der > Basis der Erlernten und das ist immer Folge des Inputs durch Menschen Solche Argumente sind immer lustig, wenn man sie sich vor dem reelen Hintergrund von "not invented here" anschaut. Ein Tool, welches es schafft, unterschiedliche existierende und bekannte Lösungsansatze sauber und objektiv zu bewerten, würde in so gut wie allen Entwicklungsabteilungen die Arbeitsqualität deutlich steigern.
:
Bearbeitet durch User
Ich bin schon lange aus der HW-Entwicklung raus, aber habt ihr mal geprüft, ob GitHub Copilot VHDL oder Verilog kann? Ich benutze es für C++, Dart und Python und da ist schon sehr praktisch.
Slippin J. schrieb: > Ich bin schon lange aus der HW-Entwicklung raus, aber habt ihr mal > geprüft, ob GitHub Copilot VHDL oder Verilog kann? Ja, kann es. Die Ausgabequalität für "sequentielle" Programmiersprachen ist aber deutlich besser als für HDL. GPT4 hat da noch die Nase vorn.
Slippin J. schrieb: > ob GitHub Copilot VHDL oder Verilog kann? Bin ich gerade aktuell dran, mich damit zu befassen. Haber aber noch keine belastbaren Ergebnisse.
Moin, Ok, also dass es da Software gibt, die aus dem string "Mach mir mal einen Zaehler" funktionierenden HDL code rauskotzt ist ja schon mal ganz nett. Nur finde ich, hat das mit den realen Anforderungen an FPGA Design doch recht wenig zu tun. Ich bin zwar jetzt keiner der taeglich so Zeugs entwickelt, aber die Anforderungen sind doch etwas anders gestrickt - zumindest kommt mir das so vor. Es ist ja viel Brimborium aussenrum, also erstmal so Fragen wie: Was ist ueberhaupt sinnvoll im FPGA zu machen, was mache ich in anderer HW, was aufm Prozessor in SW? Dann auch immer "beliebt": Auf wieviel verschiedene clk-domains kann ich die Wuensche eindampfen? Welche Signale/Datenraten brauche ich fuer die Uebergaenge? Wie siehts im konkreten Fall aus mit den gewuenschten IO-Standards/Spannungen; welcher Baustein kann das unterstuetzen, erbricht sich der Layouter evtl. vor Schreck spontan? Was fuer Baukloetze (IP-cores) braucht man, was gibt es von welchen Herstellern zu welchem Preis und was ist sinnvoll einzusetzen? Und erst wenn das alles einigermassen festgezurrt ist, geht's in Richtung "mal was HDL schreiben (lassen)". Das ist dann gegenueber allem Anderen ja schon fast Meditation und Erholung. Gruss WK
Dergute W. schrieb: > Es ist ja viel Brimborium aussenrum, also erstmal so Fragen wie: Was ist > ueberhaupt sinnvoll im FPGA zu machen, was mache ich in anderer HW, was > aufm Prozessor in SW? Korrekt, die High-level Architektur macht ein Spezialist, der dann evtl. demnächst ein AI (LLM)-Tool für die lower-lever Implementierung nutzt. So war es eigentlich immer. Die höherwertige Arbeit liegt in der übergreifenden Hierachie, während die einfacheren Schritte automatisiert werden. In Zukunft gibt es dann gute FPGA-Architekten, die effiziente mit Generative AI umgehen können und solche, die lieber an alten Flows festhalten. Haben wir alles schon gesehen. (Warum eigentlich FPGA? ASICs sind viel effizienter, besonders wenn man das Layout direkt ins Rubilith schneidet?)
:
Bearbeitet durch User
Dergute W. schrieb: > Es ist ja viel Brimborium aussenrum, also erstmal so Fragen wie: Was ist > ueberhaupt sinnvoll im FPGA zu machen, was mache ich in anderer HW, was > aufm Prozessor in SW? Das ist schon richtig, aber das ist in etwa so, als ob Du einen Schrank bauen willst und jetzt der Säge vorwirfst, dass sie weder den Raum ausmessen noch die Zeichnung machen kann. Das macht die Säge aber nicht weniger nützlich. HDL schreiben ist einfach ein Schritt von vielen, der jetzt - vielleicht - etwas einfacher geworden ist. Es ist bei der FPGA-Entwicklung ja auch so wie bei der Softwareentwicklung: Ein gewisser Teil des Codes ist Trivialkram. Das x-te Mal Kommandos per SPI empfangen. Das y-te mal einen A/D-Wandler ansteuern. Das muss aber auch gemacht werden und wenn die lästigen Dinge jetzt schneller gehen ist der Entwickler und der Projektleiter glücklich.
Tim . schrieb: > In Zukunft gibt es dann gute FPGA-Architekten, die effiziente mit > Generative AI umgehen können und solche, die lieber an alten Flows > festhalten. Du verwechselst Vorgehen mit Umsetzung. Der Flow und dessen Organisation (= was muss bei FPGA alles passieren) ist eine andere Ebene als die Codierung (wie mich ich es formulieren), welche nur einen Teil davon darstellt. Das ist es, was ich im anderen thread mit Fokussierung meinte: Die KI-Enthusiasten richten ihren Blick auf den Code der entsteht, so als sei dieser der wesentliche output. Das ist Mitnichten der Fall. Die Erstellung des Codes belegt selbst in kleinen überschaubaren Projekten, die wenig Orga erfordern, nicht einmal 20% der Zeit. Bei größeren sind es 10% und weniger. Zum FPGA-Design kommen noch Elektonikentwicklung, FMEA- und andere Analysen, Entscheidungen, Tests, Inbetriebnahmen und Validierung hinzu, nebst Plänen dafür. Das alles sieht nur der Codierer nicht, weil er es häufig nicht macht. Im Übrigen bin ich persönlich der Code Automatisierung keinesweg negativ eingestellt. Ich bin nur nicht so hyper enthusiastisch, sondern sehe es nüchtern. Wir haben ja immer mal wieder Neuerungen im Bereich der Entwicklung und in der Tat ist genau durch Automatisierungen der Anteil des Codierens mehr und mehr geschrumpft. Vor allem ist er geschrumpft weil es viele Baukästen und Blöckchen gibt, sowie eben die Vielzahl von Code-Rümpfen der Entwickler selber. Von daher würde ich deine Aussage dahingehend modifizieren: In Zukunft gibt es gute FPGA-Architekten, die effizient mit generative AI umgehen können und damit die Codierer = VHDL-Entwickler ersetzen. Und ich hänge da noch hinein: Auch die C-Entwickler für die ZYNQs werden weniger zu tun haben. Über bleiben dann die, die Erfahrung von Grund auf haben, alle Bereiche kennen und einschätzen können, um zu entscheiden, wo man wann was nutzt ... ... und die im Einzelfall auch noch mal eine schlaue VHDL-Komponenten bauen können: Markus K. schrieb: > Das y-te mal einen A/D-Wandler ansteuern. Du glaubst gar nicht, auf wieviele Arten man einen AD-Wandler ansteuern kann. Z.B muss man den bei Faltungsoperationen, die auf reale Signale angewendet werden, keinesfalls stur mit fester Frequenz betreiben. Man kann bestimmte Aspekte der digitalen SV auch nach vorn ins Analoge ziehen, wenn man die zündende Idee hat und das Problem vor Augen sieht. Zu entscheiden gibt es dann nur noch, ob man es patentiert oder, wie seinerzeit geschehen, mit dem Kunden abstimmt, das besser nicht zu machen, weil es sonst die halbe Welt nachbaut und es bei den Chat-GP-active-superintelligent-agile Code generators landet :-)
J. S. schrieb: > In Zukunft gibt es gute FPGA-Architekten, die effizient mit generative > AI umgehen können und damit die Codierer = VHDL-Entwickler ersetzen. Und > ich hänge da noch hinein: Auch die C-Entwickler für die ZYNQs werden > weniger zu tun haben. > Da stimme ich Dir zu. Allerdings hatte ich das so ähnlich in dem nicht von Dir zitierten Text schon geschrieben. Ich sehe die Architektenrolle als die Planungsrolle, die Implementierungsaufgabe übernimmt ein Entwickler. Tendenziell werden die LLMs erst einmal die einfacheren Aufgaben übernehmen. Übrigens gibt es schon eine Menge Ansätze, auch die anderen Teile des Designprozesses mit abzuducken. z.B. gpt-engineer: https://github.com/AntonOsika/gpt-engineer Der erstellt neben dem Code auch gleich Architektur, Testcases und Dokumentation, wenn man entsprechend promptet. Gerade für HDL sind aber die oben besprochenen Schwächen vorhanden.
:
Bearbeitet durch User
https://spectrum.ieee.org/ai-for-engineering Nvidia Is Piloting a Generative AI for its Engineers ChipNeMo summarizes bug reports, gives advice, and writes design-tool scripts Dauert wohl noch etwas... > “Even if we made them five percent more productive, that’s a huge win,” Dally said in an interview ahead of the conference. Nvidia can’t claim it’s reached that goal yet. The system, called ChipNeMo, isn’t ready for the kind of large—and lengthy—trial that would really prove its worth. But a cadre of volunteers at Nvidia is using it, and there are some positive indications, Dally said."
Da haben wir es: Kaum Erfolg bisher und das, obwohl die Aufgabenstellungen bei einem so eng definierten Feld wie "Grafikprozessor" sehr überschaubar ist. Das ist in einem größeren System eine Subkomponente 2 Stufen unter dem Systemverhalten. Ehrlich gesagt hätte ich mehr erwartet, was der CoPilot da ausräumt. Aber möglicherweise sind die Entwickler dort auch super gut und bauen kaum Fehler rein. Sollte das so sein, würde ich aber direkt hinterfragen, warum ich bei meinen NVIDIA-Chips andauernd updates brauche und der JETSON, den zwei meiner Kunden verbaut haben, auch nach 5 Jahren immer noch nicht komplett entwanzt ist.
J. S. schrieb: > Da haben wir es: Kaum Erfolg bisher Eine der Aufgabenstellungen ist ein Chatbot, der Fragen auf Senior-Level beantworten kann, damit die Juniorentwickler die Seniors weniger von der Arbeit abhalten. Ich finde es jetzt weniger überraschend, dass sie das noch nicht hinbekommen haben. > und das, obwohl die > Aufgabenstellungen bei einem so eng definierten Feld wie > "Grafikprozessor" sehr überschaubar ist. Ich weiß ja nicht was Du so machst, aber ich finde ASICs mit 609mm² und 76Mrd Transistoren (RTX4090) jetzt weniger überschaubar. Auch wenn da natürlich viele repetitive Strukturen drin sind.
J. S. schrieb: > Da haben wir es: Kaum Erfolg bisher und das, obwohl die > Aufgabenstellungen bei einem so eng definierten Feld wie > "Grafikprozessor" sehr überschaubar ist. > Das ist in einem größeren System eine Subkomponente 2 Stufen unter dem > Systemverhalten. Naja, dass das Blödkram ist, weisst Du selber. > Sollte das so sein, würde ich aber direkt hinterfragen, warum ich bei > meinen NVIDIA-Chips andauernd updates brauche und der JETSON, den zwei > meiner Kunden verbaut haben, auch nach 5 Jahren immer noch nicht > komplett entwanzt ist. Die sind wahrscheinlich sowieso nicht mehr so einfach zu bekommen... https://gagadget.com/de/226955-die-russische-kamikaze-drohne-lancet-ist-mit-einem-nvidia-jetson-tx2-computer-und-einem-xilinx-zynq-chip-ausgestattet/
J. S. schrieb: > In Zukunft gibt es gute FPGA-Architekten, die effizient mit generative > AI umgehen können und damit die Codierer = VHDL-Entwickler ersetzen. Also ich kenne keine der beiden Berufsbezeichnungen. Bei uns macht ein "FPGAler" Beides. Je nach Aufgabe ist das aber sehr unterschiedlich welcher Teil die meiste Zeit kostet. Es gibt auch Komponenten die man recht einfach überblickt, also sehr wenig Architekturüberlegungen, die aber viel Zeit in der VHDL Beschreibung kosten weil die Komponente sehr generisch geschrieben wird. Je nach Generic sind das dann breite Pipelines oder schmale Pipelines oder kurze oder lange Pipelines mal mit mehr Timing Optimierung, mal mit weniger.
Angehängte Dateien:
Ich denke Copilot Chat wird Startups wie RapidGPT effektiv killen. (siehe Screenshot). Kein anderen Tool hat in den letzten Jahren meine Produktivität beim Programmieren so effektiv gesteigert. (Der code ist noch nicht korrekt, aber das ist im Dialog einfach erledigt) Spannend ist allerdings die Frage, wie sich LLMs für Aufgaben außerhalb des Schreibens von Code einsetzen lassen. z.B. Schaltung und Layout. Dafür habe ich noch nicht so viel gesehen. Kleiner Tipp: Wer auf Github ein größeres Open source projekt hat, sollte kostenlosen Zugang zu Copilot haben. Am besten mal im Profil nachschauen.
:
Bearbeitet durch User
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.