Yes yes yes! I love it when people make the things I think would be a good idea, and then stay on the hobby project idea list for years to come. (I'm struggling to make that not sound sarcastic - maybe it's just my British reading! - but I really am sincere.)
When I was thinking about it, a couple of further directions I had in mind were 1) ecosystem/library/sharing of modules, so something like the voltage divider example is not something you'd need to do (even once) for every project; if it really took off the pipedream would be that application notes examples were just provided as modules, so you could take whatever IC wnd just import the module if you were using it in a standard way; 2) if you did a similar thing for layout constraints, you could then have that as part of the same module, and when you compile the whole thing (in hand-wavey generalised theory if sufficiently constrained) you could generate the overall layout for a project with say a SMPS and also sensitive analogue circuitry in a way that makes sense without either of those modules having to know that the other is in use, just because they have rules like distance from transistor, bypass cap to IC could be fully constrained, so you always get exactly the same sensible-looking layout, etc.
Anyway, looks great, I look forward to trying it properly some time!
100% agreed about the ecosystem too. We've already created a perhaps-too-scrappy package manager, but it works! https://packages.atopile.io/
We're pretty convinced that the awesomeness of the software ecosystem is a function of its openness and open-source and atopile largely came from working out how we could seed a similar shift in the hardware world. I can't wait for the day I can `ato install` SMPS, filters, radios and servo-drives with the confidence they'll just work!
Specifically on the layout section, I have been thinking along the lines of start with sensible 'seed' layouts that users will contribute, then mutate the layouts with a physics driven solver. Imagine links between components as a spring and repulsion forces to model creepage/clearance distances, you could imagine the layout warping into a suitable shape for your board. I am pretty excited to get to this bit.
As someone who just taught themself Kicad to make a simple MIDI controller PCB usi an STM32F4, I was totally blown away, coming from software, how "manual" everything was, how abstruse and arcane.
It's quite difficult as a beginner to know that a design is "correct", or perhaps "correct enough", with respect to component placement and EMI.
It seems like even top EE who specialize in board design utilize rules of thumb rather than rely on simulation.
I was also blown away that the state of the art autorouter for traces seems to be from the early 2000's -- no recent AI magic going on here.
Where is my "autoplacer"? It seems like an AI trained on millions of schematic/pcb combos, even just gerber files via image ingestion, ought to be able to generate a pretty decent layout + routing given constraints.
Or perhaps I'm spoiled coming from software and web because it's so much further removed from physics. But it's still the case that there are a ton of modular components with "API's" that should have a templating language, so very much bravo to this project.
Yes, it is like 90% rules of thumb and experience. The reason being simulation is expensive: not just in the software itself, but in the time it takes to learn how to use it, set it up for a particular design, and then run through it and understand if it's actually reflecting reality or not. I've been working on some projects where we really care deeply about noise performance, and even the super-expensive packages which exist (which we can't really afford) don't seem to actually be able to answer the questions we have about the design. Autorouting is similar, autoplacing is basically a disaster here.
I am confident a lot of this is an accessibility and UI issue: if you want to disrupt this you could focus on making simulation and auto-placement tools that are cheap and actually usable, and help inform the rules-of-thumb. But that's a very big investment and mostly orthogonal to making a different way to specify your netlist.
We share similar thoughts about the core of the auto-routing/placement/simulation issues being UX! We're a bit more bullish on code being able to fix that as well.
Noticing that these tools are infrequently even configured because it's simply too much of a pain to do so for every new design - we're hoping the expressive, reuse-focussed code-based-approach means people need to capture these things once and then everyone gets to reuse them.
This is all a while away, but after we're able to get design currently captured in schematics working smoothly we certainly plan to tackle auto-routing/layout as well
For the autolayout part, one thing we realized is that it’s very hard for a computer to do a good job at it when there is a lot of implicit requirements that are not baked into the schematics. We are hoping that by capturing those through code, auto layout can be improved.
On the design check, we aren’t doing a lot there for the moment but the comment above also applies: if you have clear requirements in the code, it becomes easier to test if the solution fits those requirement.
> It seems like even top EE who specialize in board design utilize rules of thumb rather than rely on simulation.
Yup, almost 100% this. Most parts of most boards are pretty trivial, and the design decisions you make don't really matter all that much. Unless you're working at a company the size of Apple, it really doesn't make sense to spend several hours of engineering time to figure out if that $0.001 decoupling capacitor is really needed.
And in the end it's often a lot easier to just build the thing and test if it works. We see the same in programming: it's technically possible to mathematically prove that some programs are correct, but in practice you can get 99% of the way there for all programs in a fraction of the time by just writing a bunch of unit tests.
Simulation is definitely done, but it's limited to the really hard stuff like antenna design or high-speed signalling.
When I was thinking about it, a couple of further directions I had in mind were 1) ecosystem/library/sharing of modules, so something like the voltage divider example is not something you'd need to do (even once) for every project; if it really took off the pipedream would be that application notes examples were just provided as modules, so you could take whatever IC wnd just import the module if you were using it in a standard way; 2) if you did a similar thing for layout constraints, you could then have that as part of the same module, and when you compile the whole thing (in hand-wavey generalised theory if sufficiently constrained) you could generate the overall layout for a project with say a SMPS and also sensitive analogue circuitry in a way that makes sense without either of those modules having to know that the other is in use, just because they have rules like distance from transistor, bypass cap to IC could be fully constrained, so you always get exactly the same sensible-looking layout, etc.
Anyway, looks great, I look forward to trying it properly some time!