Friday, February 11, 2022

FOSSi Explosion 2021


Do you know what just happened? 2021 just happened. Most years has its ups and downs, but when it comes to 2021 it seems like the prevalent feeling was that everyone just wanted it to be over. And now it is over, except for all those damn retrospectives. So, with the risk of opening up some old wounds I would like to take a look at what happened last year in my corner of the free and open source silicon world.

In the 2020 retrospective I wrote about a couple of big milestones, like the first vendor-supplied FOSSi FPGA toolchain and the first fully FOSSi ASICs. 2021 was... more of the same I guess. And personally I think this is the interesting part. Everyone is now working hard to actually do stuff with these new opportunities that arose in 2020. Finding new possibilities, hitting limitations and working around them. Solving problems, being creative and coming up with new ideas. Less headline-friendly but will have more impact longer term. And 2021 was by no means void of interesting news. Just look at the FOSSi Foundation newsletter El Correo Libre that was packed to the brim with interesting projects and announcements each month.. It's more that I couldn't think of anything that particularly stood out so I'm moving directly to the more personal events instead. Is that ok? Of course it's ok. I'm writing now!



Let's start by looking at my oldest active open source project, FuseSoC, that turned ten years old in 2021. For those who don't already know, FuseSoC is an award-winning package manager for HDL code. Package manager is a concept that is well-known for software developers, from system-level package managers like apt and rpm to language-specific ones like npm, pypi maven and cargo.

For chip designers, the idea of a ubiquitous package manager has not taken hold and most companies invent and maintain their own incompatible system. Kind of like how we did software up to the mid nineties. Although not as ubiquitous as I had hoped by now, FuseSoC has over its ten years life span still grown to be the most widely used package manger for Verilog/VHDL code and is used internally in large and small companies as well as powering many of the most popular open source silicon projects.

 So how was 2021 for FuseSoC? Frankly, not all that exciting. There was the FuseSoC 1.12 release early 2021 that you can read about here. We got to see some new features, like fellow RISC-V Ambassador Carlos Eduardo de Paula showing how to use FuseSoC with Chisel-based designs, but most of the work done on FuseSoC over the year was to prepare for a big, exciting 2.0 release that will happen some time in 2022. Still, it makes sense to mention FuseSoC first because it is used by every single other project written about here, and the number of projects using FuseSoC steadily rises regardless of the activities on FuseSoC itself.

And just how to get started with FuseSoC for a new design is a question that pops up from time to time. So when Alibaba Group's T-Head Semi released their OpenC910 I did a spur-of-the-moment live coding session, adding FuseSoC support for the core, documenting it through a Twitter thread for everyone to see the process as it unfolded. Check it out if you want to see the unfiltered process of taking a previously unseen core and adding FuseSoC support for it, as well as  showing some of the benefits in doing so.



Edalize started out as a part of FuseSoC but was split out into its own project in 2018. That turned out to be the right decision because it is now used in several different projects other than FuseSoC. And in 2021, Edalize saw far more activity than FuseSoC. In case someone is wondering what Edalize is, it's an abstraction library for EDA tools. Basically, it provides a common API for different EDA tools such as simulators, formal tools, linters, synthesis tools and FPGA toolchains. So instead of writing Makefiles, TCL scripts and other configuration files for 30 different EDA tools manually, you just need to describe it once it the EDAM (EDA Metadata) format and Edalize will generate the correct setup files for your tool of choice. Very handy. The award-winning five minute Edalize introduction video provides more detail about this.

As mentioned, Edalize saw a lot of activity during 2021. First of all it gained support for three new FPGA toolchains; oxide for Lattice Nexus chips, libero for MicroSemi devices and apicula for Gowin FPGAs. The biggest news in terms of tool support was however the openlane backend which provided the first ASIC flow for Edalize. I wrote about that in A first look at Edalize for ASIC flows last year if you want to learn more.

From cheese to chips with the Flow API


A large chunk of the work done in 2021 was not immediately visible to users but was done to lay the foundation of the new Flow API, which will add a great deal of more features and flexibility to Edalize in the future. This has been in the works for quite some time and for those wanting to get a rough idea about it, I recommend taking a look at the article accompanying the Edalize 0.3.0 release which contains a brief introduction to the flow API.


Moving on to another of my more well-known projects, the award-winning SERV, the world's smallest RISC-V CPU, there's plenty of news to report. The question everyone seems to ask first is if it got any smaller, and yes, it did. I was able to optimize away around 20% of the remaining FFs during 2021, although the combinatorial parts of SERV remained more or less the same size.

 But size isn't all that matters. The documentation was massively improved with most of the internal modules now having schematics which are accurate down to the gate-level. And to prove this is actually the fact, I redid the ALU in Digital (a logisim clone) from the schematics and used that as a drop-in replacement of the original ALU. If anyone has the time and interest it would be really cool to see all of SERV implemented in a Logisim-like program and even use that as an interactive documentation somehow.

Working, runnable implementation of the SERV ALU

In addition to schematics, I also added descriptions and timing diagrams for most of the important signal transitions. The ambition is to not only be the world's smallest RISC-V CPU, but also the most well documented. Still got some ways to go but it's already really good. As for new features, SERV got support for the M extension thanks to Zeeshan Rafique who added that as part of Google Summer of Code.

Another big milestone was that SERV was taped out at least four times during 2021 as part of the OpenMPW programme. Two of those tapeouts, both of them the SERV-based Subservient SoC, were done by my colleague Klas Nordmark and I (mostly Klas) as part of a grant by NLNet Foundation to add the Edalize OpenLANE backend and an accompanying reference project. There will hopefully be more things written about this particular project in 2022, especially when we receive the actual chips.

I also found some more time in 2021 to talk about SERV and presented at four conferences, with a brand new SERV video premiering at the embedded RISC-V Forum and being subsequently updated with some additional project ideas for the following events. This new video has shown to be quite popular and goes into more detail on more things that happened during 2021. It's still not as popular as the SERV talk from WOSH 2019 though which apparently has been seen almost 30000 times(!?!?!?)



CoreScore is one of the more niche uses of SERV... ok, most uses of SERV are pretty niche come to think of it. Anyway, CoreScore is a project that tries to answer the question How big is my FPGA? by simply seeing how many SERV cores we can fit into the FPGA
on different development boards. Pretty straight-forward but also very useful for comparing both FPGAs, and also the efficiency of different toolchains. Going into 2021 the record was 5087 cores in a single FPGA. That number was topped twice in 2021 with 6000 cores being the new world record thanks to Sylvain Lefevbre and his Xilinx VCU128 board. Apparently this made some numbers in the tech media and among other things ended up on Tom's Hardware. That was particularly fun as I have fond memories of my 15 year old self spending hours and hours on Tom's Hardware trying to find which motherboard was best for overclocking my Celeron 300A Mendocino. But it was not just in the top where things happened in CoreScore land. In total there were 19 new scores submitted by different users, almost doubling the number of known CoreScores. And best of all, there's now a beautiful highscore table at to keep track of all the numbers.

If you're missing your favorite board in the list, don't hesitate to find out the CoreScore and submit a number for it. Love to see more!

LED to Believe

Another less known but somewhat similar project to CoreScore is project LED to Believe. The goal is simple. If you have an FPGA board, LED to Believe will be able to generate and FPGA image that blinks a LED on your board. While being a very simple project it does serve two purposes. The first is to act as a pipe cleaner for your toolchain. FPGA toolchains are complex and there's a suprising amount of things that can go wrong. Having the most simple project possible helps verifying that the tools are properly installed and can generate an image before you move on to other projects. The second purpose is to be an entrypoint into using FuseSoC and demonstrate how well-suited FuseSoC is for porting a design to different hardware targets. And I would like to claim that it has been very successful in this regard. Already when the year started we could blink LEDs on 44 different FPGA boards and as the year ended this number had risen to 77 thanks to all fantastic contributions from users all over the world. And again, see a board that's missing? Roll up your sleeves and send me a pull request.


The final big open source project I took into 2021 is SweRVolf, a reference platform for the Western Digital SweRV family of RISC-V cores. More recently, SweRVolf is also the foundation of the RVFPGA Computer Architecture Course from Imagination University Programme. RVFPGA is rapidly gaining popularity and I'm both excited and a bit scared now that thousands of university students will get their first contact with computer architecture, RISC-V, Zephyr, open source silicon and FuseSoC through a SoC I designed. And with that in mind, there has been some work to make SweRVolf even more robust and accessible.


The year started with landing support for simulating using Vivado XSim in addition to the already supported Verilator and QuestaSim. Software support was improved as well thanks to a port of SweRVolf for the Tock OS. Increased availability could also be seen on the hardware side where it is now possible to use the smaller SweRV EL2 CPU as an alternative its larger sibling SweRV EH1. The EL2 support was also a prerequisite to run SweRVolf on the Digilent Basys3 board, which carries a smaller FPGA than the Nexys A7 and thus can only fit the EL2 CPU. Many of the latest features can be read about in the SweRVolf 0.7.4 announcement.


The last piece of functionality added to SweRVolf is technically a separate project, but it was born out of a need in RVFPGA and is where it was first used as well. As RVFPGA will become available as an online course, there were some concerns about hardware costs. The online education platform used wasn't totally happy about requiring students to buy an FPGA board. This could be solved by running the course entirely using an RTL simulator but it's really not the same thing as interacting with a board, running your own code and see how it reacts to moving switches and watching LEDs light up from your memory writes. There have been plenty of efforts to visualize simulations by providing some kind of GUI, either in terminal or through some graphics. All of those however seems to be one-off efforts and not easily portable. I wasn't really keen on either repurposing an existing solution nor writing a new single-use system. But then I got an idea. Instead of a tight coupling between simulator and GUI I decided to define a protocol that communicates I/O state over websockets. Websockets are readily available in almost any programming language and most importantly can be used directly in browsers without any complications.

ViDBo : AKA, SoC over sockets

This allows for adding a small component into the simulation model that sends simulation model outputs and receives inputs over websockets. On the other side of the websockets connection sits a browser with an interactive picture of the board, a Virtual Development Board, or ViDBo. This gets us as close as we reasonably can to a no-cost FPGA board experience without any simulator- or OS-specific building blocks. And while this first implementation uses an RTL simulator as the backend and a web browser as its frontend, there is nothing that stops us from having a pure software model as the backend or a headless CI system that acts as a frontend, injecting I/O state and observing outputs. VidBo only defines the protocol sent over websockets, not what sits on either side of the protocol. The only drawback of VidBo is that I now have yet another open source project to maintain which probably was the last thing I needed. Oh well, so far it hasn't been all that bad and I have had some very welcome contributions.

Other stuff

Wow! This turned out far longer than I had anticipated. Sorry about that. But if you got this far and for some reason still haven't had enough of SERV and FuseSoC or want to learn a bit more about the history of open source silicon, I also did a series of video interviews during 2021, covering different topics. First out was two episodes on open source silicon and RISC-V for the FOSS North pod followed by Matt Venn interviewing me for the YosysHQ. Highly recommend checking out both those channels even if you don't want to hear more of me. They both have many high quality interviews with a wide range of topics and guests.

I think this covers most of my open source silicon activities over the past year. Wait! One more thing. I made a UART that's small enough to fit in a tweet in case, you know,  someone needs a UART that's small enough to fit in a tweet.

Finally, I would also like to mention and extend my thanks to Qamcom and NLNet Foundation for funding work on Edalize and Subservient as well as Imagination Technologies and Western Digital who have been funding most of the SweRVolf and ViDBo work during 2021. Take note, all you freeloading companies out there. This is what real support of open source looks like and how you help build a healthy ecosystem.

And with those well chosen words we can leave 2021 without any regrets and sail into the bright future of 2022. Bon voyage!

No comments:

Post a Comment