(no title)
tcherasaro | 2 years ago
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|2 years ago
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|2 years ago
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|2 years ago
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.