Forum: FPGA, VHDL & Co. Generative AI und HDL code


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


Lesenswert?

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.

von Klaus K. (Gast)


Lesenswert?

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.

von Papa Schlumpf (Gast)


Lesenswert?

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!

von Gustl B. (gustl_b)


Lesenswert?

Schlumpf schrieb:
> es nur Informationen reproduzieren kann, und ...

Und schon falsch.

von Papa Schlumpf (Gast)


Lesenswert?

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

von Gustl B. (gustl_b)


Lesenswert?

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
von Papa Schlumpf (Gast)


Lesenswert?

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.

von Papa Schlumpf (Gast)


Lesenswert?

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.

von Gustl B. (gustl_b)


Lesenswert?

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.

von Markus K. (markus-)


Lesenswert?

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.

von Markus K. (markus-)


Lesenswert?

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.

von Markus K. (markus-)


Lesenswert?

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?

von Bernd G. (Gast)


Lesenswert?

Fortschrittswahn? Man wird ja noch fragen dürfen.

von Tim  . (cpldcpu)


Lesenswert?

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
von Tim  . (cpldcpu)


Lesenswert?

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
von Slippin J. (gustavo_f)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Dergute W. (derguteweka)


Lesenswert?

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

von Tim  . (cpldcpu)


Lesenswert?

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
von Markus K. (markus-)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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 :-)

von Tim  . (cpldcpu)


Lesenswert?

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
von Tim  . (cpldcpu)


Lesenswert?

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

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Markus K. (markus-)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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/

von Gustl B. (gustl_b)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

Hier ist das Paper zum NVidia AI-Assistenten:
https://arxiv.org/abs/2311.00176

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

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