napowderly

I think the amount of reuse is a big difference. IC tools build on characterized cells with a lot of the rules already encoded. With PCBs, even when you're reusing a reference circuit, you're often manually carrying over the constraints and figuring out which layout decisions mattered. A lot of the engineering gets repeated rather than traveling with the design. That's something we're trying to improve with atopile.

Above links broken: https://github.com/atopile/packages/blob/main/packages/ti-in... https://github.com/atopile/packages/blob/main/packages/ti-in...

I basically dont write ato code when designing modules any more, claude code + rules file + a few decent examples and an MCP for basic functions like building, finding parts and inspecting library components is able to do a pretty great job. As an example, claude one-shotted this MPU6050 design: https://github.com/atopile/packages/blob/multi/adafruit_heis...

Currently working on a pipeline to generate a whole bunch of these automatically, stick them on some big test boards and make sure they actually work. We will be selling razor blades, and will have the test data to show they work.

I think there is actually some really neat stuff to be built here. I think layout engineers would love to be able to write down their 'style guide' that is basically a set of parameters modifying the footprint. We would have a 'common' representation, basically a definition of the package itself that would be transformed to whatever you might like for the pad/silk shapes. Something very similar to having a linter in code that would enforce company best practices.

We already provide the 'plug and play' version which looks quite alot like LCSC data and is certainly good enough for playing around with. Id really like to put some effort into standardizing this in the mid-term, seems pretty crazy to me that there are way more footprints designs out there than actual packages.

Our vision is not schematic capture, but intent capture. Once you can capture intent it can trickle down to schematics, layout, BOM selection etc. The language is pretty simple at the moment and building out from the 'minimum useful product' which is basically replacing the schematic.

The schematic is not most of the work, but it is the place that most of the work is relying on as a source of truth. Everything from firmware header files, end of line testing, reliability tests to service manuals. Today as an engineer you end up in the middle of that. Once you have a complete description, much of the boiler plate work can be automated.

We have done quite alot on the components and routing section of the work as well, we can generate most components for you automatically without leaving the IDE and have a growing list of fully auto-selected components. Instead of going to digkey to find a 10kohm 1% 0402, you can just give those specs to our tool and it will automatically pick the most suitable one for you, considering things like price and stock (plus eventually any other filtering you might care about, including custom libraries). For layout we currently just to layout reuse blocks, which is actually a crazy time saver for how simple it is. https://packages.atopile.io/ currently has ~10s of parts, but we are growing it over the next few weeks to ~thousands, so most parts you want to use will have a reference design + layout you can install and use in your project, just like you would NPM/pypi.

We think both are pretty important. For most people, the ato language should be sufficiently powerful, for module designers we have a python interface that allows for more complex designs.

For example the INA228 from TI has a funky addressing scheme that is not possible to describe in ato, so we create a hybrid module:

atopile for the main structure: https://github.com/atopile/packages/blob/multi/adafruit_heis...

compose in an 'addressor' python module: https://github.com/atopile/packages/blob/multi/adafruit_heis...

Fair enough! We definitely need a better landing page, we are just coming out of a long period of building, will all be getting some much needed polish soon!

Here is one of our more recent demo projects you can check out that shows how a larger project is structured: https://github.com/atopile/nonos/blob/main/elec/src/nonos.at...

And an example of modeling a component: https://github.com/atopile/packages/tree/main/packages/archi...

For sure, the way I see the component library is ability to capture progress. In the current paradigm how many times have schematics, symbols and footprints been drawn up for common ICs/circuits? I would expect 100s or in some cases many thousands of times. Our hope is by providing an open source and shareable format we can reduce this. If people really hate code and want to write a tool to convert to altium/kicad/cadence format, go for it! At the same time, I think the way we share component data is pretty dated, PDF datasheets do not adequately capture component information in a way that can be apples to apples compared in any automated fashion, best we have is something like a digikey search. In the future I would like to be able to have much more sophisticated requirements that automated search tools can use to help me find the best components for my use.

Not personally a fan of the readability of lisp, but that is just a personal preference. Our assumption is that python is going to be the most familiar language to our users and following a python like syntax will make picking it up easy. Our language is definately still quite immature and we are still figuring out exactly what it should look like.

There is definitely a little bit of a learning curve at the moment, we do have some getting started videos that walk you through the whole process. If there is anything missing or confusing, please point it out! We do want to make it as approachable as possible. It will only get better from here, I promise!

On the downloading, currently we have the package on pypi, which does make it pretty easy to install from a command line, but I can appreciate that will be new to alot of people. In the future we might do an executable download version.

We have a getting started video here: https://www.youtube.com/watch?v=7aeZLlA_VYA

We are very active on discord also if you get stuck or have any questions/feedback, hope to see you there! https://discord.gg/PBq4pS4K3p

In our tool, just give it a part number and it will find and download the footprint and create an ato file for the component.

We currently support components on JLC, but eventually plan to build out a pretty substantial library. We will also capture a good fraction of information that you would currently need to go to the datasheet for.

Indeed! We do support quite a few parameters for component selection today, but definitely want to add a lot more. I think this opens up some exciting possibilities, for example not needing to explicitly call out a part number for generic components in your source code, retaining information about what the requirements of that part are. Of course in production you would want a lock file to make sure things are not changing arbitrarily, but I personally would have loved something like that while I was dealing with chip shortages a few years back.

I am curious to hear that you dont see any value in bringing software workflow to hardware. I found in previous jobs we spent a huge fraction of our time dealing with things like release, version management and reviews. Thanks for your thoughts!

For sure, our goal is to solve the toughest problems in electrical engineering, we are starting with the low hanging fruit. Confident reuse of designs that can be verified and validated before a chip is placed sounds pretty exciting to me!

BOM generation and abstraction have definitely not made it to PCBA design yet, so that is where we are starting.

Stoked to get to the hard stuff.

For sure, we have been pretty focused on the low level part of the language, I think it will be interesting to see how our language evolves as we are able to abstract away more of the low level connectivity and configuration. I think eventually we will end up building something like a python library on top of ato to get the best of both worlds.

Indeed, we think the community aspect of this is super important. Being able to reuse high quality work confidently is very nice. Our export is pretty cool already! We build outputs in CI on a server, ready to drag and drop directly into JLC, including BOM and PNP files.

Being able to use git was our fundamental motivator, we all previously worked a big companies and found it maddening that we couldnt work in parallel on projects without breaking everything.

On parts specs, for sure, we currently capture all the data you would see on JLCs website. We do have dielectric and voltage ratings for caps. Eventually we plan to scrape a bunch of datasheets to build out a high quality dataset, I am very excited about this!

Thanks! We definitely want to get involved on the education side. Currently we are super focused on building out the tool and growing a community around it. We are looking for people to use our tool and give feedback on what works and what sucks. Would be excited to chat about what you would want to see from an education standpoint!

Agreed, we need to flip this.

We had a look at a few options before doing our own. A few thoughts; Building a DSL allows us to keep it really simple to start, we tried using SKIDL ( a very cool python project) and found it was pretty easy to get your self in a weird spot, the language would let users do things like create a component and not hold a reference to it.

Units and tolerances are core to our language, the physical world is 'fuzzy' and having a good way to deal with those we think is pretty important.

We are also trying to make it as readable and friendly as possible, our expectation is our users will likely have some experience with python and perhaps a little C back in school, so making it clear and approachable is front of mind.

Very open to critiques on our choices! We still very much in development.

Thanks! Hope to see you there again this year!

They do have this, its called EasyEDA. In my experience its not as good as kicad and definitely not as good as the 'professional' tools like cadence and altium. Our tool does basically do that though! We have a big library of kicad components that can be used in your designs as well as an import just about any JLC component just using its JLCPN. We love their service, would love to see that model proliferated to other companies also, so hard to beat having parts available and in stock.

For fun I did have a play with GPTs doing a little fine tuning on some ato code. Definitely not my domain, but pretty amazing how quickly it kinndaa worked. Our focus at the moment is building out the layer that designers (human or otherwise) can operate on. I do think that we need some pretty solid testing infrastructure for us to get to a place where we would ship 'black box' pcbs. Maybe one day.

For sure, there will always be some 'user' type requirements that we need to build a way to input, for starters it will be something like a lock file with component positions of things you need in a particular spot. I see alot of value in automating things you just dont care about, particularly if 'sensible' rules can be applied. For example if the tool could automatically determine trace widths, not just at a net level, but for each link based on how hot you were happy for it to get and what loads it would see.

Excited to hear it! Our language already captures tolerances and the solver we are building does proper tolerances stackups. You specify the desired output with a tolerance, eg my_regulator.power_out.voltage = 4.75V to 5.25V and we will solve the stack up to get you there.

Hang tight, its coming soon!

love it

We have indeed started with the schematic/requirements half of the problem. My experience in industry is there can be much more direct reuse/configuration in schematic as many boards might have similar features. Layout is typically quite bespoke as it will have mechanical constraints.

That said, we are absolutely looking to take on the layout section in the near future. We are starting with some augmentations of kicad, for example we just released a layout reuse feature, where component layouts can be captured and shared along with the ato code.

I think with few exceptions defining explicit layout choices in our language will be painful and not the right path (perhaps connector positions would be an exception). We have not put a huge amount of energy into this yet, but from some initial playing around, we believe capturing all the information that a person would use to judge a quality layout will be crucial. For example, current tools do not have concepts of current/voltage and definitely not transient behavior.

To get to actually good auto-layout that doesnt suck is going to be a slog for sure.

Thanks!

Thanks!

yeah I have only really used it for simple python things, its pretty good at that.

Today, poorly. We just do a dumb matching of signal names. I imagine we will do something like add a property to the interfaces on each device.

For sure, we found that to start with something useful from day 0 we needed to be able to completely represent any possible circuit. Starting by just providing a cleaner way to write out a netlist is just the beginning.

We are working to add an equations solver to our compiler over the next few weeks, which will allow you to do things like set the ratio of a divider and total resistance, then have the solver pick optimal values based on availability, cost etc.

I think that gets really exciting when you start to be able to link these together, its trivial from there to directly set the output voltage of a power supply in volts, which will internally configure the feedback resistor divider.

Also verified designs will be super important. Its a little crazy that the status quo is you will almost inevitably make a silly mistake on your first spin. I am imagining designers will go off, make a new circuit, build and test it then make a PR to merge it into main.

I have found taking a 'functional programming' like approach, where you build up your circuit from small blocks with specific functions that are easy to hold in your mind and then building up by combining those. For example instead of sticking a bunch of resistors and caps in your top level file, you can abstract them into their functions like a filter, resistor divider etc. Very curious to get your thoughts on using the tool!

I am definitely curious for feedback from people after using it for a while. I felt the same in the beginning, but after writing a fair bit of it, I rarely find myself wanting it. I could imagine for more casual or new users it could be helpful at least for the transition.