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

[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

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

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