You have to understand the ASIC or FPGA design flow to understand why that doesn&#x27;t make sense. For some reason, I struggled to find a Google result explaining it without being a tutorial on specific EDA tools. This one from IBM mentions many details, though:<p><a href="http:&#x2F;&#x2F;citeseerx.ist.psu.edu&#x2F;viewdoc&#x2F;download?doi=10.1.1.92.8110&amp;rep=rep1&amp;type=pdf" rel="nofollow">http:&#x2F;&#x2F;citeseerx.ist.psu.edu&#x2F;viewdoc&#x2F;download?doi=10.1.1.92....</a><p>The analog components were largely hand-made by pro&#x27;s, simulated, and then prototyped. Today, there&#x27;s lots of so-called mixed-signal blocks that combine analog and digital with extra complications:<p><a href="https:&#x2F;&#x2F;www.cadence.com&#x2F;rl&#x2F;Resources&#x2F;conference_papers&#x2F;1.5%20BeckerJ%20Imtek.pdf" rel="nofollow">https:&#x2F;&#x2F;www.cadence.com&#x2F;rl&#x2F;Resources&#x2F;conference_papers&#x2F;1.5%2...</a><p>So, I&#x27;m focusing on digital design with pre-made analog blocks at interfaces and minimal integration work. Getting to the rest with OSS will be... an uphill battle on top of an uphill battle. For now, we actually can use something like Qflow at least for larger nodes:<p><a href="http:&#x2F;&#x2F;opencircuitdesign.com&#x2F;qflow&#x2F;" rel="nofollow">http:&#x2F;&#x2F;opencircuitdesign.com&#x2F;qflow&#x2F;</a><p>Still need standard, cell libraries for the target process. There&#x27;s an open set or two...<p><a href="http:&#x2F;&#x2F;www.vlsitechnology.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.vlsitechnology.org&#x2F;</a><p>...but best is to have pro&#x27;s (or top academics) to straight up design a set for you for specific nodes then open-source it once silicon-proven. Need common analog components which pro&#x27;s will have to do, as well. Need to integrate the digital and analog logic plus make sure whole chip is working. Gotta do the design rule checks to make sure physical properties of each layer or between them is right.<p>There&#x27;s a lot to it. I have one or more academic papers for almost every step in synthesis, re-synthesis, formal verification, gate-level testing... you name it. Plenty for FOSS-loving academics to build on and integrate. That will take time.<p>Meanwhile, my main recommendation is to finalize an open-source FPGA w&#x2F; plenty of I&#x2F;O interfaces on advanced process node like 45nm. Then, target ABC synthesis and&#x2F;or VPR to it. Let&#x27;s us get open hardware while ignoring a large part of the design process. Archipelago FPGA&#x27;s are already quite a ways there:<p><a href="http:&#x2F;&#x2F;www.eecs.berkeley.edu&#x2F;Pubs&#x2F;TechRpts&#x2F;2014&#x2F;EECS-2014-43.pdf" rel="nofollow">http:&#x2F;&#x2F;www.eecs.berkeley.edu&#x2F;Pubs&#x2F;TechRpts&#x2F;2014&#x2F;EECS-2014-43...</a><p>Can create a metal-programmed S-ASIC that matches it for easier porting. If it takes off, do one for 28nm. Those should cover most use-cases with standard cell model for others.<p>Personally, though, I think there will be a mix of proprietary and FOSS tools. Best model is getting vendors to make theirs verifiable by FOSS tools so we can ignore the complexity of <i>how</i> they do it to focus on <i>what</i> they did and its equivalence&#x2F;correctness. Especially good to get a smaller vendor like Mentor Graphics on it as a differentiator in post-Snowden market. They keep secret sauce while we get verification. Win, win.