Tschätschipiti-VHDL

OP Persönliche Seite #8086185
Lesenswert?

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.

#8086189
Lesenswert?

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.

(Firma: Starfleet) #8086211
Lesenswert?

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.

#8086231
Lesenswert?

Bradward B. schrieb:

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren