Code-Based PCB Design with AI: Inside atopile

And so, um, you guys are building a company called AdaPile.

Um, if you could, you know, tell us what was your thought process behind building AdaPile and your approach to getting AI to perform design tasks.

Yeah, for sure.

Um, so I, I guess what, you know, just wi-winding back a step, um, you know, we're, we're thinking about this problem well before AI was around.

You know, we're thinking of it, uh, more from like an automation perspective.

How, how do we bring automation connecting together, uh, you know, across the design process, all of these steps that today in hardware there's just a person in the middle of them.

Um, you know, you think in, in software we have CI, we have GitHub, you know, all of these tools to, to manage complexity of your designs.

Um, and we found that really missing in hardware.

So our first step was, well, how can we capture all of these things we're trying to do in a way that just immediately fits into this same ecosystem of tools that exist? So naturally, we landed at, well, it, it needs to be described in language, needs to be a, a programming language, uh, to, to leverage all of that, that power.

Uh, I think, you know, in, in hindsight, uh, it just wasn't gonna work because it was way too big of a change for people.

Uh, and our company got very lucky that AI tools became prolific and very powerful when they did, as, you know, what, what we see has really happened here is the barrier to try new things has dropped through the floor.

Before, where you might not be using, you know, Python for some little automation, you might just use, uh, you know, a little napkin math or, uh, some calculator online.

Now it's really easy to use AI tools to allow you to build something quite complicated that before just wouldn't have been worth the learning overhead.

Um, and we see the same thing happening in our, in our tool.

So what would've looked very scary two years a-ago, now you can just interact with in natural language in a very intuitive way, um, I would argue in some ways even more intuitive than the tools that exist today.

Yeah.

What us- what brought us originally to, into this world of trying to capture information in code is that there's just a lot of intent lost in the, in the tools nowadays.

There's great tools out there for electronics design, everything from manufacturing to DFM, to schematic capture, to layout design, but all those tool- of those tools live in their small little islands and are very good at that specific niche.

But at every stage, I have a new engineer or a new process or something which is very lossy to translate in between.

From my requirements capture into my, uh, schematic capture, there's a- always a human in between that has to be in the loop- It has to be stuck in meetings, it has to be re-explaining stuff.

While in software, a lot of the, a lot of the information and a lot of the design is captured in one single source.

That's just the code, and that's that one you can use across the whole horizontal layer.

And this is kind of where we, we saw like both Narayan in his, in his background at Tesla trying to scale big amount of publication boards, but also from my background where we just tried to move as fast as possible, where manufacturers were determining our products primarily, and our mode was how fast we can adopt.

We, we saw that we wanna reuse a lot of our design, and we wanna be able to automate and have like central authority over how things should be built and rules in the same domain as the designs themselves.

So that's where we were trying to discover what is the best way to describe engineering intent in a way that we can automate it across layers, but also make engineers' lives more, uh, less bo-boiler plate heavy and more actually engineering.