CPPL: A Circuit Prompt Programming Language | Hacker News Reader

CPPL: A Circuit Prompt Programming Language

arxiv.org

46 pointschrsw7 comments

The very first sentence: "Large language models (LLMs) have shown promise in register-transfer level (RTL) design automation" I want to see some serious proof for this shitty claim. While LLMs excel at slop webapp codegen because the code is usually highly modular, composable and easy to reason about), LLMs understanding of RTL is just pure dogshit. A simple signaling protocol, even well documented with some temporal behaviour and even some ready made assertions that are picked up by formal verification tools for static proving - none of this helps any top tier LLM to grok whats happening. state explosion, temporal dependencies, no composition - RTL is not code, its construction for complex machinery and LLM suck balls at it. and all of this will not go away if you slop into existence some low quality DSL for netlists

I've used AI successfully for some things but for SystemVerilog it's pretty rubbish. Too little training data I assume, and everything is behind firewalls.

However it's not completely useless - I've used it successfully for boilerplate for small demos and bug reproducers... And it has clarified some things for me (obviously I double checked what it said with the LRM). So I guess it's fair to say that they have "shown promise", in the same way that my 6 year old shows promise.

AI is advancing so quickly though, I bet it will be pretty good in a few years.

> RTL is not code

Of course it is. It executes on an unusual machine, but it's clearly code. I'll never understand this "hardware design is totally unlike software design" attitude that hardware designers have. Is it just so they feel special? They're really quite similar.

> RTL is not code

>>Of course it is.

most programming languages have that one serious key property that Ive mentioned above - ABSTRACTION. you can well reason about a function that calls another function addTheseTwoStranegObjectsTogether(arg, arg2) and make totally valid assumptions on how and what would happen. "executing" that code is a depth first call graph walk, pretty linear one too. You cannot do these things by reading RTL code, the state space is enormous, there is no "unusual machine" that executes it (if you mean simulators, thats a different thing). also you cannot reason even about simplest instances since they are stateful and that is in no way is exposed via interface connections

>AI is advancing so quickly though, I bet it will be pretty good in a few years.

Time will tell :) Cheers

I dunno what you're talking about. The whole point of the module hierarchy is abstraction.

> also you cannot reason even about simplest instances since they are stateful

Uhm... Classes? Globals?

I had Claude build a spiking neural net example for classifying MNIST digits in FPGA last week. It wrote the verilog and seemed to deal fine with timing issues. The FPGA receives a binarized/downsampled (to 14x14) image via SPI and runs the classification. ~8K LUTs in an ECP-5 85K. 95% accuracy. Claude even built me an app that runs on the PC side that lets you draw a digit and then send it to the FPGA via SPI.

I've also had it make mods to an existing RISC-V processor to add custom accelerators. Did fine there as well.

> MNIST digits in FPGA

Your example suffers from one of the same problems in the paper. They exclusively used text book level problems in their eval of the models HDL coding ability. These are effectively poisoned in the training data with many many copies of solutions done in different ways.

This is a good paper for undergraduates to dissect and find ways to make better.

"adversarially summarize this paper using an inverted-pyramid style" is a good starting point. I won't go into details beyond this, but the authors should be more critical of their own work.

Reply on news.ycombinator.com