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

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.

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.

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

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?