lowRISC® was created with a mission to help make open-source silicon designs a reality, commercially relevant, and widely adopted throughout the industry. As a non-profit community interest company, lowRISC carries out this mission with the ultimate aim of benefiting the open-source hardware community generally. We aim to bring to semiconductors the enormous benefits that open-source already provides to software: transparency, reuse and collaboration.
This article explores in detail some of the differences between open-source software and hardware, and how the process of running open-source projects needs to be modified to make it suitable for silicon projects. We call this process the Silicon Commons®.
What we mean by open silicon
There is no single definition of open-source, but many different implementations: from software companies who make their source code visible only for evaluation purposes, to projects licensed under a GNU Public License (GPL), which forces users of the code to open-source the software it gets integrated with.
Our vision for open silicon is one that provides maximum value to the industry, and therefore maximum overall benefit for everyone with an interest in high-quality, secure software and hardware. We believe this is best achieved through code provided under the business friendly licence Apache 2.0. This licence permits very wide access to the IP and flexibility in its use, while placing minimal obligations on the users.
We believe that in the future most SoCs will incorporate a mixture of open-source and proprietary IP components. Even SoCs based on OpenTitan®, which is a “complete” root of trust SoC design, have to incorporate proprietary closed source IP from the silicon vendors (e.g. sensor top) and the foundry (e.g. memory macros).
Control systems
The range of control systems for open-source software projects is even broader than the range of licensing options. These control systems have evolved to suit the needs of the projects’ stakeholders, such as the creators of the code and their user base.
Some projects like GCC, LLVM and Python have a strong community-based approach where technical experts make design decisions. Other projects like Android and HuggingFace are tightly controlled by a single organisation. Finally, projects like OpenCV and Linux itself are controlled by a single individual who created its first implementation.
Note that despite their different control systems, all these projects are highly successful in terms of adoption, delivering the vision of their creators and value for users.
When choosing the right control system for open silicon, having a distributed group of individuals running the project is not likely to work, at least not today. The primary reason is cost: designing commercial quality IP is orders of magnitude more expensive than commercial quality software, driven by the cost of EDA tools, servers to run extensive verification, and masks to fabricate the design in actual silicon. The “activation energy” required to kick start a hardware project is vastly greater than in software.
In addition, the need for confidential processes to carry out certification means that in many markets open silicon projects have an unavoidable confidential component that cannot readily be managed by a distributed group of individuals operating entirely on open platforms.
Finally, the entities funding open silicon projects need to commit tens of millions of dollars in their success, and in return they want some control. As a result we are much more likely to see hardware projects controlled by one or a small number of corporations.
Governance systems
Fortunately, there has been a lot of standardization in governance systems for open-source software projects, with the inclusion of copyright headers and contributor license agreements (CLAs) that protect the project and its users.
These governance systems need to be strengthened even further in the case of open silicon projects. The primary reason in this case is risk: it is prohibitively expensive to update hardware in the field. If for whatever reason some patent-protected IP made its way into production hardware, the silicon vendors and/or the product manufacturers could be sued and run the risk of paying compensation. Even this risk can disrupt hardware roll-outs and disincentivise silicon vendors from using ungoverned open-source silicon.
The way we strengthen the governance systems in projects like OpenTitan is not only by forcing the acceptance of a CLA for each submission and use of the correct copyright in submissions, but also by only accepting contributions from verified and governed sources, namely:
- Individuals who are working for a project member, which signed a membership agreement with the project host organisation, requiring such contributions to be made under the terms of a Corporate CLA
- Exceptionally, individuals who are not working for a commercial organization, but only after having signed an Individual CLA
Employers, as part of their membership agreement, take full responsibility for ensuring the contributions from their employees are under the terms of the Corporate CLA, reducing the risk to the users of the IP.
This system of governance, implemented in a transparent way under the supervision of a neutral and expert host organisation, gives industry partners the confidence to take up the benefits of open silicon and academic partners the confidence to collaborate.
Engineering systems
RTL is code, and the systems created to enable many software developers from multiple organizations to collaborate on their code work well for hardware projects. Therefore, we have leveraged many of their ideas in our engineering systems: coding standards, requests for comments (RFCs), pull requests (PRs), committer roles and so on. You can see them in continual use in the OpenTitan GitHub repository.
An important aspect of the contribution process is how to guarantee the quality of contributions. This is achieved through multiple, transparent safeguards: a solid verification system; a process involving code reviews and committer approval for contributions; and a governance process for the take-on of project partners and the allocation of committer, contributor and other roles on the project.
In this case, the main barrier to adoption is one of skill and experience. The practices above are unfamiliar and not as widely deployed in silicon projects as in software ones. Many chip design companies still follow traditional “waterfall” development processes, and there are (comparatively) very few open silicon projects.
As a result, we have to put extra effort at the start of the project in onboarding contributors, and creating design guidelines, training, documentation, and infrastructure elements such as continuous integration (CI) and regression testing frameworks.
Silicon Commons
lowRISC developed the Silicon Commons methodology together with its partners and contributors, as an adaptation of open-source software principles to silicon development. It has been implemented successfully in the OpenTitan project.
Silicon Commons emphasises collaborative governance, rigorous design verification and use of industry-standard tools. This is done through design guidelines, training and documentation, engineering infrastructure elements and a rigorous governance process.
Our approach has facilitated the growth of commits in OpenTitan from 2,500 at launch to over 20,000 today, with contributions from industry, academia and lowRISC’s engineering team. More importantly, it got the Earl Grey discrete SoC design through all its development stages, into final validation and deployment in commercial products.
Our experience in the creation and application of the Silicon Commons methodology puts lowRISC at the forefront of open silicon development and in an ideal position to steward new open-source projects.