[helpfulmountain]

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.

[rcxdude]

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.

[mawildoer]

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

[Timot05]

Thanks for the support!

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.

[crote]

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