Hacker News Reader

Comment by mikeayles | Hacker News Reader

Been working on this exact problem for a while now. The core issue isn't that LLMs are bad at circuits, it's that we're asking them to do novel design when they should be doing selection and integration.

My project (https://phaestus.app/blog) takes a different approach: pre-validated circuit blocks on a fixed 12.7mm grid with standardized bus structures. The LLM picks which blocks you need and where they go, but the actual circuit design was done by humans and tested. No hallucinated resistor values, no creative interpretations of datasheets.

It's the same insight that made software dependencies work. You don't ask ChatGPT to write you a JSON parser from scratch, you ask it which library to use. Hardware should work the same way.

Still WIP and the block library needs expanding, but the constraint-based approach means outputs are manufacturable by construction rather than "probably fine, let's see what catches fire."

View on HN

> The core issue isn't that LLMs are bad at circuits, it's that we're asking them to do novel design when they should be doing selection and integration.

I don't want to detract from what you're building, but I'm puzzled by this sentence. It very much sounds like the problem is that they're bad at circuits and that you're working around this problem by making them choose from a catalog.

Try that for code. "The problem isn't that LLMs are bad at coding, it's that we're asking them to write new programs when they should be doing selection and integration".

I only had undergrad EE training so maybe I’m out of touch with what’s done in industry. But, I think most human engineers mostly don’t design novel circuits either. Chips come with specification sheets that have some reference implementations. So obviously somebody at the company designs that reference implementation, but I think most users stick pretty close to it…

Copy/paste (from reference boards or examples in the datasheet) is pretty common when starting a new design but if you don't then figure out what each connection and external component are there for and adjust to your application (or sometimes figure out the part won't work for you) then you quite literally don't know what you are doing.

That’s exactly how it has been working for me in code. I have a bunch of different components and patterns that the LLMs mix and match. Has been working wonderfully over the past few months.

At what level of abstraction does programming become a process of selection and integration?

Why get philosophical and not just deal with the reality that 95% of the industry are dealing with languages that just compile down to C? We are already at some of the highest levels of abstraction thus far in the history of the trade.

Are there examples of LLMs generating novel code? If so, who is it novel to?

Not trying to be a smart ass here, I’ve been keeping an eye out for years.

Maybe you can provide some examples of what you would consider to be “novel” code?

The proof of the Erdos problem the other day was called novel by Terrence Tao. That seems novel to me.

Everything is derivative of something else. “Novel” is a distinction for works which are minimally derived, but everything created is a remix of something else. Novelty is an illusion.

Are most circuits novel? I'd assume that there is enough out there to fit 80% of PCB design needs and sure it can still be bad at the remaining 20%.

That's precisely how LLMs work for code, yes. Were you not aware?

Sorry, could have been more clear, LLM's are great at architecting high level design decisions, but terrible at the nitty gritty - without better tooling (with the right tooling, such as https://flux.ai, they are capable!).

I even had Gemini hallucinate a QFN version of the TPS2596 last night, it was so confident that the *RGER variant existed. In an automated pipeline, this would break things, but giving it a list of parts to use, it becomes a lot more useful!

That is exactly what LLMs are good at for code

I think Altium tried to do something similar. A bunch of common blocks being able to just plop on the PCB, (auto) route few tracks and done. Failed because there was always something some client wanted to do, move, change or optimize for production run.

Module based design is cool for getting the prototype going but once you get into production you want to optimize everything so it falls apart quickly when you need to move the parts (not blocks, parts) to fit the least possible amount of space, cut components that could be shared (do 8 blocks on one board each with its own decoupling caps need entire set of them? Probably not). Fine for prototyping/hobby stuff/one off but falls apart quickly in production.

Still, having working prototype quickly that can then be optimized in more traditional way can still be very valuable.

> It's the same insight that made software dependencies work. You don't ask ChatGPT to write you a JSON parser from scratch, you ask it which library to use. Hardware should work the same way.

hardware optimising gets you far more money faster than software, because the cost of software not being optimal is mostly cost on the consumer (burning more CPU than it would if it was optimized), while for hardware each chip less is more money left in your pocket and there are actual size constraints that can be pretty hard edged vs software's "well the user will have to download extra MB more"

I think it's also that hardware costs are so easy to quantify compared to engineering labor and software dependency maintenance etc

This sounds interesting for quick prototypes, but tbh it doesn't map onto how most iterative layout processes actually work. At least in my experience. $0.02

However, I wanted to say that for a lot of common parts I find the Adafruit open source schematics to be at least as useful as the application layout suggestions in many datasheets. When it comes to regulators etc it's nice to see how they did it, because like your project, you really can approach it like a block.

If I understand what you are doing this sounds like a great idea.

For example a part like the ADS7953 ADC comes with layout recommendations, including the design of the ground plane underneath the chip and the placement of the decoupling caps. A more extreme example would be an esp32 and all of it's supporting parts, including the keepout area on the PCB for wifi transmission.

I really want to assemble circuits out of higher level primitives like that, drag and drop a chip and all of its supporting parts, including their layout and power connections.

So this isn't exactly putting pre-wired up blocks together, my intent behind phaestus is to essentially to get you from an idea to a prototype tangible product as fast as possible.

I'm targeting sub 5mins from first prompt to manufacturing exports, stl files for enclosure, gerbers for pcb manuf, bin file for firmware, bom for pcba.

E.g. if you wanted something that doesn't exist, but don't have the time, the skills or it's just not worth it. One silly example I had was a colour e-ink selfie fridge magnet. As far as I know, that doesn't exist, I could make it, but I can't be arsed. (so I could suprise my partner with a selfie, a picture of our dog, or anything, just a little treat for her for putting up with me).

With this, it'll pull in a ESP32-S3 Sense Xiao board, an e-ink module, a battery connector and a usb c charge connector. glue it all together, and there we go.

Should work if you wanted a rudimentary zigbee mesh communicator, pulls in a C6, a touchscreen, battery, probably a physical button or two. Once that block library starts filling up, it'll become more and more capable.

However, what I suspect you're after is more aligned with https://www.circuitsnips.com

I built circuitsnips to be the 'thingiverse' for electronics schematics.

Unfortunately it's been a bit neglected since so much of my free time has gone into phaestus, I did have great intentions to kicad up some official reference designs, so I can get rid of the github scraped bootstrap data as that was the sticky point both ethically and for the quality of the schematics, but there are only so many hours in a day.

Thanks for the link, that is very impressive.

This is conceptually interesting to me because I see this as almost a more generic TI Webench. I’m curious why your focus in the sized “grid” blocks (presumably for placement directly on the PCB layout) instead of doing the same but for the schematic. That way I still have the flexibility of laying out the board how I want to meet eg mechanical constraints instead of working around a 12.7mm grid.

I saw routing as equally as big of a headache as the schematic, so formalizing the layout to a grid means layout becomes a compilation problem, not a design problem.

My intent for phaestus isn't to design pcb's, it's to design entire products, and also to be friendly to non technical users who don't know what a PCB is, let alone do layout themselves.

This sounds very interesting, especially if you combine it for instance with an FPGA for logic blocks.

Thanks, as a concept it has potential, I've leveraged some of my previous projects www.circuitsnips.com for inspiration for the subcircuit blocks, TOKN for more accurate parsing of schematics, and to a lesser extent even my datasheet MCP server and kicad-netlist tool, more info at https://www.mikeayles.com/

For the time being, I'm erring away from feature creep, even though I really, really want to though! For the sorts of products I would like this to make for the time being, simple I2C, SPI and GPIO driven peripherals are the limit. I only have 2 more weeks, and then I want to have a working, battery powered device on my desk. PCB, Enclosure, Firmware, everything.

Similarly, I haven't got a framework for anything mechatronic in the MCAD pipeline, so no moving parts (besides clickable buttons). Fixed devices are fine, like screens and connectors though.

Is there a way to stay up to date with what you are doing?

It very much aligns with how I've approached hardware since I was 15 and had a massive stack of functional blocks of electronics circuitry that I would combine in all kinds of ways. I've lost the 3x5's, but I still work that way, build a simple block, test it, build another block, test that, hook the one to the other etc.

Feel free to star/watch the repo for the project at: https://github.com/MichaelAyles/heph

I may be able to set up an RSS feed for the blog if that interests you? edit: https://phaestus.app/feed.xml

There's a limited sign up currently on the site, which currently goes to an approval page. I don't think I'm quite ready for it to be fully open yet, as i'm paying all the inference, but I should be starting to populate the gallery soon with generated projects.

NP, I don't do GitHub (because MS), but I'll bookmark your pages and check back periodically. Please do post to HN whenever you reach an interesting milestone and feel free to reach out.

RSS feed would be helpful.

Done, https://phaestus.app/feed.xml. If there's any issues i'd appreciate the feedback, I haven't used an RSS feed in a while!

Seems to work, thanks!

I’m curious why you don’t target an HDL, which seems like it should match very well to llm capabilities, and rely on existing layout solvers for describing the last physical layout step?

This seems to be a discussion about board level circuits. HDLs are for chip design.

So far the language models aren’t great at HDL but I assume it’s just a training priority thing and not some characteristic of HDLs.

Reply on news.ycombinator.com