This thread is close. It's about as commercially close to a fully open workstation as one can get, but the problem is that MilkV boards still are NOT fully open and use proprietary DDR controllers, PHYs, analog IP and often closed RTL blocks. Even though they use RISC-V the system-on-chip is still partially closed. It's open source, but not "libre". Libre would be either 1. Croc / HyperCroc (MCU-class, VERY close to Arduino replacement), 2. Basilisk (Linux-capable open SoC) or 3. MPW shuttle chips (lots of small open RISC-V designs). See links below:
https://arxiv.org/abs/2502.05090
https://arxiv.org/abs/2603.12308
https://arxiv.org/abs/2505.10060
https://www.marketscreener.com/news/latest/First-Google-Sponsored-MPW-Shuttle-Launched-at-SkyWater-with-40-Open-Source-Community-Submitted-Desi-32894981/
https://acorn-research.usc.edu/chip-gallery/
These chips are the closest to a fully libre SoC in 2026 because they're based off the SkyWater 130nm PDK (SKY130) even though those are older nodes. Will need OpenRAM, keep memory sizes small and simple (no deep cache hierarchies), prefer single-port SRAM over complex variants, lower clock speeds (easier timing closure) and wider buses instead of deeper memory. The problem? PLLs, ADCs, PHYs are hard analog problems, require process-specific tuning and deep expertise and real solutions.
Option A — Avoid it (most effective)
Design like this: external crystal oscillator (no PLL), UART/SPI instead of USB/PCIe
On-chip SRAM only (no DDR) and no high-speed IO. This is exactly how Croc/Basilisk stay open. More area, less optimization. Or Option B — Use emerging open analog
ALIGN (DARPA-funded) w/ Open SKY130 analog libraries. Reality? Still immature and not production-grade for complex IP.
Even with an open PDK, the fab (e.g. SkyWater Technology) uses proprietary equipment + calibration. What you can do? Well, you cannot fully fix this today. But you can use only open PDK layers and rules, avoid any NDA-only features and stick to reproducible flows (OpenLane/OpenROAD). This gives you design reproducibility, not manufacturing transparency. But this part doesn't matter anyways because it just deals with the fabrication equipment, not the chip itself.
The next problem is wire bonding, packaging, testing = industrial black box. Practical mitigation includes minimalist packaging, use simple packages (QFN, DIP if available), avoid advanced packaging (BGA, SiP), community transparency, publish pinouts and test procedures, and document expected electrical behavior. You still rely on industry, but reduce complexity. Or you can use DIY chip-on-board (COB) / Direct die bonding. Very hard, but philosophically “more open”. Run your own flow w/ OpenLane ran locally. It gives you full control over synthesis, place & route and verification. You only use the shuttle for fabrication, not design. The problem: MPW runs give limited silicon data and no deep reliability modeling. What you can do: open characterization, publish test results, failure cases, voltage/frequency curves, build community datasets, multiple runs across designs and aggregate data publicly. This is a social + engineering problem. Not really an OPSEC problem.
Design for robustness, conservative timing margins, simpler logic and lower frequencies. Minimize dependencies, boot from ROM, use serial instead of USB and use simple linear regulators and that's it. You're set.
