For sure the goal! Our current component tool will find components that are available on JLC, in stock and to your spec, no more looking for resistor part numbers. The layout side is going to be exciting, we are just scratching the surface there.
We have some basic component parameters that we can define, like value, dielectric and voltage rating for capacitors. I think these become much more powerful once we add in equations to help relate these values and link them together. For example if I configure my powersupply for a 12V input, the tool should know that the capacitors need 12V * some safety factor of rating.
I think I see the entry point for auto routing to be taking advantage of the fact that layers have become pretty cheap (atleast for prototyping) and engineering time is the expensive bit. If the tool can help me layout a board in half the time, particularly for test hardware or the likes, that would be huge. Eventually I think we will get to a place where computers will do a better job of layout than most people, but thats a ways off.
I bet you do ;) We are fully opensource today, but we will eventually have some features we sell to enterprise. We have a small community of mostly friends at the moment, we are hoping to grow that very soon now that we have something we believe is worth sharing!
For sure, its a big benefit of using language, it is comparatively very fast and easy to define custom relationships of component values, trace widths etc that would quickly become untenable in a point and click tool. We think the path forward is to be able to encode the governing equations that you would get in say a buck controllers data sheet directly into our source code. That way from a user perspective you can define your circuit simply by importing modules, defining them (for example input voltage, output voltage and current) we can then solve the component values and pick them from our component database for you. One of our early users wrote a plugin to do LED arrays in an afternoon. Our compiler is all open so its pretty easy to add on custom scripts for whatever you might be wanting to do.
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.
We are taking the open-source route (eventually moving to open-core). We think a big part of moving the industry in this direction is building a community around it, much like the way Github started out.
Indeed, the ability to branch and merge is a pretty exciting concept for me as a hardware designer. Another simple one is building artifacts in CI and doing quality checks, I have make some silly manual errors that have been very expensive during export.
> Another simple one is building artifacts in CI and doing quality checks, I have make some silly manual errors that have been very expensive during export.
I set up a CI pipeline for the hardware company I worked for. It automatically generated things like gerbers and board renders for each commit, and made them available as PNGs. I added a little tool which made it really easy to view the results side-by-side, and see both the front and the back. It definitely saved us from some really expensive mistakes a few times!
This is very cool and the concept is something I've been wishing on for a while. Unfortunately I work in an enterprise type of design team. I'm a software developer but our hardware team has standardized on Cadence tools and are pretty dug in on how they work, which is kind of opaque to us software guys.
I was a designer at a big company in my last job. Many of my colleagues shared the sentiment that the tools were trash, I think people just need an exciting future to rally around. I think being able to link across disciplines is super exciting also, firmware and hardware can be versioned along side eachother, no more checking schematics for pinouts and meetings about which pin which signal should be on, just put up a PR, have both hardware and FW teams review.
The core compiler is open source so hopefully the stakes are low to start using it on non-production equipment like test fixtures, bed of nails, quick prototypes... Based on experience using the compiler on those project, it could be transitioned to higher stakes designs.
Indeed, Altium has similar features also. I think what has been missing is an effective way to collaborate on hardware projects as a community and be able to share them like you would packages on pypi or npm.
