Maintaining the Clash compiler: what it takes to keep an open-source HDL alive
Reading time: 5 minutes
Software is never ‘done’. Many people underestimate what it takes to maintain a tool like the Clash compiler.
The reality is that a living, actively used piece of software requires continuous attention: bugs need fixing, dependencies need upgrading, and users keep discovering new ways to push the boundaries of what the tool can do.
For us, maintaining Clash is not a side project. It is foundational to who we are, since the company was built around the compiler. Clash emerged from academic research at the University of Twente and QBayLogic was founded to keep the technology alive, improve it, and put it to work in real-world FPGA projects.
Clash is the open-source FPGA compiler, co-created and maintained by QBayLogic.
A never-ending laundry list
Software maintenance is a broad term that covers several distinct activities. First, there are always bugs to fix, often edge cases that surface when someone uses Clash for a type of circuit that hasn’t been tried before. There is always the need to keep up with the Haskell ecosystem, particularly GHC (the Glasgow Haskell Compiler), which Clash depends on. Falling behind on GHC versions would leave users stuck with outdated tooling, so staying current is important. And then there is the list of feature requests from the community.
Bugs in Clash typically fall into two categories.
- The first is new issues: edge cases that nobody has encountered before.
- The second is regressions: situations where a fix for one problem inadvertently breaks something else. Clash has a large and complex codebase, and it is simply not possible to keep track of every interaction between its components when making a change.
To guard against these regressions, we maintain a comprehensive test suite. Every bug fix comes with a corresponding regression test, ensuring that once a problem is solved, it stays solved. This suite grows continuously and forms the backbone of our quality assurance for Clash.
The downstream challenge
One of the less obvious aspects of compiler maintenance is dealing with downstream tools. Clash generates VHDL and Verilog code, which is then fed into vendor tools like Xilinx Vivado and Intel Quartus or the open-source tool Yosys. An improvement to Clash can sometimes produce output that triggers a bug in one of these downstream tools.
This is not our fault, strictly speaking, but it is very much our problem when it happens. So, we find workarounds. Sometimes that means adding configuration options that let engineers selectively disable new features to maintain compatibility with a specific vendor tool.
A small team on a big mission
Six people currently work on Clash, led by Rowan Goemans, though none of them full-time (the total effort adds up to roughly 1.5 FTE). But the work is not limited to the code. Significant effort goes into community support: answering questions, writing documentation, creating tutorials, and helping new users get started with Clash.
Everything we create is open source and goes straight to the community. We fund this work through a combination of mechanisms: 5% of the revenue from QBayLogic projects that use Clash is allocated to the Clash team, along with 5% of company profits. When government funding is available, such as the NLnet grant we recently secured, we apply for that too.
This might sound like a costly commitment, but the alternative would be much more expensive.
If we didn’t maintain Clash, we would need to use commercial tools instead. A set of MATLAB licenses for the entire team, for example, would cost thousands of euros per year. And that doesn’t even account for the proprietary hardware description tools we would need. Building and maintaining our own tool saves us money and gives us capabilities that off-the-shelf tools simply don’t offer.
The value of community
Clash has an active community of users around the world. We receive pull requests roughly once or twice a month, but code contributions are only part of the picture. The most common, and arguably most valuable, form of contribution is the bug report. A good bug report can be a lot of work for the person filing it. They encounter a problem in a large project and then spend considerable time isolating it, stripping away everything unrelated until they have a minimal, reproducible example that clearly shows what’s going wrong. Sometimes, this work accounts for more than half the effort of fixing the bug. We have had cases where a user’s carefully prepared report enabled us to implement a fix in minutes.
We also actively seek input from the community on feature requests. In a recent survey across our community channels, we asked users about their biggest pain points. The result was telling: the most common request was for new features, not bug fixes. That says something about the current stability of the software.
What’s coming next
Speaking of new features: two notable ones are currently in development.
- The first is funded through the NLnet grant and focuses on integration. There is a large body of existing open-source IP cores – CPU cores, JPEG encoders, Ethernet components – written in VHDL or Verilog. Currently, integrating these with a Clash design requires significant manual effort. The NLnet project aims to automate this process, making it straightforward to incorporate existing components into a Clash-based design.
- The second is a new mechanism for safe numerical type conversions. In hardware design, converting between different numerical types (say, from a signed integer to an unsigned one) can introduce subtle bugs. A negative value converted to an unsigned type, for example, produces a meaningless result. Previously, Clash would silently allow such conversions, leaving engineers to discover the problem during simulation.
The new feature catches these issues at compile time. The compiler can now tell you whether a conversion is safe before you ever run a simulation. And for the cases where you know a conversion is fine despite the compiler’s concern, you can explicitly override the check: safety by default, flexibility where you need it.
Built by the people who use it
Clash is maintained by the same engineers who use it daily to design FPGA solutions for clients. Every bug we fix, every feature we add, and every improvement we make to the documentation is informed by practical experience. That feedback loop, from client project to compiler improvement and back, is what keeps Clash sharp and what makes our FPGA design process so robust.
- Learn more about the Clash compiler here: https://clash-lang.org/
- Find the GitHub repo here: https://github.com/clash-lang/clash-compiler
Frequently asked questions about the Clash compiler
Who maintains the Clash compiler?
Six people currently work on Clash, led by Rowan Goemans, none of them full-time, adding up to roughly 1.5 FTE. They are the same engineers who use Clash daily to design FPGA solutions for clients. The Clash compiler emerged from academic research at the University of Twente, and QBayLogic was founded to keep the technology alive, improve it and put it to work in real-world FPGA projects. More about the creators of Clash.
How is Clash development funded?
Through a combination of mechanisms. QBayLogic allocates 5% of the revenue from projects that use Clash to the Clash team, along with 5% of company profits, and applies for government funding such as the NLnet grant when it is available. The alternative would cost more: without Clash the team would need commercial tools, and a set of MATLAB licenses alone runs to thousands of euros per year.
What is the most useful way to contribute to Clash?
A good bug report is the best way to contribute to the Clash compiler. Pull requests arrive roughly once or twice a month, but the most common and arguably most valuable contribution is a clear report with a minimal, reproducible example. Isolating a problem out of a large project can account for more than half the effort of fixing the bug, and a carefully prepared report has enabled fixes in minutes.
