Could you imagine the pain of building an entire software product using only assembly code? That’s about how we felt designing hardware. We don’t currently have good ways to describe what we need, reuse existing designs and compile that description down to a product.
We started atopile to fix this. atopile is an open-source language and toolchain to describe circuits with code. The compiler is here: https://github.com/atopile/atopile Docs are here: https://atopile.io/getting-started/ . For a detailed deep dive designing an ESP32 module, see this video: https://youtu.be/eMWRwZOajdQ
We realized this was a problem in our previous jobs. Narayan and I (Tim) had to manually, draw and export all our electronic circuit boards. This lasted until our friend Matt, a software engineer, showed us his development workflow. All his projects were built, tested, and merged automatically via GitHub. So we asked: Can we build the same for hardware?
We observed that the ability to abstract electronics effectively hinged on using a language to describe the requirements, so we came up with the “ato” language. In ato, you can break down circuits into modules, components and interfaces. You can nest and connect those blocks with each other. Here is an example with an RP2040 microcontroller:
import RP2040Kit from "rp2040/RP2040Kit.ato"
import LEDIndicatorBlue from "generics/leds.ato"
import LDOReg3V3 from "regulators/regulators.ato"
import USBCConn from "usb-connectors/usb-connectors.ato"
module Blinky:
micro_controller = new RP2040Kit
led_indicator = new LEDIndicatorBlue
voltage_regulator = new LDOReg3V3
usb_c_connector = new USBCConn
usb_c_connector.power ~ voltage_regulator.power_in
voltage_regulator.power_out ~ micro_controller.power
micro_controller.gpio13 ~ led_indicator.input
micro_controller.power.gnd ~ led_indicator.gnd
led_indicator.resistor.value = 100ohm +/- 10%
At the moment, atopile is intended to design all types of printed circuit boards (PCB) with low to medium complexity. The circuit complexity that the compiler can handle will steadily increase until it becomes suited for production usage. We often get asked if the compiler is meant for chip design rather than PCBs, but that is not the case. The language is exclusive to PCBs. At least for now..!
A big part of why the software community is so prolific is thanks to open source and open core technology. The ability to share software packages with each other and efficiently chain tools together has made the software world an awesome place for developers. As hardware engineers, we would love our field to benefit from this as well. That’s why we’ve made atopile’s core open source (Apache 2.0). We plan to generate revenue by selling entreprise targeted features, similar to GitLab.
We would love to have your thoughts on the compiler! What’s your story in electronics? What would you want us to build?
But take the example from [0] of a voltage divider. I agree that that is a textual description of a voltage divider that can be compiled to a netlist, a BOM, etc. But what is the actual division properties? What's the combined tolerance stackup? What I /want/ to be able to do is define a module generator function that takes a ratio, a desired output tolerance, and a maximum output current and generates the divider module with resistors chosen (both resistance and tolerance) that will meet those properties. And while I'm wishing, given that (for low output currents) this is an underdefined problem, I'd also like a way to lean towards components already in the BOM, either by just manually using preferred values (yuck), or by outputting multiple possibilities and having a selector downstream that does BOM line count optimization.
Besides taking much, much more of the drudge work out of this, it also makes these circuit-as-code text files reviewable, in much the same way code is. Consider an input pin for an ADC on a microcontroller. On the signal path, I might have at a minimum a voltage divider to get things in range, a low pass filter to get rid of aliasing, and a buffer to satisfy the input pin impedance requirements. If this is three different modules, each with two or five components... reviewing this is equivalent to designing it, I need to check each bit. If, instead, this is generate_divider(1/3, 0.1%); generate_lowpass(200 Hz); module my_standard_opamp_bufer -- then I only need to review those implementations once, and can trust the use of them (for, potentially, dozens of ADC pins).
[0] https://atopile.io/getting-started/
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.
atopile (1) — convert ASCII to pile of electronic components
The state of electronics tooling has long been extremely bad - 99% of people who put a regulator into their schematic will want an appropriate input and output capacitor as the datasheet demands. 99% of people who put a microcontroller will want a crystal and a programming port and a reset pin pull-up. It's only because of closed source tools stuck in the stone age that the state of the art is to copy out of a PDF.
And multiple people working on the same design and merging their changes? Forget about it!
It'll be very exciting if we can move towards a more modular world, where designs can be composed.
Not really. KiCad is open-source and a very capable EDA suite, for example.
The problem is that it's a really hard problem for which no one-size-fits-all solution exists. There's basically an infinite number of properties which are important when designing electronics, many of which will have to be nudged depending on your design. Capturing all that in a data format is virtually impossible, and any attempt to do so is likely to degrade into something unusual quite quickly once you get past the trivial stuff.
In my experience reading it out of a PDF is usually not that big of a deal, once you get used to it. For things like schematics symbols and footprints there are data interchange formats available - and there's a pretty decent chance these days they'll be openly available for the part you are using. But they always contain mistakes, and I find it way faster to just roll my own from the PDF than to copy it ready-made from a 3rd party and fix the errors.
Not really, IME.
Let's say I want a SMPS. Something basic, say 12-24v in 3.3v out at 1A. I can buy a module and solder it onto my PCB, or copy a reference design out of a PDF, or vendors like TI have tools like webbench to help me generate a custom design.
The vendor wants to hand me a proven design and have me buy their chips. I want to be handed a proven design and know my project's going to work right first time. But no, the likes of Altium have got to have their vendor lock-in by making copy-and-paste absolutely as difficult as possible.
There's no great skill or inventiveness in me drawing out the world's billionth SMPS design. I'm not "solving a hard problem" - it's drudgery.
> and there's a pretty decent chance these days they'll be openly available for the part you are using. But they always contain mistakes,
So you'd agree, then, that when a human copies from a PDF manually there's a substantial chance of them introducing errors?
Are you and I not equally vulnerable to making such mistakes? Frankly I find it absurdly wasteful that the industry has transistors in the same package but with different pinouts and the 'solution' to keeping this stuff in order is... senior engineers checking junior engineers' work against PDFs manually.
I dunno. I've used others, and KiCad was no harder to start with than the others (Horizon, LibrePCB, Lepton/gEDA, some others I forgot).
I asked for recommendations a week ago on HN for EDA products, and tried them all.
You know which one I eventually settled on? The one with the most components (symbols + footprints).
Turns out, features are nice (rules checker, etc) but not having to f*&^ing create my own symbols for a mass-produced part, then design the footprint for the same part is a huge timesaver.[1]
For many of us non-professionals designing a board, the UI just isn't as big of an issue as having to create our own components.
[1] At any reasonable hourly rate, having to create a library of just 1 component costs more than whatever you think you'll save with a slicker UI.
In terms of decoupling designs etc., the reason nobody has come up with a better solution is firstly that it doesn't actually take up enough time in the scheme of things to bother, and secondly that you often have to deviate. For variable regulators for example, the output capacitor (and inductor if it's not included in the device) are chosen based on output voltage, the switching frequency you choose, and sometimes other variables. You often want to deviate from the recommended circuit in the application notes for various reasons.
I'd think of a circuit board production as more like putting together a magazine than working on a software codebase, where you'd have a bunch of people working on overlapping parts of the code.
I mean even for a lot of boards we do (even quite complex ones) we'll just have one design engineer and one layout engineer, but for things where multiple people work on the schematic we just have people work on their own sheets and then somebody brings them together into the final design - kind of like where you might have an overall designer/editor that pulls a magazine together but individual people having put together individual articles. But it's pretty common that it would still be mostly laid out by a single engineer unless you're doing something extremely complex...
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!
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.
However I do want to mention that I think it might be necessary to be able to "cross-compile" to visual schematic format, and back. Or perhaps there is an open schematic tool that can be extended?
The issue is that I think electrical schematics are significantly more familiar to EE types, contain more legible information. Instead of reinventing the wheel there, it'd be nice to see a system that can switch back and forth between text and visual schematic.
How are schematics described as files currently? Is there an open standard? Can it be converted to atopile format, and back?
edit: just wanted to double down on this being very cool though. i dont mean to deflate this project and I'm about to design a pcb for a personal project - I might give this a go for fun. the promise is there and asthe project and feature set grows i can see it being the way forward.
What we discovered is that:
- making a visual viewer is a non trivial endeavor. It takes a lot of time but the value add is marginal for an average viewer. - people tend to spend a lot of time making the viewer look good instead of improving the circuit
We think that in the long run, a viewer could be awesome to inspect what is going on or get a general understanding of the circuit. But it’ll be difficult to justify the time spent on it early on in the project.
We also think that there might be better and more interesting ways to view your data, for example maybe you want to just see all the power paths through your circuit, or investigate how a signal travels from your input to your adc through filters, protection etc. Often on big designs these things might be strewn across multiple sheets and a bit hard to follow.
What stops electronics from becoming like programming is the routing. It's NP hard and even the big car companies haven't solved it yet, let alone any tool accessible to hobbyists and startups.
So you spend an hour designing the schematics, a few minutes placing the components, and then hours doing the routing by hand. If your product only replaces the first step, that'll save me at most 10% of the work.
If you want to make a crater in this industry, add an autorouter to KiCad and make it sophisticated enough to handle an ESP32 2-layer board without manual assistance. Altium is like $15k per year and cannot do it yet.
The physical positioning of big components or IO is usually an important requirement that needs to be frozen early on, so that mechanical design on casework can proceed in parallel.
it's non-trivial, you need to fiddle with parameters to encourage the autoroute towards certain behaviors. there are also some schematic patterns that lend towards better netlists and in turn better routing
I then built a little CLI tool which used bitmap images and ConvNets to do just that one fan-out, but then I lost interest in it as soon as the PCB was finished.
FWIW: Cadance "conceptHDL" is a schematic entry program which generates a Verilog netlist like this as its output (usually for board level simulation including ASICs and FPGAs). But if you're careful, Verilog could used directly as the input- the board-level schematic is pretty simple compared with the chip source code.
I'm sure there is a tool somewhere to convert this into an EDIF netlist for Kicad or whatever. [Icarus can do it: https://steveicarus.github.io/iverilog/targets/tgt-fpga.html ]
Also: this is not limited to digital: there is a variant of Verilog called Verilog-AMS specifically designed for analog simulation.
https://en.wikipedia.org/wiki/Verilog-AMS
In Verilog-AMS, you can define a simulation models of your components:
So not only do you get a component, but you also can simulate the whole thing before fabrication to catch mistakes.There's a few parts we think that are behind that, but one is similar to python's/Guido's "code is read more than it's written", so we're attempting to address that!
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.
I understand that auto-routing is not a solved problem by any means, but there should be more efficient tools to make it easier. I shudder to imagine laying out some big LED matrix without more advanced tooling.
The only issues I've had is how it outputs circular things for cutting - it does a series of polygons (configurable number), rather than an arc/circular - places like send-cut-send won't accept it, claiming it causes issues with their machines.
I love the graphical nature of Schematic design. It helps me visualise problems that my colleagues would admittedly rather code. I take a lot of care in my schematic layout, and it can help me make a good guess as to wether my circuit is planar or not. - usefull when you dont want to incurr the parasitics on a via somewhere.
I would also remark that there is no reason why design reuse would necessitate a text based caprure. We already have reuse though subsheet heirachy, ctrl c/ctrl c and to some degree reference designs.
The only other thing I would add is that a lot of people come from a hobbyist background, which means small volumes. For commercial contract manufacturing, drawing out the same old schematic features for voltage regulators doesnt add up to much NRE as a fraction of the project cost.
The point we would like to move towards is one where atopile enables you to generate high quality documentation about your design in a similar fashion to a datasheet but not entangling the documentation with the source design, which is what a schematic forces you to do. There are some features we'd want to build that could enable that like a visualizer for important parts of a schematic, a fan out view of the consumed interfaces around a chip, the results of a spice simulation...