How do folks develop PCBs, firmware, host-software, maybe even ASICs and track versions of each? Can these various components be effectively tracked in a single repository? Specifically:<p>The timelines for design cycles vary greatly – it can range from mere minutes for host software changes, builds, and tests, to hours for FPGA synthesis, and days to weeks for PCBs. ASIC development can span months to years.<p>Artifacts: in software we have mostly text (we can diff), we can build quickly or cache builds or run incremental builds; none of that works in the physical world. Is it advisable to check in a mechanical or electrical engineering design project into a git repository?<p>What do folks do, what is your experience, what works, what does not?
The software/firmware/hardware stack is layered. Here's what has worked for me, for several FPGA-based instrumentation applications.<p>* Integration level: this is typically Yocto or Buildroot. It's architected to want its own repository, and should diverge from "upstream" repositories as little as possible (except for, basically, whatever configuration files tailor the build to your application.)<p>* Hardware design (PCB tools): Altium, at least, comes with its own Git integration and wants to control the entire repository. I have kept PCB designs separate from other SCM tooling and haven't found it to be too problematic. I think KiCAD is the only tool where I'd even consider combining the schematic/PCB with other stuff, since it uses a text-oriented storage format and doesn't try to micro-manage the SCM flow.<p>* Firmware (software and RTL) that's closest to the hardware/software design boundary: I really <i>do</i> want these to live in the same repository, so that it's easy to make changes that span the hardware/software divide. I would also argue that corresponding detailed design documentation lives here, too, since it incentivises documents to be maintained like source code, rather than as a grudging afterthought. Only source code is checked in (no build artifacts, no binaries - these would be a constant source of merge conflicts otherwise.)<p>* User-facing interface code: for me, this is a Python API and access to pre-built firmware releases. These live in a single git repository for user convenience. Firmware images are kept using git-lfs (and are --excluded by default .lfsconfig to keep new clones reasonable.) This has worked very well.
> none of that works in the physical world<p>Are you sure? The most common way to specify hardware these days is with a hardware description language, and the usual programming language tools like diff work for that. I'd personally be loathe to work any other way.<p>I won't give an answer either way as to your grouping question, just some things to consider:<p>Do you have a well-defined spec such that the two could work in isolation and finally merge the software and hardware at the end -- likely successfully? Then you should consider separating them completely.<p>As a general rule, the software that "goes with" the hardware should be in the hardware repository. That would include stuff like test frameworks of the HDL code, any tools or code used to generate further HDL code, as well as probably the on-chip firmwares (though sometimes I see those separated out). Stuff that would help you test and debug the chip as you develop it, should probably be in the chip repository.<p>I'd note that in a very big design it's not uncommon for different parts of the final IC to be developed in relative isolation from each other (possibly in different repositories); see my first point about whether there are well-defined interfaces.
I've used a few different ways to track hardware files (specific to ECAD, Electrical CAD files)<p>- SVN is actually pretty good! It has a central server where a user can check out files, change them, check them back in. It makes sense for things that can't be merged like software text files<p>- Git, alongside all the other software. This can work for some types of hardware files like libraries which are giant XML files in some ECAD programs, but good luck resolving merge conflicts!<p>- There are some dedicated file management solutions out there from the big companies. I don't have much experience with those outside of mechanical design ones.