[Timot05]

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.

[robomartin]

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.

[Timot05]

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.

[mawildoer]

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

[robomartin]

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.

[vrinsd]

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.

[mawildoer]

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.

[robomartin]

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.

[mattclarkdotnet]

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

[robomartin]

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

[tcherasaro]

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.

[Timot05]

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.

[epcoa]

> 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

[robomartin]

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