Show HN: Atopile – Design circuit boards with code

@Timot05

I wish you the best. Among other things, you are reinventing Verilog and other attempts. Yet, of course, evolution does not happen without people who are willing to devote their valuable time and effort to consider new ideas.

My personal perspective, after having designed hundreds of PCB's, is that there's a reason for which symbol-based data entry has survived decades of computer-based circuit design evolution.

I have also written more software than I can remember in more languages than I am able to list. I have less than zero interest in using a software process to describe circuits of any kind. What makes sense for hardware design inside an FPGA somehow does not translate well outside the chip.

Software and hardware engineering are very different things. It is probably correct to bring-up the fact that many have tried to turn software engineering into precisely the opposite; dragging symbols around and connecting them in schematic form. That approach has failed but for the most trivial educational tools.

Could you imagine the pain of building an entire software product using only assembly code? That’s about how we felt designing hardware.

Having done this dozens of times, I don't think it is painful and don't see a parallel between assembly coding and designing electronics. In fact, assembly coding is easy for the professional experienced software engineer. Of course, it is probably close to a nightmare for someone who's never done it or never even studied machine level coding. Ballroom dancing is impossible for me. I am not a dancer. And it should be in a range between difficult and impossible for anyone without the requisite training and practice. So, that's not the right metric.

Drawing schematics is easy. Schematics convey lots of information quickly. Function, structure, constraints, implementation notes, support/service notes, fabrication guidelines, etc. Also, they are trivially and instantly easy to understand, gather around and discuss. They present a mental image and state that would require fairly deep concentration to develop if reading a schematic as code (except for trivial circuits, which don't really matter). Schematics, as I said earlier, have survived the test of time for a reason: They work.

That's not to say a different approach isn't possible. All I am saying is that I would think hard before attempting something that very clearly few engineers want and care about.

For reference, I started life drawing all of my schematics and PCB layouts by hand. I then transitioned to using AutoCAD v1.0 and writing tons of LISP code to make that easier. From there I migrated and used a bunch of tools most experienced EE's have touched: OrCAD, Protel, Mentor, Cadence, Altium, KiCad, Eagle and likely others I can't remember.

Oh, yes, I also completed a few layouts back in the day using X-acto knives and stick-on traces and doughnuts on vellum. That was fun.

This page shows a number of approaches. I all of these back in the early 80's.

https://www.pcbwizards.com/handtape.htm

Yes, that's a roll of black tape she is using:

https://i.imgur.com/yUgZ5zz.png

Schematics are not the problem.

This isn't intended to discourage you at all. All I am suggesting is that you might want to interview 100 EE's and see if this matches the idea of "build something people want". Don't interview software guys who tinker with electronics as a hobby (unless that's your audience). Interview real, working, EE's with 10+ years of experience using EDA tools from different vendors and generations. My prediction is that you will quickly discover nearly nobody cares about moving away from schematics. You will definitely find other pain pain points, just not schematics.

Thanks for sharing this blog post! Super cool to see how things were done early in the industry!

Counterintuitively, I do agree with your points. We didn't end up designing the ato language because we actively wanted to end up there but rather because we tried everything else before and none of the solutions we tried worked out.

The problem we wanted to solve was: "how does git look like in hardware?". Another way to phrase it is: "How can groups of people coordinate and share their work in hardware?".

The first solution was simply to put KiCAD on GitLab. That solves the version control part of the problem but doesn't solve consistency of design outputs, coordination and reuse problems. The we tried to add automation on top (namely with KiBOT) to generate manufacturing outputs automatically. That was pretty cool for consistency of manufacturing outputs but it didn't solve the coordination and sharing aspect of the problem. And so at that point we kind of had ran out of ideas of things to try. And that's when we started developing the ato language.

Schematics are definitely a great medium to share a design with your peers. But we've found that for those other aspects I mentioned, code is more suited.

Random thoughts.

I have a feeling that very few hardware projects have a bunch of people working on the same schematic. I have personally never experienced that in the context of a team project. What might happens is that each engineer works on a board and the interface between boards is defined by the team. I have done systems with 15 to 20 PCB's interconnected through custom backplanes this way.

Modern EDA tools have ways to save portions of schematics to a library of reusable designs. This could be one vector for collaboration if, for example, you have someone who is an expert in SMPS (Switch Mode Power Supply) design doing all your power supply designs. There is no need for this person to actively modify an ongoing design, all you need is a verified and tested schematic unit you can just plop down and move on.

I think a key difference in hardware is that you cannot constantly be engaged in modifying the schematic. These are things that become real physical instantiations at a given point in time. And so, the concept of using software tools isn't necessarily applicable. You most definitely do not want someone changing a schematic after it has been released to production.

Then you have to step back and look at things at a system level. The schematic is the least important part of the process. Imagine something like an industrial CNC machine, the real deal, a $100K machine that has to work 24/7 and not kill anyone. This machine likely has dozens of PCB's, wiring diagrams, mechanical components that need to be machined, injection molded, made from sheet metal, hoses, valves, sensors, etc.

The schematic, is the least of the problems we come across when designing such systems. It simply isn't a pain point. And there is very little need to iterate like we might in the software domain. In fact, that could be very dangerous, because, at a minimum, you can't just recompile your way out of a mistake.

Sorry if I sound negative about this. That isn't my intent. This is just my opinion based on decades of doing electronics at every level. I have, BTW, used software to generate netlists for very specific designs. In one case it was an array of hundreds of sensors (the same sensor) on a PCB. I just wrote a Python program to generate the netlist. That's a very specific case where a schematic doesn't offer a great deal of value. In this case a simple PDF documenting the board interface and how the sensors were connected (a matrix) was enough.

We hear you! We're most certainly planning on eating up the system's chain to describe, version control and validate up the system's chain.

As one example in an earlier (and likely future) permutation of atopile we could compile harnesses (using the fantastic https://github.com/wireviz/WireViz) by linking two interfaces on connectors.

Long future, if you can integrate mechanically too, you can at least check if not generate the harnesses lengths, bend radii, drip looks etc... for that same harness.

Somewhat like software, you can only tractably do that at scale if the units work and work reliably. Unit tests are the basis of software validation and we expect hardware validation as well. We're starting low-level we know, but with a concepts we know (from the insane scale of big software projects) can work on enormous projects too.

Many of the things you mention are not really done in hardware.

For example, unit tests. Even in FPGA designs, you can run functional simulations on portions of a design to help save time and validate. I don't believe we are yet at the stage where we simulate the entire chip. Not sure it would make sense even if you could. You have to worry about real-world effects such as clock skew and jitter that might not necessarily be deterministic. If you have designs running at hundreds of MHz or GHz, at one point you have no option but to run the design on the real IC and debug in hardware.

The other issue is that every company is likely to have their own process for some of the things you mention. Harness design and manufacturing is a good example of this. Companies like Siemens, Zuken, TE and others have professional solutions that often integrad with CAD/CAM tools (like Siemens NX) and produce professional manufacturing-ready documentation. Job shops, in many cases, are setup to receive files from industry standard tools and work directly from them. WireViz is a neat tool, but it is pretty much at the hobby level.

For example:

https://rapidharness.com/

https://www.zuken.com/us/product/e3series/electrical-cable-d...

https://www.sw.siemens.com/en-US/vehicle-electrification-wir...

You should not be discouraged though. That said, I would still urge you to interview a lot of EE's and product design engineers to really understand what you are walking into. You need to realize that you are not likely to change the entire product design and manufacturing industry just because you offer a software-like approach to design. That's just not going to happen. Industries have tons of inertia and they tend to only be interested in solving pressing problems, not adopting entirely new workflows. Also, the EDA/CAD/CAM industries are paved with the corpses or thousands of offerings that, collectively, over time, defined how things are done today.

My guess is you'd have to raise $100MM to $300MM, hire tons of engineers and devote ten solid years to materially influence how things are done. Nobody has the time or budget to introduce new tools, new problems, new training and grind their entire product development process to a halt just to adopt a new paradigm.

I'll give you an example of this from real life. The CAM tool we use to program our CNC machines is crap. We use CAMWorks Professional, which integrates with Solidworks and probably cost us $30K+ per license (between initial purchase and maintenance fees). We want to switch to at least doing CAM using the Fusion360 tools. However, this will definitely cause us to take a hit in productivity and possibly put out bad product for a period of time until the dust settles. And so, while we absolutely detest CAMWorks, we have no choice but to continue using it until a window of opportunity presents itself to make the switch. And, of course, also knowing full-well that the Fusion360 solution isn't utopia. There are no perfect tools. Just choices you might be forced to live with.

This is all so true! But it also describes the problem very well. Of course a $100k CNC machine design will always be developed by a small team collaborating as you describe. But the tools and processes that work for that most emphatically do not work well for smaller projects with more distributed contributors.

Custom PCBs are so easy to order these days, but they are hellish to design and test well. That would change rapidly if we could reuse basic blocks the same way we do with code

smaller projects with more distributed contributors

Smaller projects are either handled by one or a few engineers, with each looking after one or more disciplines. I can't see collaboration on a PCB as a thing.

For example, I have personally done electrical, embedded code, FPGA and full mechanical design and manufacturing on many products that can be described as one or a few PCB's with < 1000 components. Not that hard.

I am open to the idea that I just don't have the experience in a domain where more than one engineer actively works on a single circuit board. By "actively works" I mean, simultaneous editing of portions of the PCB with the equivalent of a team leader handling pull requests, etc.

I have worked on PCB's full of analog and digital chips in the 30 x 30 cm range (12 x 12 in) entirely on my own while other engineers worked on other boards that plugged into the same backplane. I have never worked on a single board where anyone else is running simultaneous edits. The closes I have gotten to that would be a power electronics engineer "blessing" a switched mode regulator design that I then manually integrate into my work (and so do others).

So, yeah, don't know. I'd be interested in hearing from anyone who regularly works in an environment where simultaneous team editing of a single PCB happens in the same manner as one might with something like VSCode and "Live Share" collaboration sessions.

Sorry, I just don't know if that proposal is realistic. Not my range of experience, which means nothing at all.

I agree with every comment robomartin has posted on this thread.

I'll add: I HAVE worked on schematic designs with 10-20 people working on an overall schematic design at the same time. Usually one or more engineers own some sub-section of the design ; i.e. for a mobile device, one or a few people own the "power" part of the schematic, the camera team owns the camera portion(s) of the schematic, etc.

Mentor (DxDesigner / Design Capture) and Cadence (Concept) support this flow, but with the oddly more popular but OrCad this can be a nightmare.

Hi, @Timot05. I’m a former EE with 20 yrs experience working in the industry and have designed dozens of very large complex mixed signal PCBAs 4-32 layers, as well as about the same number of large FPGA SoC designs.

I watched the demo video out of curiosity and here’s my 2 cents, though there is a lot to unpack here:

First if you want to know the current state of “how does git look like in hardware” as far as PCBA design is concerned look at Altium which uses git under the hood now to provide a very nice visual way to show differences in both the schematic and PCB layout between versions that solves some real pain points for an EE and therefore EEs actually want it and use it. There are ways to create reusable, version controlled sub-circuits that get put into libraries as well:

https://www.altium.com/altium-365/hardware-version-control https://resources.altium.com/p/introduction-git-altium-desig...

Whatever open source you build should be modeled after that.

I found the above very nice after years of manually using git to version control PCBA designs developed in other ECAD tools like PADS, Orcad, Cadence etc. I even tried to get a couple EE’s and layout people to use my methods of git version control, documented in the README of course, but to no avail, most strictly hardware EEs (with no FPGA or SW background) either can’t grasp git or don’t see the point in spending the time on it. The same people will quickly pay $10k-15k a seat for Altium to get that slick UI on top of git version control because it makes things more visual, not less, which as others have mentioned is important in PCBA design I’ll get to in a second.

But, I understand better what you actually mean because you phrased it another way “how can groups of people coordinate and share their work in hardware?”

That depends of course how / who are you coordinating and sharing with? How are you dividing up the work?

In my experience, even with a very large complex mixed signal design, there is one guy per board, and in the extremely rare case that a single board is being worked by more than one person it is usually divided up by discipline typically, RF, analog and digital and those people contribute their pages in any number of ways including using sub-circuit modules out of an Altium library.

And, EEs lean heavily on reference designs and eval hardware to do their work. Though they do spend a lot of time reading a lot of data sheets they really don’t have time to read most of them, just reference the ones they need to integrate existing designs and handle the new parts of the design (which need to be minimal). They need to get large parts of the working designs handed to them with eval hardware they can test and vet on the bench, and with reference designs (schematics, layout, firmware and some documentation) provided by and supported, somewhat, by the vendors of the major components. Not some open source developers who can’t really support the major components utilized in their designs effectively because they don’t have access to all the information they would need to do that, talk to the fab etc. They can only talk to FAEs, same as all other engineers outside the vendor.

Also, PCBA design is very process oriented. Even if a company doesn’t have a PCBA design process this will not slow down an experienced EE who I say has learned what I call “The process” with a capital T. Schematic capture and layout are 2 very hard and fast steps in that process with boundaries that been defined by decades of EE college curriculum and EDA development that aren’t likely to see any change in EE in the near future, though I think the EDA industry is in need of some disruption somewhere, it is not here.

I started designing CPLDs and FPGAs right as most people had switched from capturing their chip designs in schematic form to capturing them in verilog and VHDL. It was a disaster. Most EEs in that space (including myself for a time) were really bad at architecting their modules and then structuring and writing the HDL code to make sense and be maintainable. Good documentation and block diagrams were essential for development and maintenance. And, after 20 years, it is still a huge problem for a lot of designs. I really wish someone would make a good tool to aid in the construction of block diagrams from the code of large FPGA designs. Too often I would inherit a legacy design and find myself having to spend a week or two creating block diagrams and other documentation for the design.

I shutter to think what it would be like to try to understand and debug a PCBA for a 20 layer board that was just a bunch of code or text and didn’t have a schematic and some decent documentation. It’s bad enough that EE’s are frequently handed a large schematic and layout with little or no documentation for it except a folder full of the data sheets for each component.

Thanks for your detailed answer! Tons of information in there.

To your point about how the work gets divided, I don't think that work will necessarily be distributed amongst many people for a given design but code gives you a couple of benefits:

- you can branch and merge the changes you make, which means that you can design a given feature and have your team review only this change instead of reviewing a batch of changes.

- If someone actually does want to pickup your design and wants to contribute to it, code makes it easier for them because more information is captured in the code, so they get a better sense of what the design requirements are.

To your last point, we don't really see the code becoming the documentation of the implementation of the module. Actually the goal is to do something similar to the IC space or the software space, where the code becomes the implementation of something but the documentation lives somewhere else, perhaps in a datasheet-like document. Currently the schematic forces you to have both the documentation and the implementation baked into the same document, which forces you to find a middle ground between adding information relevant to those two objectives.

you can branch and merge the changes you make

I don't think this a fundamental exclusive benefit of "code" (ie text). I am skeptical how textual merging, especially default automated, can be applied in this domain except in trivial ways. This is a usually easy sell for software because you can structure your system to localize effects (even if there it isn't perfect). The big guns have very sophisticated workflow and tooling for this.

https://www.altium.com/documentation/altium-designer/collabo...

https://www.altium.com/documentation/altium-designer/using-v...

code makes it easier for them because more information is captured in the code

I sincerely don't understand. Perhaps it is informative to consider that SPICE has been around for 50 years. The idea of using textual description for circuit design is not new at all, and they are used when appropriate. One must ask why the basic workflow is the way it is when the alternatives have always been possible.

Currently the schematic forces you to have both the documentation and the implementation baked into the same document

Not entirely onboard with this forcing assertion, but is this necessarily a bad thing? https://en.wikipedia.org/wiki/Literate_programming

what it would be like to try to understand and debug a PCBA for a 20 layer board that was just a bunch of code or text and didn’t have a schematic and some decent documentation.

That's a seriously important point. Open source is filled with just plain horrible code. EE's who are not generally trained in software development can deliver reasonable schematics. There's the potential for utterly unintelligible designs if they had to create them using software techniques. I have seen FPGA code that is most-definitely cringe-worthy and unintelligible without, as you said, stopping to draw a schematic.

One way to think of this --in terms of circuits, not FPGA's-- is that a schematic can stand on its own. A text based netlist, even if sophisticated, requires documentation and, more than likely, a schematic.

I should probably add this:

One of the most useful things when developing anything at all is push-back or criticism. That's where you find value, insight, ideas and learning. I always value counterpoint far more than anyone who keeps telling me how great I am and that all is well.

Very recent example: I enlisted ten people a few weeks ago to critique a presentation I had to give at a conference in Zurich. One person, when I sent her the first draft, told me it was fantastic and that it sounded great. I never sent her version 2. Others pounded me hard with critique from every angle. They got every version until they had nothing negative to say. The last person stuck with me until the very last draft, she critiqued it until we both agreed it was time to let it go and focus on delivering what I had.

I say this to highlight that what I've been telling you is 100% in the spirit of constructive criticism. People telling you this is great is fantastic, but that never helps you make a better product or understand if you are on the right path. Keep going. Do what you believe is right. You don't have to accept or act on any criticism or push-back, listen to it, take it in and then do what you think is right given your objectives.

Not at all! Thanks so much for engaging with us on this level. It's greatly appreciated!

Fully agree! We'd much rather be in a situation where criticism is consistently thrown at the project so we can further improve it rather than having positive feedback and the discussion just stopping there.

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!

Here's something that has been true for decades: Storage is cheap and always getting cheaper.

When you are dealing with complex multidisciplinary designs (a full machine), the concept or a release takes-on a very different meaning.

Scenario: You update a single circuit board, or the code that runs on a single microprocessor.

The release descriptor for the product, the machine, must include every single element that goes into making that machine. If all you do is commit the software update to Git, you very well run a chance to create a very serious problem for manufacturing, qualification, testing and post-sales support.

It has been my experience that, because storage is cheap, a release due to any change is a full annotated copy of all design files for the entire design; electrical, firmware, software, mechanical, testing, manufacturing, etc. In some cases we've had to save entire virtual machines with working code because workstation and system software can mutate and things break. We recently had a case where a Windows 10 automatic update (don't get me started) broke code that used to work in a last month's Windows version.

If we accept that storage is cheap, then the concept of releases at the product level, are simple copies along with a set of relevant "readme" files describing release details. You can come back to this three years later and all is well.

In the era of little Arduino boards it is sometimes easier that, more often than not, electronics don't exist just for the sake of electronics but rather as part of a much larger, and often far more complex, multidisciplinary product. In that context, schematic entry is an insignificant burden. The same is true of hyperventilating about what code editor to use. Some of these things are truly rounding errors in the product life cycle.

The value is mostly in the software workflow, not in the software tooling.

Store your KiCad files in Git. Make a script which automatically adds a revision tag to the PCB. Create a CI pipeline for Gerber generation. Export PNGs so you can do visual diffs.

If you're collaborating on some project which consists of artwork made in Photoshop you aren't looking for a text-based drawing program either - you are looking for a better way to do diffs.

This is the most useful comment in the thread (so far)!

This product would not work at all for any analog or power designs--EEs like to visualize current flow and a schematic is the best way to do that. Maybe if it could interoperate with small blocks of schematics, treating them as modules, it could be useful. If there was a way to parameterize part values, like those used to build analog filters, that could also be useful, but not in the current text-only form.

The one thing it could be useful for is creating net connectivity for large numbers of pin to pin connections, like DDR memory or PCIe buses. Schematics for these end up looking like large data tables anyway, and can be tedious to create and prone to errors.

I see so many EDA startups using their product for simple Arduino boards and other low to medium complexity designs. It's far more effective to start with the most complex board design. Take a server board from the OpenCompute project with a few thousands parts and a few tens of thousands of nets. What would that look like in this language? Would it have too much boilerplate code? What would the experience of creating it be like? How do you handle back annotation? How do you handle pin swaps, or part section swaps? How about BOM variants?

The one thing it could be useful for is creating net connectivity for large numbers of pin to pin connections, like DDR memory or PCIe buses. Schematics for these end up looking like large data tables anyway, and can be tedious to create and prone to errors.

This is a good example. I'll expand it to include such things as breaking up the symbols for a large FPGA (say, over 1000 pins) into multiple schematic blocks and managing them as the schematic design progresses. Very often you have to move pins around within the same block or between blocks just to arrange them logically or align them with whatever they might connect to.

For example, take the output of an FPGA bank and connect it to the input of an HDMI transmitter chip. You would want to align the red, green, blue, clock and control pins so that you can connect them with a bus that looks right. If someone reading this isn't clear, imaging arranging the pins on each device in random order where, for example, the first chip has R0,B8,R1,G5 and the second chip is R0,R1,R2, etc.

This kind of thing is tedious and painful.

The way we solve the problem with Altium was to write code that allows us to fully define an FPGA (and other IC's) using data entry in Excel. One turn of the crank creates all symbols and PCB patterns and exports into the libraries. This took something that was a days-long torture to maybe 45 minutes of work. After that, if you need to move pins around, it takes minutes to update everything.

This is also an example of why a text file based approach would not be as useful. Entering data in Excel is very easy. Editing it is just as easy. In some cases you can even copy and paste from datasheets and easily edit or rearrange. I can also write formulas to generate sequences of pins, etc.

Having to manage this in a text file would not be as slick. Over the years, I have found that Excel, coupled with VBA code, is a very powerful tool for schematic entry and PCB design.

Yeah, I have to agree. It's a neat idea and I can see it having some applications, but I don't really see myself using this for anything serious.

I think OpenSCAD neatly demonstrates the issue with 3D modeling: when you come from a tool like Blender it might look amazing that you can now trivially change dimensions mid-design, but what you're really looking for is the parametric modeling you get from something like Solidworks.

Schematics-as-code doesn't solve a problem I am having. What I want, is for an easy way to import "snippets" in KiCad: I want a library where I can select an MCU, and it'll automatically add all its auxiliary parts too and let me choose from a few pre-made standard routing options. Maybe even make it parametric so it becomes a nice little wizard where if I'm adding an LDO I can enter a voltage and it'll calculate the adjustment resistors for me.

You're right about "code" not being the right solution for everything. In the case of the layout we have indeed already already implemented an MVP of the "snippets" approach you described: https://atopile.io/blog/2024/02/02/-layout-reuse-keeps-getti...

A big part of the code is that creating a wizard for each issue it a tall order to develop, but through expressive and composable language we should be able to articulate the parameters for the configuration just as as clearly and generically solve that class of problems.

Very nice!

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.

Yeah, trying to learn KiCad is worse than learning Blender. If JLCPcb made a simple online editor that sourced from available parts and integrated directly with their store they'd be running out of banks to put their money into.

Yeah, trying to learn KiCad is worse than learning Blender.

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.

This. By FAR the most annoying thing of creating a simple PCB is dealing with symbols and footprints. Why the hell is this is not a solved problem.

Because every CAD, which has traditionally been dominated by commercial solutions invents their own file format for lockin.

On top of that semiconductor vendors don't want to hire people to draw symbols in every possible cad solution.

So you instead have them release symbols in some preferred tool, maybe they also outsource to third party services like UltraLibrarian. There problem with the third party services is they do the laziest conversions possible between format using scripting and often do a horrible job.

Because every CAD, which has traditionally been dominated by commercial solutions invents their own file format for lockin.

This doesn't really explain why creators of new CAD programs (Horizon and LibrePCB are new) invent new data formats.

We've seen time and time again, in every digital domain ever invented, that the most important thing is the dataset.

It doesn't really matter how nice the library manager is if what it manages has limited availability - and no, asking for a community to pitch in and help with the duplicated work is not a solution.

The solution is to pick the largest library and use its format.

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.

this resonates. i will share that i'm trying out and having luck with flux.ai. it's not perfect, but for a small hobby project and someone with little experience and not getting far quickly in kicad, it works. i have a pcb in-hand from jlcpcb right now and it works. it also introduces some of the shared features discussed above. (i don't work for them, just looking for something that would let me do a fairly fast PoC)

Oh now this one is interesting, I've given it a short try and the UX is just on another level compared to the usual, I might actually be able to get something done with it. This is what EasyEDA should've been, not the terrible KiCad web clone that it is.

For us hobbyists there's no point in investing years learning something proper like Altium because we won't ever be shipping to production or doing stupidly complex multilayer boards. We need the Tinkercad for PCBs, not Fusion360. Something that can be crude and oversimplified, but quick to use and also simple enough that even middle schoolers can learn it.

Kicad is not that difficult to use. Sourcing parts can be though.

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.

They do! EasyEDA, and have used it to make custom keyboard PCBs. It's pretty handy and I found the learning curve to be much easier than KiCAD, etc.

They did and there's even tools to import their component library into Altium or Eagle.

I learned kicad fairly quickly. I've tried several times to learn blender and failed. Then again I'm bad at art.

As an electronic design engineer, it just feels to me like these kind of things aren't really huge problems day-to-day...

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

We have some plans and atopile already supports some configuration regarding those deviations. There's a component selector which can choose resistors, caps, inductors etc... from a database of known components. Currently it's a free-for-all, but naturally we expect to be able to constrain this to a subset of components like "thing we already use at this company". That database means (once equations are also in) we'll be able to capture those requirements and change those output components depending on the scenario.

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.

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.

> The problem is that it's a really hard problem for which no one-size-fits-all solution exists.

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.

For sure, we definitely subscribe to works out of the box / path most taken. We have been working on adding equations to our language so we can solve component values based on requirements like output current and ripple for a regulator to get cap values for example. I hope in the future our component models will capture a good fraction of the info you have to go to the datasheet for today.

Unless I'm missing something, this is not circuits-as-code, it's just circuits-as-text. It's basically a non-standard way to represent a netlist, and to hang metadata off that netlist -- which is, to be fair, quite cool and useful.

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/

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.

Get even a basic equation solver in there and I'll be a user! Have it handle units properly and I'll be a happy user. Have it be able to handle both worst-case and RSS tolerance stackups and I'll be in love.

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!

Will it take into account temperature ranges and other parameters as well?

If we can build the equation solver our hearts are set on, you should be able to account for as many factors as your design requires - albeit with some performance limitations at some point. That is, assuming temperature can be factored into equations in the same manner as any other parameter or attribute

We're also super stoked about getting topology and equations together in the same file (and even code-base!)

The equation solver is soon on our roadmap: https://atopile.io/roadmap/#language-features

Solvespace has a nonlinear algebraic equation solver:

https://solvespace.com/index.pl

It's what underlies the geometric constraint solver which you don't need for what you're doing. It's probably worth a look under the hood. You might also read this post from Michael-F-Bryan implementing something similar in Rust:

https://users.rust-lang.org/t/geometric-constraint-solvers-p...

He based his work on what he learned from Solvespace.

Thanks for sharing! We will have a look

Had a play here for equations: https://github.com/atopile/atopile/blob/tim/equations/sandbo...

This is great. The pragmatic bit that makes it a bit more challenging (or, perhaps, a bit more of a search optimization problem than analytical) is that most of the cost functions are step functions. Once you need better than 10% tolerance on a resistor, you might as well step down to 1% -- available tolerances are discrete, and 5% and 2% tolerance parts are rarely cheaper than 1%. Similarly going to 0.1%. So once it's clear that preferred_tolerance_N is not going to solve, you can assume preferred_tolerance_N+1, and then push that through -- and hopefully push a few marginal parts up a bucket. There's also a similar step-function cost for adding a new BOM line, especially for hobby-scale projects; this is a project-global optimization, where I might change a 10 kΩ / 2.2 kΩ resistor ladder to 6.8 kΩ / 1.5 kΩ if I already have 1.5 kΩ, 6.8 kΩ, and 10 kΩ in my BOM but would otherwise need to add 2.2 kΩ (assuming everything else still solves, of course; more likely than not, since we usually don't care much about the total resistance of a ladder, as long as it's stiff enough, and doesn't leak too much).

Hadn't thought about the BOM line one but that definitely makes sense. The implementation I linked is definitely math heavy but might actually not be the best idea. As you say, the cost functions has steps. For less than a given amount of components, random search might be suited. Past that point, we might use maths to constrain the problem and then search within that range.

We have equations at the top of our todo list and hope to get there soon :) Matt setup a roadmap here with things we want to work on: https://atopile.io/roadmap/

it's just circuits-as-text.

atopile (1) — convert ASCII to pile of electronic components

love it

I think this is a wonderful idea and begins to create a foundation of data richness and interoperability for a very exciting new approach to PCB design, as I commented elsewhere in this thread

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?

I was thinking the same thing (I'm an EE by day). I think this idea is very cool, but since the dawn of time schematics and PCB layout have always been visual because you are actually building a physical thing. Its easy to see hardware bugs in schematics visually. However, it might be very hard to track it in code, unless the code is one day smart enough to find the bugs for you. You have to hold more context in your head that you cant export to your visual senses when its written as code. You cant see the actual circuit flow.

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.

We do agree. We built an early version of a viewer in the project but later moved away from it because it wasn't good enough to interact with. We might come back to it with something that is more targeted at inspecting only sections of the circuit or provide a block diagram level representation. But we don't think that just outputting a schematic the way they look today is the right solution.

You might find this a stumbling point for adoption. My first thought is this could be a good tool for me to use, but how can I send a design to someone else to get feedback on if I’m not going to expect them to also also learn how to use this or how can I get my design manufactured if the tools can’t export out the, normally very visual, layout files.

I do think that is fair. The reason that we don't have a visualizer is not that we don't want one, but rather that the value to effort ratio is quite low (and really because the effort is high, not because of low value). I'm sure we'll get there at some point. But at the moment there are more pressing issues for the people who are ok dealing with no visualization (like typing, language server, equations etc...).

I’d definitely consider not letting some basic visual schematic outputs fall too far down the priority list.

A lot of existing EE is basically just the visual diagrams and a lot of existing EE people will expect the tools to give them the visual diagrams they work with somehow… like even just including the compiled schematic as an SVG in with the compiled outputs of netlist, gerber, etc… something that other software can be used to convert to PDF without extra complexity in your tool and can be used to interoperable with the existing talent pool of EE people who have not just no idea how to use your tool… but know how to read typical style circuit diagrams.

I worked on this for a little while myself.

It wasn't so much "pc board by code" so much, but it was more a "pc board by CLI" approach.

And by that what my goal was, was to offer primitives and utility functions that would build the board up over time, but it was to be done incrementally in a Lisp REPL.

My use case scenario, was ancient AutoCAD.

Back in the day, while you could hook up a tablet or other pointing device (I'm talking pre-mouse here) to make AutoCAD drawings, a lot of it was done simply through typing in commands, in AutoLISP.

(lineto 100 100) kind of thing. And the drawing would appear on the screen over time, you'd save the data model, and manipulated with the REPL. If you wanted 10 lines:

    (dotimes (i 10) (let ((x (* i 10)) (y 100)) (line x y x (+ y 100)))

(HN does not have a paren matching editor, apologies...)

Where it broke down for me was coming up with a graphic rendition using CL.

If emacs had anything reasonable regarding graphic support (its SVG support is Not Good), I'd have done it there.

Rethinking it, it just occurred to me I could have probably gone a good way using ABCL in a Java GUI shell.

But the key point is that I think using a REPL for building up something like a circuit can actually work, actually be efficient for users, especially if it's extensible (i.e. (defun grid ...) ). Especially a hybrid (like clicking on a line pastes an identifier into the REPL).

My experiences with KiCAD drove me down that mad hole.

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 agree - also an EE - and I think it is similar to 'programming music' packages like Sonic Pi. If you are used to reading and writing standard music coding will be an odd and difficult change. Right now we have a comfort for seeing the layout and such physically, and since that is how we manufacture it this is going to be an output anyway, but there is some future world where it is all put together automatically within the requirements we specify and we have an entirely new way of designing circuit boards. Each component would come with not only a footprint but an array of basic design implementations that would mix and match with others.. autorouting on steroids of sorts.

Yeah that’s an interesting aspect. We did implement a viewer very early on. And we then removed it from the project.

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.

As a novice, a viewer would be really helpful to me to understand what it's actually doing. I did bookmark this for the next project I have in mind.

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.

Worth adding, we have found much higher returns building tools to solve the problems that a visualizer would normally help you with in other ways. For example ERC checking and modular abstraction of circuits. Working at a 'block diagram' level is much more intuitive than at the net level in my experience.

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.

One thing that surprised me when moving from mechanical CAD to EDA programs is the lack of "relations." I have not used the more professional tools, just KiCad, but it surprised me that there are not more variables, relations, constraints, subassemblies, for things like buck converters and these types of things. KiCad has 'netclasses' which let you set trace widths, but it's all manual, same with the design rules checker. Each vendor seems to have their own design manual for these things, which is nice to have but so tedious -- I have to read a PDF to know what size decoupling cap goes with this IC? Why is that information not encoded in the footprint somehow?

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.

look at OpenSCAD, it's a scripting language to generate models. I used this a lot to generate subpieces and build off of that. easy as saying Bolt("M5", 1.5) or something

As a regular OpenSCAD user, I wouldn't bring it up as a good solution for anything. It exists, you can solve problems with it, but it isn't a good design. It should just be a library in a real language.

It should just be a library in a real language

The last thing I want to worry about is having malware in an M5 bolt.

From a security perspective, it does help that ato is not executable!

I've found CadQuery to be a pretty good replacement for my purposes, but I haven't done anything complicated with it yet, just designing 3D printed/laser cut electronics enclosures.

Ya OpenSCAD is great for in/cross project re-usable components.

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.

Old issue, but annoying nonetheless. Less of a problem when outputting STL files (for printing) which only support polylines and not arcs/circles. Funnily enough, 3D printers nowadays support arcs natively in G-code, so some slicers support detecting rounded polylines and converting them back into circles or arcs.

Found a script[0] that does this for DXFs in a github issue[1].

[0]: https://github.com/nophead/Mendel90/blob/master/dxf.py [1]: https://github.com/openscad/openscad/issues/4605

I actually opened that issue - I'm ukd1 on github too. I looked at fixing it at some point, but it tbh didn't seem that easy or like they had time to help, I should probably revisit. The script I couldn't get working right last time I tried, but I should give it a re-look!

I have used it, I think its great. I am excited to see whole products defined in code.

I found OpenSCAD's 3d model representation to be very challenging for anything complicated. I used FreeCAD, which is scriptable, but also uses a brep representation instead of CSG, which IME works a jillion times better.

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.

I'd like to hear the opinion of Lady Ada on this - one of the industries greatest hardware designers.

one of the industries greatest hardware designers

Is this meant sarcastically?

>Is this meant sarcastically?

No I don't mean it sarcastically, why do you ask? Do you not see Lady Ada as a shining light of the industry?

Lady Ada is one of the industry's greatest hardware designers and I would value her opinion on this.

If you don't know who she is, her name is Limor Fried and she founded AdaFruit.

I don't have current stats but from 2016: Revenue US$45 million (2016)[1] Number of employees 105

Front page of Make Magazine:

https://blog.adafruit.com/2017/05/08/limor-ladyada-fried-on-...

Front page of Wired:

https://www.wired.com/2011/03/wired-magazines-cover-features...

Front page of Smore magazine:

https://www.adafruit.com/product/3920

Front page of Hackspace:

https://www.flickr.com/photos/adafruit/40061387915

By "industry" you mean "electronics hobbyists"?

I oh see you are wanting to diminish her capabilities for some reason.

I'm not interested buddy, you can take your sneering elsewhere until you show me the multi million dollar company you have created, the hundreds of commercial quality boards you have designed and sold for real money, the driver software you wrote to make them usable and the industry accolades you have received - on merit.

She's a solid entrepreneur and a competent engineer.

Calling her "greatest" seems odd, for implementing breakout boards with datasheet circuits.

I agree. She's really great for hobbyists and for prototyping. She's done a ton to help beginners. And Adafruit is a very interesting company. I seriously admire her. But as to the original claim that she's "one of the industries greatest hardware designers", when you look at the electronics industry on a whole (an industry where people design incredibly complex things that are used by millions/billions of people), her _designs_ are nothing special.

and sold for real money

"Lady Ada" and Adafruit certainly are good at price gouging. They often charge exorbitant prices for the same stuff we can get elsewhere at a fraction of the cost. No, providing datasheets and some instruction isn't enough, there's a thousand other sites with better instructions in most if not all cases.

As far as I can tell, Adafruit doesn't price gouge. More expensive than some other US places, sometimes, but usually not by much. Sometimes they're cheaper than similar US places.

The only places that sell same or similar items for drastically less than Adafruit are places like Aliexpress (or the same foreign sellers selling on Ebay), and there are many reasons why Adafruit is more expensive than those places...

Some of the stuff Adafruit sell is likely sourced from Aliexpress (or perhaps from Alibaba if they're buying in large enough quantity) and is indeed priced higher at Adafruit, but that's because if they price it the same or lower they make no money. So we know for those items, they must mark them up. But how much they need to be marked up is kind of complicated. Buying lots of things in order to resell them is more complicated than buying just one or two things for yourself, especially when the seller is on the other side of the world. Simply put: there's a lot more overhead when buying for resale that you don't have to worry about when buying low quantities for yourself. One big difference is that they need _reliable_ suppliers with large quantities consistently available, and those are rarely the same sellers selling things for pennies. (I could go into more differences, because there are many, but this reply is already getting pretty long. Ask me if you want to know more, or google for info about how to open and run a retail business.)

Also, bear in mind that some of that stuff that you can get elsewhere at a fraction of the cost than Adafruit are actually Adafruit's own designs being directly cloned, like a lot of their breakout boards. In those cases, you really can't blame Adafruit, since the reason those items are cheaper elsewhere is because someone's specifically trying to undercut them (often at the expense of overall quality and sometimes even at the expensive of authentic correctly-working parts).

Adafruit breakouts, libraries, and other various components are often leveraged at early prototype stages in general industry.

That is unless all you do is high speed FPGA work and that's all you consider to be "industry".

So would we! I think we are trying to do much the same things, make hardware design faster and more accessible.

I love that this is human-readable plain text. Plain text is almost always the best format for anything.

Text puts the problem squarely into the sights of generative models.

Maybe one day, but I’ve asked the various models basic EE interview questions, and it’s painfully obvious that while it can make a paragraph that has the right words, it’s incapable of reasoning spatially, or describing complex connections. My job is secure (for this year).

I have noticed a huge improvement in ChatGPTs coding abilities having an interpreter to check its work. I expect we will be able to bring a similar feedback loop to hardware once we can integrate things like simulation and equations. Also having modules that are tricky to configure incorrectly.

I’ve noticed the opposite with chatgpt.

To be fair, idk how much elixir code is in the training set.

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

The performance of ChatGPT (4) changes frequently. Lately it has been crazy good. I fed it a non-trivial but naïvely written (and thus slow) numerical algorithm written in Python yesterday. I then told it to vectorize, which worked and was both correct and several orders of magnitude faster. Then parallelize. Faster yet, and still correct. Pretty amazing.

Just an anecdote.

Absolutely! With only a few dozen lines of context to pick up the syntax, copilot is already able to make useful contributions like configuring regulators and filters.

Worth noting afaik all kicad file formats were already sexprs, can't get much better than that.

In that vein, I'd imagine it would make lot of sense to build a lisp on top of that, macros and sexpr manipulation are very much the strong points of lisps.

Thank you! We've certainly been heavily inspired by python and Guido's insight that code is read more often than it is written.

Yes yes yes! I love it when people make the things I think would be a good idea, and then stay on the hobby project idea list for years to come. (I'm struggling to make that not sound sarcastic - maybe it's just my British reading! - but I really am sincere.)

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!

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

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.

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.

Absolutely love to hear that!

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!

`import Y from X` is a terrible language design decision, established by the JavaScript ecosystem. It should be along the lines of `import X.Y` or `from X import Y` so that autocomplete tools can assist you.

Aspects of the python lexer and parser implementation were borrowed from python, which is partly why we ended up here. I do agree though.

Python does from x import y though.

Yeah, I think we only allow import x from y for the minute. And because we don't have a language server yet, it wasn't obvious that it was an issue. That'll change soon when the server is up though!

Agreed, we need to flip this.

Really? When I type import { someVal in JS, VSCode autocompletes it to import { someValue } from “somePackage”. I haven’t had issues here.

Disagree. I rarely remember what lib has the class/function/whatever I need. Doesn't help that some libs often use "proprietary" names (e.g. "Uno", "Avalonia", "Rotativa"). I often don't even write "imports" myself. I use stuff in code and let my IDE autoimport stuff.

Why not use Verilog or SystemVerilog?

    module blinky
      (
      input v3v3,
      input gnd
      );

    wire led;

    wire led_r;

    rp2040 u1
      (
      .vcc (v3v3),
      .gnd (gnd),
      .gpioa15 (led)
      );

    resistor #(.VALUE("220"), .TOLERANCE("5%"), .PART("ERJH2CF1R10X"), .SIZE("1206")) r1
      (
      .a (led),
      .b (led_r)
      );

    led #(.PART("WP7113SURDK14V")) d1
      (
      .anode (v3v3),
      .cathode (led_r)
      );

   endmodule

Use Verilog parameters for all of the part information you might want, like links to digikey part number.. or bury them into modules with different names.

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:

    module resistor
      (
      inout electrical a,
      inout electrical b
      );

    parameter real R = 1.0;

    analog
        V(a,b) <+ R * I(a,b);

    endmodule

    module capacitor
      (
      inout electrical p,
      inout electrical n
      );

    parameter real c = 0;

    analog
      I(p,n) <+ c*ddt(V(p, n));

    endmodule

So not only do you get a component, but you also can simulate the whole thing before fabrication to catch mistakes.

I think a lot of young hackers just don't have the breadth of experience to know what has come before them, or what is in common use. OP has reinvented synthesis, but poorly.

And if you want to go there (which you did), older hackers have too much experience and are therefore set in their ways and are incapable of innovation.

“Go there”? This isn’t a battle. Both can be true. But experience is a fact.

Not even quite synthesis yet! We're well aware there's quite a lot out there that's fairly analogous - but nothing that's quite translated to the space, despite a few efforts as pointed out above.

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!

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.

Did you know that the KiCad file format for schematics and PCB layouts is text? And it kind of reads like source code? You can even check it into Git.

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.

you can do this with the Freerouting plugin

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

In general, yes, but when I tried it, all free autorouters (and the paid one in Altium) failed to do the fan-out/escape of the ESP32's BGA.

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.

I really wonder why autorouters are so bad/slow still, I at least understand the high level concept of what it should be able to do, and I would think that with enough input parameters, this shouldn't be that hard of a problem to solve, especially with how easy it is to deploy tasks across lots of powerful machines for (relatively) cheap these days.

Not just routing, but from a cursory reading of atopile I can't see how they've even addressed floorplanning?

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.

Autorouting would for sure be a valuable tool to add to EEs toolchains. The reason we focused on the language first is because it is critical to provide high quality information to autorouter for them to do a good job. And achieving that with a schematic is tough, as it only captures part of the information required to doing a good job laying out the circuit. A bunch of information is currently implicit.

Part of the magic here would be to get your team's hardware engineers to adopt a more software development style workflow.

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.

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.

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!

Looks really useful! As a hardware designer I've had plenty of copy pasting bits of schematics to duplicate common functionality. Seems like this could be really helpful in preventing mistakes and increasing quality once used to it.

Have you got any plans for defined interfaces/modularity so devices using SPI, I²C, etc. can be chained together without manually defining pin connections? Also, will there be support for importing schematics from other formats?

We do have interfaces! They are super useful, I am very stoked that I dont have to remember which way around MISO/MOSI go any more.

Interfaces are just a collection of signals eg

  interface I2C:
    signal sda
    signal scl
    signal gnd

you can connect two together like so: micro.i2c ~ sensor.i2c

Importing schematics would be possible, but IMO not super valuable as all we could import would be the raw connectivity, a big benefit of our language is being able to add a layer of abstraction on that.

How does this handle connecting two microcontrollers with one being a SPI master and one being a slave? Or connecting UART between two devices?

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.

Kicad allows you to keep a library of projects containing layouts and schematics of small circuits that you may wish to reuse in other circuits by just simply importing them to the current design. You can then modify as needed.

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.

It reminds me of the Akka Graph DSL[1]

[1] https://doc.akka.io/docs/akka/current/stream/stream-graphs.h...

Interesting! Haven't come across it before but those linked `~>` operators do indeed quite familiar. If you're familiar with GraphDSL do you have some elements we should look into?

By reading some code here https://github.com/Timot05/logic-card/blob/main/elec/src/log...

I wonder if with directional arrows, instead of writing "out ~ switch.in; switch.out ~ power.gnd", we could write "out ~> switch ~> power.gnd" instead?

But without distinction between in and out ports it may not be possible to check if connections are valid ones.

Anyway, this project really makes me want to learn electronics! Congrats!

You're absolutely right! We've been thinking very similar ways about "dipole" components and how to best do this; and I think you've nailed it. What about using dunder __in__ and __out__ attributes? Easy enough to implement for us and overload for folks in the future.

I've only worked with Akka Graph DSL to build some data pipelines or protocol stacks. And I've loved working with it!

The equivalent of atopile signal would be port with Akka I think. A combination of ports gives us a shape. A source shape is just one OUT port. A flow shape is one IN and one OUT port, etc.

I'm very new to electronics so I don't know if it makes sense, but connecting all these ports with directional arrows was really helpful to understand the data flow.

Could you please explain the difference between Atopile and Jitx (https://www.jitx.com/)? Both seem to provide software-defined hardware development.

Our language is also a markup language more than a programing language. The goal here is that we would want the code to become a description of what the circuit is, instead of how to obtain it. The obtaining part is the job of the compiler. Not the human.

Please forgive me if you know this already, but just in case: the terms Declarative and Imperative may be useful here.

Declarative: the code describes the desired result.

Imperative: the code describes the operations to take.

Most programming languages are Imperative, but some are Declarative, and some allow a mix of the two. More here: https://www.educative.io/blog/declarative-vs-imperative-prog...

Thanks for sharing the docs! Our language is mostly declarative at the moment. There are some features we discussed that would be imperative and we might introduce them in future versions of the compiler.

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.

Why python? Why sink development effort into an obsolete and deeply flawed language?

Will not get into pros and cons of any language, but in what world python is obsolete?

In the world where the programming language theory kept developing, rather than being stuck in mid-80s.

Flawed? Sure, although every language has its flaws, some more than others. Deeply flawed? Not really. Obsolete? Lol, what. It's top 3 most popular languages.

Deeply flawed? Not really.

Python's performance problems are unfixable without wholesale redesign of the language and standard library. Its package management is a bad joke. The developers give no indication that they have any intention to fix those problems, rather than keep stuffing more unnecessary and badly thought-out features into it.

Obsolescence should be gauged by how modern the design of a language is, rather than its popularity. By that measure, Python is manifestly obsolete, and has been even when it debuted.

At the risk of sounding pretty negative to someone who wants to make the world of EDA better, this really seems like a re-discovery of a text netlist with the idea of making it 'easier' to create schematics but I feel like it's DOA for anything non-trivial.

Most PCB tools have the user create the schematics graphically, but the actual 'design' is usually a text netlist already or the tools let you export the netlist to an industry format such as EDIF.

SPICE netlists (for example) are also purely text-based, and while many of my EE professors could actually "think in SPICE" (i.e. go from a schematic of a circuit to directly writing in SPICE) for me and pretty much everyone else it was unbelivably painful to modify a SPICE netlist as you went from a simple inverter to something even "basic" as a two-transistor BJT current-mirror. You want to now copy+paste the design six times? Now you have 6x netlist re-naming fun.

One of the reasons why non-trivial schematics are done graphically is you can more easily grasp the intent of the design and make "complex" designs very clear. In my opinion, it's a reason why a well designed block diagram is worth 10x access to the "design" whether it's RTL or C -- you get an understanding WHY someone did something not just the what.

Example, you might put resistors in-series on a bus to provide termination (best done at the source/driver) ; what would that look like in this new text-based schematic language? What if I have series termination resistors on the bus, thevenin termination on the far-end and then a pull-down strapping resistor as well? The block of text will grow quickly without much clarity. I don't doubt it will be functional, but there will be no mental model of what this is supposed to look like, and further why all of these components are there. A well drawn schematic* will make this overt.

Another simple example might be a single-supply op-amp which usually has a few resistors to bias the signal correctly. It will easily end up being MANY lines of text and it won't all together be clear which lines of text associated with the op-amp correspond to an intent.

I have about 20-years of doings electronics, FPGAs, boards, C/C++, SoC architecture and DevOps with a formal education in both HW+SW. I could be an example of "the old guard" but in my career I've usually been the one to champion newer/smarter better tools and applicable domain-specific-languages so much so I pivoted my career in this very area for a number of years.

*Most schematics, and reference designs are a jumbled mess of wires and symbols. While highly subjective, a good schematic breaks logical function into symbols by function, groups related components intelligently and employs a good number of notes on the schematic.

We're largely on board with the same problem's we're trying to tackle, and I most certainly understand why you're making these criticisms of these trivial examples and our current implementation. You're right to - these simple designs aren't where designing PCBAs with code will shine (we expect!).

Currently when you discuss configuring a regulator, it's beholden upon the designer to understand enough of the internals to configure it because, in our opinion, schematics aren't well suited to designing things that are configurable and plastic - either in topological terms, or in their parameters. Our hope isn't to abstract this complexity directly by using code, but rather because code allows the workflow itself to change, for a well tested and trusted configurable block to completely abstract the internals such that a designer can forget about it (like a tested piece of code). We want to bring configurability on this "trusted" scale in from the physical world of modules to the world of highly descriptive code. It's a tall order, I'll indeed admit!

It's also well worth nothing that while at the moment we're running lean on the visualisations, we do agree they're an extremely potent tool to convey the topology of a design at a glance. We expect we'll be adding a visualiser which should be used to gain familiarity with a circuit, diff it for review and understand it from a system level (by viewing topology by interface type etc...) - unlike current schematics that implicitly hold so much content via the positioning of components.

Thanks for the detailed comment!

Glad you're open to feedback.

I don't know if your regulator response was directed at me or someone else, but using that as an example, if you take something like an LM7805/LM317 I think the 'parameterization' you're talking about (i.e. "input_voltage=12V", "output_voltage=3.3V", "accuracy=5%" --> let "tool" solve for resistors, and populate schematics/BOM) sounds cool and would work.

But what if it's something like this (a multi-phase step-down converter):

https://www.analog.com/media/en/technical-documentation/data...

While it's "annoying" that a designer might have to go study a datasheet to know which resistors to tweak or change what's worse is having a tool or 'abstraction' do it for you, with the potential that it changes significantly underneath you and you don't even know what it did or why.

This is the bane of a lot of EDA tools and more specifically why people rightfully now loathe a lot of FPGA vendor's tools that have things like "abstract IP blocks" configured from the GUI but in each new release of the tool, the underlying "generated" RTL (which comes from some byzantine invokation of scripts and a soup of options) might be different and completely breaks people's designs.

What happens if it's not re-programmable like an FPGA but something physical with resistors, capacitors and traces on a circuit board?

For sure! You've made two super important points; how can I trust it shuffling things under me and how can I justify trusting this thing if it's going in long-lead or production hardware (stuff that's hard to fix)

The first one is super interesting technically because there's a few routes by which engineers can gain trust in something, and in my experience code-generation often isn't the strongest of them. It's often the case that checking an answer is vastly easier than solving the problem in the first place. Our mid-term roadmap includes scripting tests (~pytest + SPICE in CI) and for a complex chip like that, I first expect that those params will tweak those tests, those tests will fail out of spec and the engineer needs to reconfigure it in that application while understanding the datasheet.

The next level is extremely similar, except the solver is selecting configuration component params based on cost-functions and rules, and this same test suite is validating the solution and providing the confidence needed to manufacture a prototype.

The final and important mechanism though is that you have a lockfile that lockdown the configuration of these discretes unless an engineer opens it up - yielding review as we'd have today.

The other half of this though - how can we confidently deploy this to production, is eased with the rigorous workflows software version control tools (github, gitlab) can enforce. If an engineer tweaks these params, you can use the tool to rigorously enforce review from the domain-specific-experts on the team. Currently, it's vastly too easy to slip something through (mostly unwittingly) in design review meetings, and these version control tools go a long way towards fixing that.

This is great! So many ways to improve upon the status quo approaches to circuit design -- notably allowing a single representation to be used for design through spice through layout.

For sure, its amazing how many places you need to write down basically the same information today. EDA tool, SPICE, requirements pages, documentation. SPICE is definitely an exciting one, particularly as the model can be versioned along with the package with parametrized tests that will automatically run in CI.

Exactly. A new level of modularity will be possible. Pretty incredible! Also parametric designs of modules (a function call with 3.3v vs 5v, or 8bit vs 12bit ADC) all the way down.

Yeah, that would be great. We currently don't compile down to spice but we hope to get there one day.

Absolutely love this, always wondered why there wasn’t a nocode for hardware that outputs a gerber.

always wondered why there wasn’t a nocode for hardware that outputs a gerber.

Because hardware tends to be informed by messy physical factors which are hard to represent programmatically.

Think along the lines of "the cables are coming from this side of the board", or "buttons need to be reachable by fingers", or "if you're building a weather station, the temperature sensor should be far away from components that generate heat".

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.

Thanks!

The Net-list stage of abstraction is the easy part, but auto-routing is not.

People have tried many times to build a universal router with physics awareness for decades. The issue is in the real world there are countless edge cases where the EE must make a decision on the layout.

For low speed digital design... routers have partially worked since the 90's, but for most other things the edge cases make it counter-productive to automate.

EEs are good people to have around, and some know how to build things reliably.

Have a wonderful day, and I really hope the project does well. =)

Agree, I wish them the best of luck — I’m not convinced a computer will ever beat me in the single-sided perf board niche, and I’m but an amateur, but I’d be happy if one did.

You might be right, dont think we will be tackling perf boards any time soon :D

For sure, we are starting with the schematic/requirements side of things and will push in the layout direction soon. We have started with some simple layout snippet reuse that is available today. My experience with autorouters is they do not have a good understanding of the problem, we hope to improve that by being able to capture more information about the circuit, for example physical values like voltage and current are captured today.

Our goal generally is to automate tasks that are boring/repetitive like multi-day reviews of big schematics to see if anything accidentally changed. Definitely building a lever for EEs, not a replacement.

Thanks!

Very neat, nice work.

I tooled around with a similar idea sometime back. There are clear advantages of code over graphical-schematics when it comes to automatic generation of component values / re-use of elements / speed of development / automatic SPICE testing / etc.

The primary issue I ran into was that: electronic circuits are inherently graph-structured and the traditional circuit schematic is well suited, optimal even, for displaying this kind of information. Trying to understand an analog circuit that is described as code seems awkward.

Yeah we did run into a similar issue. Someone designed a power supply and it wasn't immediately obvious how the elements of the circuit were hooked up in ato.

I think a viewer would be nice ultimately. But we haven't exactly figured out how the solution might look like. ideally something that allows you to create datasheet-like snapshots of part of your design?

A nebulous description of my ideal setup would be something like this:

Side-by-side schematic symbol view / code view that are actively synced to one-another in real-time. Schematic view allows basic arranging of parts, editing interconnects, triggering jump-to-reference within the code view, adding probe points for SPICE, displaying SPICE output graphs. Code side does all the heavy lifting like creating new parts, scripted behaviors, editing component values, all the cool shit that would be a nightmare to sort into a GUI.

Much easier said than done, of course.

Yeah the side by side thing makes sense. Especially for very low level or analog designs. But in some cases it wouldn't be desirable to show the whole circuit. Say you are dealing with a module that has been characterized and that you know works. In this case, using a language server or a linter that shows you available interfaces might be easier to use.

For the spice graphs, having a jupyter notebook-like interface would be great to document why your design looks the way it does.

If you have specific ideas or drawings of how this might look like, please send them over in our discord server :)

For context, I am very familiar with KiCAD and somewhat familiar with Eagle.

I think KiCAD gets a lot of things right. Some of the broken things:

parts management (There is no central repo, a la LVFS, where I can get a part/pinout/3d model to easily import)

export process (feels kludgey, although some manufactures take the native KiCAD files)

multiple users, same project -- it's hard to put artifacts into git and merge changes.

I see this solving the last issue, perhaps the second as well. Commercially, I think it is worth pursing the first.

Other thoughts:

When I spec parts for certain types of designs, I need a whole lot more than just tolerance. e.g, for a mlcc capacitor, I need to spec dielectric, voltage, tolerance, ESR, sometimes leakage. For resistors, inductors, and other jellybean parts, similar metrics apply. Specing active "common" parts (like bjt/fet, diodes, etc) has even more parameters to consider.

I would also love the ability to take a design and drop it into SPICE for simulation.

Also, is there any workflow option in current Kicad for importing a component-naming netlist (of the kind so many existing schematic packages can output), without having a live Kicad schematic?

One lesson of this thread could be: There is enough interest in text-based "schematics" -- aka netlist import -- for Kicad layout to add support for the approach, if it does not currently exist.

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!

export process (feels kludgey, although some manufactures take the native KiCAD files)

I fear a lot of this is due to manufacturers. There are quite a few variables in the file definition, and every manufacturer requires them to be set slightly different.

Having pre-baked per-manufacturer templates in a dropdown box would already be quite the improvement, though.

I think a compiler for PCBs is a great idea!

Are you fully open source today? How has the community aspect been going?

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!

I've been doing a lot of selling to enterprise recently - mostly US based. Let me know if I can be of support!

For sure, would be awesome to have a chat some time!

Congrats on the launch! Couple of quick questions: Are there any initiatives or resources planned for educational institutions to adopt atopile? Outside of GitHub, are there specific areas or tasks where you’re seeking community or volunteer contributions? Thanks!

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!

cool, i believe this is a scenario where targeted educational/univ. chats could help further enterprise trials (or early constructive feedback). would be great to chat more on discord/email!

This has sooo much promise, I can't describe how excited I am and will definitely be contributing if I can.

This would make it easy to implement a fancy optimizer. Each component tends to have certain acceptable thresholds for their dependencies like input voltages, current limits, external resistor/capacitor/inductor values/ratings, etc.

Then, each component could have different implementations. You can have different manufacturers produce the exact same inductor/capacitor/resistor in different packages. You can link it up to your existing BOM or hook into vendor APIs to get pricing.

Imagine optimizing for cost, removing redundancy, simplifying footprints, and prioritizing in-stock inventory over new order components.

This could be a huge deal, looking forward to its progress

We have been working on an optimizer for solving components that we will put a post out about soon. But the gist is figuring out which constraints are expensive, for example a precision inductor might be quite expensive, but a precision resistor is comparatively cheap. We can look at where to shift precision in your components to get the desired output for the lowest total cost. We already do a few things like prioritize in stock parts with high availability. I am excited to add more constraints, like board area, multi-sourcing etc.

That's awesome! We're definitely thinking along the same lines in terms of a lot of those optimisations / cost-functions.

Here's some of the basics Tim was playing with earlier: https://github.com/atopile/atopile/blob/d25686952534e0f96582...

This is an amazing concept.

You still need heavy EE understanding to know how to develop PCBs, so it’s not going to turn every software engineer into a PCB pro, but it could totally change the game for EEs that can learn to code.

This is definitely a step in the right direction though and I’m wondering how much of a PCB can be represented in an abstract syntax tree or something similar. Are there edge cases, or could you completely describe a PCB layout using code?

Definitely agree this isn't taking away EEs - anytime soon or ideally ever! The goal is to make EEs far more potent, rather than bring SWEs to hardware (although letting them easily tweak existing board's filter constants, vdivs etc... would be awesome too!)

We're honestly not sure how explicitly we want to describe a layout in code, or if it's a more declarative thing. Currently we're leaning more towards the declarative approach (eg. this trace carries 100mA of current) rather than the imperative (this trace is 0.150mm wide) since it should scale more intuitively with equations and layer better with DFM specs etc...

Have you got some ideas?

Treating it declaratively is what I initially thought it would be, but what happens when the user needs to tweak the layout for some unique requirement? My guess is what would happen is it would force them to completely eject from your declarative approach, similar to how if you build software on low-code tools, and need to tweak something, you typically have to completely eject. The low-code thing has no understanding to render your custom thing.

Idk maybe this can be solved, but seems problematic to describe layouts like SQL then rely on query planners to deliver the perfect execution.

LOVE IT LOVE IT LOVE IT!!!

I'm doing a lot of home automation work, and I absolutely hate that I need to use breadboards, hunt for pre-assembled components, or to spend days designing a PCB for simple things like relay modules with customized IO.

E.g. I have ratgdo for my garage door opener, but its power supply is an ugly buck convertor taped to the box. I'd love to just re-make the ratgdo board, but with a built-in 12V-to-3V buck convertor.

I tried that, but PCB manufacturing with custom component placing requires just too much work.

Is there a way to donate to the project? I'd love to support it.

That’s exactly what we are going for!

Have a look at packages.atopile.io. We have a package with power supplies that you can just add to your board with

  ato install regulators

https://gitlab.atopile.io/packages/regulators

Forgot to reply to the support aspect:

Best way to support us right now is to try the project and give feedback on where you'd like to see this going. The project is open source so feel free to raise issues or contribute as well :)

Fine tune an ai on the docs and you've got a new company of AI generated circuit boards

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.

So exciting, hope that happens! I'll be sure to keep an eye out

I like the idea in general, but I absolutly hate it when people invent their own weird programming language instead of using a well defined existing one... Why not just use Python?

Sir, this is Hacker News.

Great question! We hope we have a few good reasons.

This iteration of the project actually came after first working with and then modifying another awesome project called SKiDL (https://github.com/devbisme/skidl).

It's based on Python - but we found that since it's procedural, turing complete and has a rich eco-system - people use to that and there aren't standard composable ways of designing things. Instead of describing your board, you (practically) write a script that generates your board. It entangles your targets with your source-code and can make it difficult to understand the ultimate outcome of what you've written.

Additionally, since it's a potentially very long program, it was hard to write good language support around (a language server for VSCode, a schematic visualiser etc...) that were snappy, responsive and lent to examining modules as well as the whole program.

There's a few operators and first-class language features we wanted as well, like units and tolerances (3.3V +/- 100mV) that just aren't the same when embedded in a string, or class init method.

Why ato over existing hardware description languages or things like SPICE (and it's many derivatives)?

Great question! Current HDLs tend to primarily be focussed on digital circuit design, while at the PCBA level, there's a lot more focus on the "fuzziness" of the physical world (eg. tolerances).

We also noticed that most EEs we've worked with were a bit put off by the syntax and preferred something a bit more terse, but more intuitive and easier to read.

There perhaps an analog here in software - where we started with assembly (~ SPICE), moved up through things like C and now languages like Python and JavaScript are prolific and accessible.

For reference, I've designed ~10 PCBs of varying complexity (simple to highly complex) and done plenty of programming. I've used Eagle, KiCad, and Altium. My comments will try to push you to think about some specific points.

Looking at your demo video, it seems that atopile is less a "tool to build electronic circuit boards with code" and more a tool to perform schematic capture in code. Do you agree with that characterization?

I ask that question because you're clearly relying on the KiCad toolchain for PCB layout, which is a crucial part of the overall PCB design process but is not "PCB design" itself. Right now, KiCad is a tool for PCB design, and you are providing an alternative method of schematic capture. I think you should make sure that the description of your creation accurately reflects its capabilities.

Is anything preventing you from taking output from the existing KiCad schematic representation system and transpiling it into ato? What about transpiling from ato into the KiCad schematic representation system?

Does ato provide any focus on routing? It could be nice to state in software that I want a component or trace constrained to a specific layer on the PCB (or in the PCB, if there's internal layers). I'm assuming no, since ato appears to be purely focused on schematic capture, but I'm curious of your thoughts on this.

It could also be nice to include placement constraints in software. For example, say I have a handful of resistors which I want placed in the same relative area of a board and in an orderly row. Do you provide functionality to allow this? The general aesthetics of PCB layout might be programmatically defined with ato.

Just like Arduino took the nitty-gritty away from microcontroller programming, think about how you can take the nitty-gritty away from schematic capture. One way this could work is with a hierarchical schematic templating system. You'd need to build significant documentation to teach people how to use it, but it could vastly simplify the schematic capture process to a few lines of code by importing a template schematic class and instantiating multiple schematic objects into a project and wiring them together.

It makes sense to me that an "interface" as you define it can be imported for a given project. For example, "Bob's Interface" is the set of a +12V barrel-type power input, a USB-A port, a 3.5mm headphone jack, and a 10-pin GPIO header. Any project using "Bob's Interface" has a known set of input and output capabilities. The term "input/output complex" also gets at this idea. Is that how you think of an interface?

That's all for now. :)

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!

This is really cool, and love that it's open source. Congrats!

Thanks!

Nice project! Coming from computer science, I've been dabbling with electronics a bit. My path so far has been (sorry if I'm pointing the obvious):

0. computer science

1. arduino programming + very basic circuits

2. adding a few chips and talking to them through I2C/SPI: still in digital circuits territory, sending 1s and 0s

3. designing my frist PCBs with kiCAD: a huge learning step, and things start to get a bit messy (component tolerance, transmission delays ...)

4. looking at analog circuitry / alternative current / signal processing : a HUGE uncharted territory, full of promises and headaches.

This trajectory is probably quite common, and I'm sure atopile has a role to play there, when you start growing out of arduino. Making things a bit smoother, searchable, reusable, being able to learn from other people's design - what a wonderful tool it could be!

Thanks! And glad you are making your way towards electronics.

Yes, we hope for the packages.atopile.io to become a place where you can share your designs and explore what other people have built.

The final part of the demo shows the output of the automatic build as something you can upload directly to a PCB manufacturer. How does this work given the output of the compiler is a netlist, not a PCB layout or Gerber file?

There are actually two steps to the design process:

- First, requirements. In ato, you define how your circuit is connected and the requirements for the components that sit within it. From there, we generate a netlist and a BOM.

- Second, the netlist is turned into an actual object during the layout operation. We use KiCAD's layout tool in our case. There are infinitely more dimensions in the real world than there are instructions in a computer. So we do need that second step to point the requirement to one implementation in the real world. But technically there could be a quasi infinite implementations that fit the requirements written in ato.

The manufacturing files are a combination of the ato output files, like the BOM and the KiCAD output files, like the gerbers.

This is a great start, well done!

Eventually it would be amazing to import (for example) a buck converter circuit with a wide voltage input, fixed output suitable for RF, and have it automatically check available components at JLCPCB and then lay it all out with, adhering to best practices (ground planes & capacitors right next to pins etc.) If the available components change, it can tweak the footprints and layout without having to start from scratch.

Good luck, I’ll be following closely!

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.

First off - best of luck to y'all. The HW EDA space is sorely in need of tooling improvements. I'm curious as to how your product differs from JITX. They claim the same sort of thing - code based PCB development. And they've been around for a few years now.

Thanks!!

The open source aspect was really important to us. We are hoping that ato modules can become a convenient language for the community to share modules with each other, in a similar fashion to python and pypi.

Having an open code base also makes it more convenient for our users to chain tools together. This is currently hard to achieve with the existing close source standards we are dealing with in hardware.

ato is also a markup language (like markdown or latex) more than an actual programming language. We think this makes it more readable and helps guide the user writing code that compiles.

Finally I can just install some package and have a spec-compliant ESP32 circuit which I don't have to copy from somewhere else. This is great.

One small thing regarding the imports: If you plan to have some rich autocomplete functionality (which helps dicoverability of packages) it is better to have the source of something first and the imported stuff afterwards. Python - which you seem to draw inspiration from - does this as well:

    from xy import z

The editor can offer auto completions when the cursor is after "import ", which is not possible if it's the other way round: `import z from xy` (like it is in JS).

I'll try this out, it looks very promising!

Great point. We'll change that soon! Especially true for interfaces too since modules might have tons of accessible interfaces and the language server could list them out for you.

Did you see the ESP32 in the package registry? https://packages.atopile.io

Looks quite neat, but as other have pointed out I do not really see how this is different from traditional HDL languages such as verilog and VHDL. I say this because by looking a bit into atopile examples I only saw easy "digital" circuit stuff with GPIO and resistors, which are all things that can be implemented using FPGAs. However the most difficult things when designing advanced PCBs are EMC / EMI [1] problems with advanced subsystems such as an USB hub or analog filters. BOM generation and modular abstraction are already solved problems in industry (even though I hated every minute of working with Xilix Vivado) and tools like F4PGA [2] are slowling catching up.

If I may add my two cents, I think you should concentrate on making it possible to go beyond lumped element models (which can already be simulated using SPICE, etc) and simple abstraction (solved by VHDL & co) and focus on being able to offer advanced subsystems to less experienced PCB EDA users. Basically, to go for the Altium path, but without Altium. For example, it would be a killer feature if it were possible to import an FTDI USB chip module and a switching power supply module, and obtain a PCB that has a guarantees (up to a degree) that the two will not interfere with each other. Or say, have it automatically optimize a design to guarantee a certain SWR [3].

[1]: https://www.analog.com/media/en/training-seminars/tutorials/...

[2]: https://f4pga.org/

[3]: https://en.wikipedia.org/wiki/Standing_wave_ratio

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.

How technically possible is it to integrate this with KiCAD?

Super! So far that’s all we support for layout and we love that it’s also super-low-barrier to entry OSS.

Is this related to skidl https://github.com/devbisme/skidl ?

Hey,

We did use skidl for a little while as we were figuring things out (see a project here: https://gitlab.atopile.io/pew-pew-and-friends/sizzle-sack). But we later ended up moving away from it towards ato for mainly two reasons:

- Baking a description of a circuit into python describes how to obtain the circuit, but doesn't really describe what the circuit is. Skidl projects quickly become hard to read. The user is also not guided towards writing code that compiles since you need to deal with all the complexity of Python as well as the circuit itself. - Contributing to the project and adding features was non trivial

I think this will be well received in the personal keyboards community (I will like to see how to design the PBC for custom keyb!)

Oh yeah we did think about that. Would be cool to have an ato package for a keyboard! Or maybe a script that generates both the CAD (with OpenSCAD or similar) and the ato code would ne nice.

I agree some format to attach more metadata into schematics is useful, especially if enough good modules become easily available -- something as simple as "hey this is a 5V rated component" is nice not to have look up sometimes.

But to add to the wishlist of innovations in PCB layout; someone please give us better gerber editing/conversion tools. Geber strikes me as being very like pdf -- absolutely standard, well reproducible, but awful to edit in any way other than 'intended'.

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.

Would be good to see a comparison to Verilog

Pretty similar in concept, a few important nuances that come with building boards in the real world. For example dealing with tolerances. The language is definitely an important part of this, but we think alot of the surrounding infrastructure like package managers, CI pipelines and SPICE integration will be critical also.

It should produce a schematic as one of its output products.. maybe use graphviz, see:

https://observablehq.com/@nturley/netlistsvg-how-to-draw-a-b...

HDL tools all do this.

NetlistSVG is great yeah. We had a play with it. We had a visualizer in the compiler early on in the compiler implemented with JointJS. But it was a pain to maintain and difficult to get value out of.

I'm sure we will have some flavor of a visualizer in the compiler one day. But outputting a "normal" schematic doesn't seem like it's the right approach. We might actually end up with a bunch of different ways to "visualize" your circuit, each one optimized for a specific thing you are trying to achieve.

I saw your project at Open Sauce last year, happy to see the official release.

Thanks! Hope to see you there again this year!

Hi, EE here, but started my career as unskilled labor in a test lab. This is in contrast to my colleagues who are often physicists.

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.

Well designed schematics are great. Especially if you are sharing them with your team as documentation.

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

Hi Tim,

I'm just starting with electronics, following the Make Electronics book with my kid. And this seems super useful to understand circuits better (at least for people who code), do you have the plan to make a series of lessons for beginners with the app? Like going from the simple battery-led to complex things? Feel free to email.

Hey!

Really love that. My dad gave me a piece of wood with some basic components like LEDs, motors, resistors and light bulbs and a battery that I could connect those to and understand how they worked. Glad to see you are doing something similar :)

We do have a couple videos and certainly plan to make more: - Get started guide: https://youtu.be/7aeZLlA_VYA - ESP32 module: https://youtu.be/eMWRwZOajdQ - Logic gates kit: https://www.youtube.com/watch?v=hSeDv3QqRc0

We are also hoping for the package registry to become a place where you can get access to pre-designed modules to put together into a circuit: https://packages.atopile.io

Feel free to reach out per email or discord if you need help setting things up!

I'm curious if you have component checking - does the circuit overload the regulator? am I going to overvolt this capacitor? what is this LED's lifetime? - or if that's somewhere on the roadmap?

I'm also curious if you're able to use an autorouter to minimize board layers. Seems like it should be pretty straightforward to apply some graph theory to this and state the minimal number of layers for a given board, but this also might be NP-hard? I haven't kept up with the theory here.

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.

Reminds me of openscad - https://openscad.org/ but for circuits instead of shapes. Turning complex wysiwyg editor operations into reusable code is such an improvement, especially with the advent of usable LLMs to help with boilerplate.

I do agree. Though it is interesting to try figure out why openscad (and similar projects) haven't become more prominent in the industry. It feels like some aspects about code to hardware have to be tweaked for it to become the standard way to design.

Really cool project, now available in the AUR: https://aur.archlinux.org/packages/atopile

Honored to be there!

I think you should do one thing really well, before expanding.

Import from public GitHub libraries could be fun.

Differential pairs.

Impedance controlled traces.

Going further, if I have one supplier's stack up with controlled impedance lines, and I need to switch to a different supplier's stack up, what netclasses would change?

I do agree. The package registry (https://packages.atopile.io) is an attempt at importing from existing GitHub/GitLab ato projects. This will need quite a bit more polish until it gets to the level Rust's crates.io or python's pypi.org

On the language side there are additional features we would like to work on like traits and types (types would include diff pairs and impedance).

Could you imagine the pain of building an entire software product using only assembly code? That’s about how we felt designing hardware.

I've done both. What you called "pain" I called "fun". I started life as an electronic engineer but am now a software engineer and was very comfortable in both areas--including building from the TTL level. So I'm automatically suspicious of anything that calls such things painful.

My kneejerk reaction is "you've never done this professionally" but it's 3am where I'm at and can't watch the video right now.

Pain might not have been the right word indeed. The aspect we wanted to point to was rather the fact that we had to do it over and over again. And so from that perspective it became a “pain”.

Ultimately we do love electronics. This is one of our attempts to contribute back to the field.

This looks really cool. I need to dig through some more examples before I'd take anything I say without a massive grain of salt. :)

Maybe I've been writing too much React and Android Compose UI lately, but instead of a declarative structure, have you considered a functional structure? That seems to be a create way to build composable components and add enough programmability (e.g. loops, conditionals) and keep a nice one-way flow down the line.

Something like

``` import {Resistor, Signal, Ohms, Float} ...

def VoltageDivider(totalR: Ohms, ratio: Float, signal1: Signal, signal2: Signal, signalOut: Signal) { r1 = Resistor(totalR/ratio, signal1, signalOut) r2 = Resistor(totalR(1-ratio),signal2,signalOut) }

def MyBoard() { s1 = Signal() s2 = Signal() s3 = Signal() div1 = VoltageDivider(totalR: 100_000, ratio:.33, signal1: s1, signal2: s2, signalOut: s3)

}

It's similar to what you have but maybe a bit more of a programming language than a declarative format. The trade-off is that tooling support gets harder as you add some basic language features, but the upside is a more powerful language.

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.

IMO it's hard to spot the "holes" for parameters in a module - for instance, in the logic-card project the instantiations of "LDOReg" end up setting values of objects in "Vdiv" two abstraction layers down.

https://github.com/Timot05/logic-card/blob/a63581636233dd1f9...

You're right. It definitely is currently.

This is a hole we're planning to fill between linters and a language server. Picture a red-underline under an instance which is insufficiently configured, for example

this is pretty cool

Thanks!

Could it be on a plain slate

Sorry, not quite sure what you’re asking. Mind rephrasing?

Congratulations on the launch and good luck building a business around it! I remember running into you folks at OpenSauce last year and thinking just how useful it could be.

Thanks for the support! We will try get a booth at open sauce again this year. Hope to see you there :)

This reminds me of writing VHDL in the Sigasi IDE. You could write the description for a component, have it's syntax checked and get autocomplete while typing and once you were done, you could click a button and see an overview of your component and how its signals were connected to other components, kind of like a schematic. It helped me learn and find bugs quickly and I was really missing that when I got started with KiCAD.

I am very excited to use this!

My optimal workflow would be, to use code for describing the netlist using components, then use a combination of graphical and code editor to layout the PCB, like how the UI editor in Android studio used to work. (I don't know if it still works this way) I'd love to layout my components using UI like in the CAD program "Onshape", which let's you set your constraints visually and the program visualizes conflicting constraints.

I would love to start working on a project in code and then make an export into KiCAD to make final changes and send it off. Then, as the project gets further along, the point where I would switch to KiCAD would gradually shift further and further towards production. If I see this correctly, you are already aiming for that and I commend you for that approach :)

Thank you!! That's just about the workflow as where we lie today - albeit without the full suite of potency we're working towards.

I haven't actually used Onshape, so I'm not intimately familiar with their constraints system. Thank you for the recommendation, I'll have to check it out for some hints.

Really love this idea! I will give it a try. I have seen code to circuit before but this seems like it has potential.

Thanks mate!

Okay here is a wish list:

Chip fan out modules. A repo of all popular chips with traces to pins fanned out and variations (Chip XXXX, Fanout A, Fanout B, Fanout C, Compact Fanout D etc) Ideally the fanout modules should have required decoupling caps etc placed compactly).

Accommodate provision for chips such as i.MX 6ULL, the have so many pins that writing connection code would be daunting, maybe have pin groups and groups wired to groups syntax.

Provisions for chips where pins can be configured.

A repo of supporting circuits/modules like clock, clock distribution, PMIC / Power modules etc.

A CPU for example module should come with a list of compatible auxiliary modules such as a suitable PMIC/Power module.

The user will have to wire the relevant pin groups from module to module.

Lot of good stuff! We're working on some updates to the package manager now that should make a lot of that super tenable to build out.

Okay here is a feature that I'd like to see.

This has a VS Code extension, but I don't use VS Code, I like to use other editors like Kate.

Having a LSP Server and xml for syntax would be a great feature.

You're not the first person to ask for alternative syntax highlighting! Might be something we need to address soon.

I think an LSP server is what we're really excited about, since it also means we can provide far richer autocomplete and inline docs as we go too.

Designing circuit boards is not than describing a collection of electronic components and how each component's pins are connected together.

For circuit board design we are missing * PCB layer management

* copper dimensioning

* track management

* Design rules management

* many others....

At best, I would describe this tool as a vim for schematic capture in its current iteration.

One question to the founders, what are the real pain points for you that atopile are relieving?

Could you imagine the pain of building an entire software product using only assembly code?

Speaking of it, THIS would be a killer product.

A program gets compiled down to x86/x64 assembly, and you take that LL file and generate an FPGA from it.

Of course there's a lot of limitations in regards to OS APIs, but those could be represented with an SDK (e.g. a network socket API that is compatible with linux's headers and leads to a NIC being controlled with a firmware replacement).

Great concept, I have used KICAD to design in the past, some of the problems I have had as an amateur are: 1) Selecting the right components, are they available, standard size, surface mount or leaded? 2) Single or double side? Vias can be used to hop tracks

I will try out your sw and give feedback.

Oh nice, I made a really half-assed attempt with Kicad and python. This looks so much nicer.

It seems to me that this approach could make PCB design more approachable to blind people, as it's based on text rather than a visual UI. There are already blind electrical engineers and makers [1], but I don't know how they design PCBs.

[1]: https://nfb.org/sites/default/files/images/nfb/publications/...

very interesting. hope you can improve the tedious hardware design process. you might want to look into digital hardware description languages such as verilog and vhdl.

Is there a reason for a new language? As opposed to a python library?

We would love to have your thoughts on the compiler!

First thought. Where is the language definition for users?

Welcome to the arena, Tim!

I love the project. what's your thoughts on this syntax?

class Blinky

  microcontroller @mc(RP2040Kit)
  led-indicator @led.blue
    .input(&.microcontroller.gpio13)
    .gnd(&.microcontroller.power.gnd)
    .resistor.value(100, 10%)

  voltage-regulator @regulator(Reg3V3)
    .power-out(&.microcontroller.power)

  usb-c-connector @usbc
    .power(&.voltage-regulator.power-in)

Hey everyone, if you want to see a complete project, please check out the Spin Servo Drive that Narayan designed: https://github.com/atopile/spin-servo-drive

It can be a good example of how to setup an ato project.