Over the past years there has been a revolution in open source silicon. While there have been open source IP cores and open source chip design tooling available for at least 25 years, a lot of this has been disparate efforts. What we see now is that many of these projects are coming together as a tour de force creating a snowball effect of generating more projects and innovations being built from these earlier efforts. As I mentioned in my 2020 retrospective, we finally reached an important milestone last year where it’s now possible to create an ASIC using only open source code and tools. And within the limitations of the tools and technology this works just fine for one-off designs. Scaling this up has been a problem however. We see the same tasks being manually repeated and RTL files being copied over and over again instead of focusing on making more exciting end products.
A big part of this has been the lack of tooling to make it easier to use and reuse existing designs. If we had been developing a software project we would just had used pip, apt, npm, cargo or similar to bring in the bits and pieces in the form of packages that already exist and focus on our core functionality of the project.
And similarly if we are developing a complex FPGA product we would use FuseSoC, the award-winning package manager for IP cores, to quickly bring in pre-existing IP cores to the design we're working on and send the whole design to your simulator or FPGA toolchain of choice, allowing us to just care about the parts of the design that does not already exist.
Wouldn't it be nice if we could have that for ASIC implementations as well? The good news is that we are almost there.
Aided by funding from the NLNet NGI0 PET fund, Qamcom is now extending Edalize with a new backend for ASIC implementations, starting with the OpenLANE flow. The work is being done primarily by Klas Nordmark and me (Olof Kindgren)
 |
| Edalize+ASIC=Edalasic...or maybe not |
The overarching goal of the project is to allow users to quickly onboard their existing FuseSoC-enabled designs to the OpenLANE flow by just adding a bit of OpenLANE-specific information to the core description file, run FuseSoC and get a GDSII file, making it just as easy as it already is to create an FPGA bitstream or a simulation model.
 |
The FuseSoC+Edalize flow in all its glory |
To further aid users starting out their ASIC journey, we have started developing a reference project called subservient, which is a small SoC based on the award-winning SERV, the world's smallest RISC-V CPU. The subservient SoC can be found here.
 |
| subservient: The pocket-sized RISC-V SoC for your every need |
We are also working on adding FuseSoC support for the OpenLANE examples and would also like to see support in... well, pretty much everything. And here's where you come in my dear readers. As has been the case from day one of FuseSoC development, it’s important to test the flow on as many different designs made by as many different people as possible to make sure to not build in any assumptions we might make from our own designs. So please take your designs through the FuseSoC flow and let us know how it went. If not for our sake, but to see yourself how many gates and how fast your design would be in an ASIC, and make a pretty GDSII file that you can show friends and family. That's one part that I have looking forward to see for my own designs
 |
| subservient SoC in SkyWater's 130nm process: The Mona Lisa of GDSII files |
Being an open source project with a strong focus on collaboration, perhaps the most important question would be, How can I get involved?
First of all, whether you have some opinions, want to hear how things are going, have questions, need help or just want to be a fly on the wall you can find us in the Edalize chat room
Trying out the reference flows is valuable to make us understand where documentation or implementation is currently lacking, and if you come across any problems please let us know by filing a bug report, suggest improvements to the code or documentation or even fixing the issue you found yourself. Being a work in progress means you might hit some bumps in the road, but it also means you have an opportunity to help out deciding the best solution.
And as mentioned before, adding FuseSoC support for your own cores is valuable since it makes it easier for you to run it through different flows and for other people who want to use them as is or as a part of a bigger design. Don’t worry. Adding a FuseSoC core description file is in most cases
very straight-forward and doesn't put any additional requirements on
your code. We’ll help you figure out the problems if it doesn’t work. Also keep in mind that the larger the ecosystem of cores become, the higher chance you will find the cores you need next time you start a project.
 | |
| “Focus on your core business, not your cores” C. McCoreface 2019 |
