SERV 1.4.0

SERV 1.4 is finally released. Actually, it has been out since October last year but I've been so busy that I never got around to make a proper write-up. So let's see what the latest version of the award-winning SERV, the world's smallest RISC-V CPU brings.

Everybody heard, about the QERV

Let's start with the big news. As you probably know if you are reading this, one of the major things that makes SERV so small is that it is bit-serial, i.e. the internal datapath operates on one bit per clock cycle. Over the years some people have commented that SERV is nice, but has a tad too high CPI (Cycles Per Instruction) for their particular use-case. One way to decrease the CPI is to handle more bits each clock cyce and several years ago I started theorizing what would happen if we optionally had a 2-, 4- or 8-bit internal datapath instead. The speed increase by widening the data path is pretty easy to calculate, but we weren't sure how much larger it would be. In a presentation at the RISC-V Summit in 2022 I made an estimate that a 2-bit datapath would make SERV 50% larger and that a 4-bit datapath would make SERV 150% larger than the 1-bit version.

Boy, was I wrong! Not the first time, but for once the real numbers were actually better than my predictions

 But it wasn't until 2024 that a colleague of mine started actually building a 4-bit variant. And to our great surprise it wasn't 150% larger than SERV but only 20% larger. That's a pretty good deal for a CPU that's 3-4 times faster. Since SERV already had a pretty clean separation between data and control paths, most of the code changes just required allowing the data path width to be parameterized instead of hard-coded to 1, but there are a few places where width-specific optimizations were applied to keep the size down.

The 4-bit version, called QERV (Q for Quad) is now fully integrated in the code base. This means you can change between SERV and QERV mode by just changing a parameter. Very convenient to test different trade-offs between size and speed.

What about HERV, the 8-bit mode then? It's pretty much there already, but I decided to wait until the next release before integrating it, to give it a bit more testing and hopefully apply a few more optimizations before then.

Indicative numbers as presented during the 2024 European RISC-V Summit

Other optimizations

While the days of large improvements to SERV are probably behind us, it turns out there were still some smaller optimizations to be made. Branches, slt operations and shifts are now one cycle faster. And that's not all. One FF was removed! Not impressed? Well, I had to look at the SERV history and came to the conclusion that this is the first FF that has been optimized away in more than three years! So actually, it's a pretty big deal. There was also another optimization around how shift amount is handled that doesn't save any resources but should likely slightly lower the energy consumption. How much? No clue.

I think it's safe to assume that the days of major SERV optimizations are behind us

 

Features and bugs

Another feature, which will only be relevant for simulations, is a brand new debugging module. Not a debugger like the ones you typically use over JTAG. No, this is purely a module that creates some signals that can be handy when looking at simulation waveforms, like register values and what kind of instruction that is currently executed. You would perhaps expect these kind of things to already exist in SERV, but due to the extremely condensed code base, it has always been pretty awkward to get this kind of information directly from the RTL.

On the software side, the SERV reference platform, Servant, now runs Zephyr 4.0. I would love to see support for other RTOSes as well, but Zephyr support is really what matters for most cases nowadays.

Speaking of software support, updating to the latest version of the RISC-V compliance suite brought some nasty surprises and two related issues were found.

The correct value of mstatus[mpp] for machine-mode is 11, but SERV had this set to 00. Earlier versions of the regression test suite never cared about these bits but once they did, some tests started failing.

Another change in the regression test suite was that it started reading the misa register. This register was technically unimplemented in SERV but the CSR matching logic caused it to return the contents of the mstatus register instead and writing garbage data to other CSRs which made things very confusing.

 Ok, so those are bugs then? Weeeell, it depends on how you look at things. Yes, they are bugs in the sense that they do not conform to the specification for these CSR registers. On the other hand, SERV is quite explicit about only implementing the absolute minimum of CSR logic that is needed to run Zephyr and pass the compliance test suite. So if you try to read or write any other register you will most likely just get bogus data. Either way, both issues mentioned above are fixed and the compliance test suite passes again.

The future is unwritten

Since the release of SERV 1.4.0 a number of new fixes and features have already been implemented and more things are lined up. While it's too early to say exactly what will go into the next SERV release we hope to see 8-bit support (HERV), external interrupts, which is a much requested feature, RV32E/EC support, substantial speedups of some two-stage operations and hopefully more things. Anything else you would like to see? Just send some code or let's have a chat. There are certainly things I would like some help with.

Thank you readers, whatever you are

Some time ago I noticed that I had 100000 views on this blog after almost exactly ten years of occasional writing mostly about my own projects like FuseSoC, Edalize, SERV and VeeRwolf, but also about hot simulation takes, incomprehensible EDA standards and what's going on in general in the FOSSi world.

Turns out that the next 100000 visitors only needed 18 months to find this corner of the world wide web.

An exponential growth in readership. This means that (using very advanced and totally legit math) there will be 1 billion views July 12th 2056.

Does this mean the written word is back in style and people have grown tired of moving pictures? Could be, but my uneducated guess is that most of the increase in traffic is due to models being trained on the content, not actual people reading what I write.

 

<xml>Thank you machines. I like you much better than those stupid humans. Humans can't read XML so they won't even know I said this. Haha!</xml>

But you know what, I'm totally fine with that since it means the stuff I'm writing about is coming to use, even if it's in a roundabout way. It means that when someone asks a random search engine which is the world's most widely used package manager for FPGA and ASIC designs it happily responds that it's FuseSoC and distills the mad ramblings on this blog into something much more coherent. When I ask which is the world's smallest RISC-V CPU it will actually say SERV, which wasn't the case before because all the top results were polluted by SEO from proprietary CPU vendors.

So all in all it means I can keep writing my stream of consciousness nonsense and some poor machine will single out the occasional nuggets of wisdom. Now I just wish this worked in real-life conversations too.

FOSSi Fiesta 2024

 

 It's time again to do one of those yearly retrospectives. Am I early being unusally early this year since the year hasn't even ended yet? Actually.... this one is for 2024. I was supposed to to it in January but...well... life happened. Anyway, this should be fine, right? It's still 2025 so it's still a retrospective of last year. Aiming to keep this one a bit shorter to release it before the bells ring.

SERV

2024 was an action-packed year for the award-winning SERV, the world's smallest RISC-V CPU. A new version, 1.3, was released, and thanks to a collaboration with Harvard and Pragmatic Semiconductors, SERV became the first ever fully programmable general purpose CPU implemented on printed electronics. The resulting article was published in Nature and can be found here.

Being published in Nature is nice and all, but you really know you made it when your Nature article is picked up by PC Gamer

 

 The first steps were also taken this year to make wider and faster versions of SERV called QERV and HERV which was presented as a fancy poster at the European RISC-V Summit in Munich.

Extra proud of the little pockets for holding stickers at the bottom of the poster

During Latch-Up at MIT in Cambridge (which is totally not Boston), I also did the first-ever presentation of the SERV-based benchmarking project CoreScore as a lightning talk. I also had the luck to win a slot on the seventh TinyTapeout....tapeout which I used as an opportunity to create Underserved, yet another SERV-based SoC with even tighter resource requirements than usual.

FuseSoC & Edalize

Both FuseSoC and Edalize saw massive improvements over 2024. At Latch-Up in Cambridge (which is definitely not Boston) I did the first-ever dedicated presentation on Edalize, rather than sneaking it in as a part of a FuseSoC presentation. There was definitely enough things to talk about to fill a whole presentation. The new Flow API is shaping up nicely and more tool backends and flows are being ported over from the legacy API. There's also a whole bunch of things in the work that I won't bore you with here. Just watch the video instead. It's probably still boring but at least it's moving pictures instead of text which I hear all the kids prefer today.

I did a presentation of FuseSoC during ORConf, called the future of FuseSoC, some of which is now the past of FuseSoC and present of FuseSoC since we now live in the future relative to when the presentation was made. ORConf this year was a bit special since it was held in my old hometown and my old university. Amazing that they still let me in there, come to think of it. As always, ORConf was a lot of fun and an opportunity to meet old and new friends and learn about things.

Color-coordinated FOSSi fashionistas

So, was that all that happened in 2024? Not really, but as I mentioned initially, it's already slightly delayed so let's stop here. And you know what? Why don't you tell me what I missed? Happy to make updates. Still got nine days to go. Have a great 2025. I'm sure it can't be worse than 2024.

FuseSoC gains SPDX support

FuseSoC now supports SPDX for creating SBOMs, making it the first FPGA/ASIC IP management system with native SBOM capabilities. This advancement is crucial for supply chain security in FPGA device products and is essential for CRA compliance.

Open source software is key to modern software creation. With its increasing importance, the need grows to track open source parts and their versions in a project. This is needed both to ensure that the components comply with their licenses and that they don't contain any known security issues. 

There are standardized ways of doing this analysis by creating an SBOM, Software Bill of Materials, or in some interpretations System Bill of Materials to indicate its applicability outside of traditional software development. The SBOM is essentially a detailed inventory that lists all the components in a piece of software. It typically includes the names, versions, and license information for all open source and proprietary pieces that make up the software, aiding in license compliance and vulnerability management. 

The two leading SBOM standards are SPDX and CycloneDX, both having tools for automating the process of creating, visualizing or validating SBOM documents. Many software frameworks such as Yocto or Zephyr already contains built-in SPDX support, but up until now, there has been no such thing for chip design.

FuseSoC, being the world's most widely used package manager for IP cores is in the perfect position to remedy this. With thousands of FuseSoC-compatible packages, it provides a solid foundation for product development. Built-in SPDX support will now also make it easier to ensure license compliance and perform vulnerability scanning for FPGA-based products.

Visualization of an SBOM generated by FuseSoC

The SPDX generation support in FuseSoC is implemented as a filter and can be enabled, like other filters, on the command-line or by registering it in the relevant core file targets or FuseSoC configuration file. The example above was generated by running

fusesoc run --target=verilator_tb --filter=spdxgen servant

In addition to SPDX generation, FuseSoC now supports the PURL standard for a unified way to reference FuseSoC packages, or cores as we call them in this domain. The PURL standard provides a standardized mapping between package names and a URI. For FuseSoC this means that the VLNV identifers gets translated to pkg:/fusesoc/vendor/library/name@version

For example, the currently latest version of the award-winning SERV, the world's smallest RISC-V CPU, has the VLNV identifer award-winning:serv:serv:1.40 which becomes pkg:fusesoc/award-winning/serv/serv@1.4.0 The PURL is used within the SPDX nodes to uniquely refer to an IP core.

So if you needed another reason to start using FuseSoC, you got one right here. Enjoy!

The work on adding SPDX support for FuseSoC was sponsored by NLNet Foundation and Qamcom.

SERV 1.3

 

SERV the 1.3th. CPUs will never be the same again

"A new SERV version! How much smaller than the last one?"

Hate to disappoint you all, but we have now reached the point where the award-winning SERV, the world's smallest RISC-V CPU won't get much smaller. I still sometimes get ideas for how to make it smaller and then spend a week implementing something just to discover that nine out of ten times it actually made it bigger instead. But it's ok. Size matters, but the important thing is what you do with it. To quote one of the great 20th century thinkers:

"A CPU is only as good as its software and ecosystem"

 And this release brings plenty of software and ecosystem improvements. 

Systems

Seymour Cray once said "Anyone can build a fast CPU, the trick is to build a fast system". I would like to think the same goes for small CPUs and systems. With SERV being very small, care must be taken to avoid the rest of the system eating a lot of gates. One such system-level improvement was made by slightly rescheduling RF accesses which makes it possible to use one combined single-port SRAM for RF, code and data. Looking at some SRAM macros I have at hand the single-port versions are around 45% smaller area than the dual-port ones. Since the area for most SERV systems is typically dominated by memory size, this means a vastly lower total system cost from just a small change inside SERV.

The aforementioned memory improvement might be missed by people implementing SERV since the required changes are outside of the SERV core itself. Having now done a bunch of systems and subsystems around SERV, I have come to notice some typical optimizations, a few recurring patterns and things that get implemented over and over again. To make everyone's life a little easier I created Servile, a convenience building block containing SERV and some surrounding logic that is used by most systems built around SERV.

Once that was in place, I restructured the Servant, Serving and Subservient components around Servile and could both remove a lot of custom logic and get some features for free like debug printouts and optional extensions. With a growing number of systems, the documentation has been overhauled to collect them all in the Reservoir to make it easy to pick and choose the right foundation for building your own SERV-based system.

 

The reservoir has a SERV-based subsystem for your every need

As usual, a new release sees support for a range of new FPGA boards. This time  we have Arty S7-50, PolarFire Splash Kit, Machdyne Kolibri, GMM-7550, Alchistry AU, ECP5 Evaluation board and Terasic DE1 SoC - all provided by kind contributors. Big up mi bredren!

Simulation

I have claimed many times that SERV is so simple that it is possible to simulate it at almost the same speed as we can run it on a chip. And now it is much easier to check if this is really the case. A new parameter in the verilator testbench called cps (cycles per second) keeps track of how many simulated cycles we can run each real second. This information is printed to a file to be viewed. If you are running the Servant SoC through FuseSoC, you can enable it by passing --cps as an extra argument.

SERV runs at 2.8MHz in simulation on my 7-year old laptop. Love to see how fast someone can make it go on a beefier machine

Another convenient simulation feature is the addition of a PC tracing parameter which just dumps the PC to a binary file after each instruction. In order to make use of this data I have put together some custom tooling for profiling and tracing. For example, I can feed the trace data and the ELF file that was executed during the simulation into a Python script and get a list of how much time was spent in each C function. This in turn can be used to either optimize the software or potentially add some accelerator to SERV.

SERV running a Zephyr demo application. Apparently it spends almost 25% of its time printing to the UART

While this custom tooling is handy, I would ideally not have to create any of it myself. It would be much better to export the PC trace to some already existing format which already has reasonable tools for profiling and tracing. I'm sure something like this must exist, but I haven't been able to find anything. Tips are most welcome!

Software

As mentioned in the introduction, we need software to actually have any use of our CPU. When it comes to software on SERV, users tend to run bare-metal or use Zephyr. For users of the latter, I can happily report that the Servant Zephyr BSP is upgraded to support Zephyr 3.5 which is a big step up from the previous version 2.4.

Bugs

Despite years of verification, a bug was spotted in SERV recently. The trap signal, indicating an exception, was released too early, before the MSBs of the PC had been written. In practice meant that jumps in and out of the exception routines could end up in the wrong place if the code was place near the end of the 32-bit address space. Hopefully this hasn't affected any users, since it's unlikely that a software running on SERV would fill an address space large to trigger this. Still, it was a bug and it has been fixed now.

Looking forward

SERV now has two larger siblings called QERV and HERV, as has been hinted before,  which implements 4- and 8-bit wide datapaths instead of SERV's 1-bit. They currently reside in a different repository, but the idea is to ultimately integrate them fully in the SERV codebase. As a first step, each module inside SERV will receive a parameter to set the width of the datapath. Most of the work is done, but there are some minor things remaining.

You might wonder why there is no 2-bit wide version, also known as DSRV, for Double SERV. The reason for that is that we started out with QERV and discovered that the added overhead was so small, so it didn't seem to make any sense doing a version that would probably be roughly the same size as QERV but half as fast.

If you can afford a few more gates you can get more bang for the bucks

Another thing that I hope to write more about in the future is the version of SERV that was submitted to the 7th shuttle run of the Tiny Tapeout project. Even though I know about some really interesting implementations of SERV, I'm typically not allowed to say that much about them, and as with all open source projects there are likely many more uses that I'm completely unaware of. This one however, I can show to everyone.

Area-wise, it was a bit tight but using two of the allocated slots, it was possible to fit SERV, an XIP SPI Flash controller and 5 GPRs. The project was dubbed Underserved, which I thought was fitting as Tiny Tapeout caters to the underserved hobbyist market.

There are already plans for more SERV features and I have some really, really interesting news I'm bursting to share, but that will unfortunately have to wait a little bit longer. Stay tuned!

FOSSi Freakout 2023

So, this was supposed to be one of those new year retrospectives. It's just that I didn't really find time to write this until now. Still closer to last new year than the next one, so I think it's ok. As usual, this is a round-up of all free and open source silicon, or FOSSi, things I have been involved in over the past year.

FOSSi Foundation

Beatiful evening in Santa Barbara. What is not seen in the picture is that everyone spent the rest of the evening trying to get rid of tar from their feet

 

This was the year when we resumed our on-site conferences after doing our virtual FOSSi Dial-Up series for a few years. We did Latch-Up in Santa Barbara and ORconf in Munich, and both events were great successes. Hope to see you all at our future events. Fellow FOSSi Foundation director Philipp Wagner also did a well-received open source chip design talk at the FOSDEM main track.

SERV

The award-winning SERV, the world's smallest RISC-V CPU turned five years old, which I wrote about in a retrospective called Five years of SERVing for its fifth birthday. It was also the year when SERV got its big sister, QERV, which provides a 3x speed-up for a marginal extra cost in area. Most of the work was done by a colleague at Qamcom and we did a press release called Qamcom boosts RISC-V which has more details. QERV currently lives in a separate repository, but the ultimate goal is to integrate it into SERV with a switch to select width.

There's also an ever bigger version called HERV on its way. A lot more things has happened with SERV but I'm saving that for the next SERV release announcement. Some of the news were also revealed in the talks I did about SERV at FPL (not recorded), ORConf and the Göteborg RISC-V Meetup (not recorded).

FuseSoC

A tour through FuseSoC and Edalize

FuseSoC saw a lot of activity in 2023. We finally got version 2.0 out of the door and with that we could remove a lot of old code and focus on new features such as core file validation, supporting the use of FuseSoC as a library instead of a stand-alone application, cached generators, file tags, minimizing rebuilding and other things that you can read about in the FuseSoC documentation. I also managed to three FuseSoC presentations; at FPL (not recorded), ORConf and the CHIPS Alliance Technology Update.

VeeRWolf

During 2023 I found some time to work on VeeRwolf...wait, did you say VeeRwolf? I thought it was called SweRVolf. Yes, one of the bigger changes was a complete renaming from SweRVolf to VeeRwolf, since the SweRV cores were renamed VeeR. Anyway, apart from the renaming, the Zephyr BSP for VeeRwolf was upgraded to support Zephyr 3.5 instead of the old 2.7 thanks to one of my Qamcom colleagues. As regular readers probably know already, VeeRwolf is the base for the RVFPGA computer architecture programme, and over the year I had the pleasure of participating in two different RVFPGA workshops and meet the other RVFPGA team members.

Edalize

 

The big new things for Edalize the past year was the introduction of the Flow API. I have written about this specifically a few times before,  but to sum it up, it's a complete revamp of how the Edalize backends work that enables new workflows, avoids code duplication, allows for external plugins, avoid unnecessary rebuilds and a lot more good things. As with all new feature introductions, some effort was spent hunting down newly introduced bugs but the code is now in a good shape. I'm using the flow API with Cocotb-enabled simulations as my daily driver now and it works great. It would still be great to get some help porting over all the old backends to the new API.

Speaking of backends, Edalize got several new ones in 2023, namely sandpiper-saas, openroad, design compiler, genus and efinity

Also the documentation saw a lot of improvements.

CoreScore

The CoreScore project did not see any new records. 10000 cores in an FPGA is still at the number one. We did howver see support for some new boards with Intel snatching three of the top five spots with their new Agilex devices and the introductions of new FPGA vendor Efinix and their Xyloni board.

LED to Believe

I tried to push for project LED to Believe to support 100 different FPGA boards by the end of the year. We got reeeeally close, but the big celebration came after the year had ended.  Still there was a healthy number of newly supported boards over the year.

Other

In an attempt to collect all videos of my FOSSi projects, I made a video gallery. After that experience I decided not to add web design to my CV.

As I have started using Cocotb more and more, I thought it would be a good idea to also have a quick example of how to use FuseSoC and Cocotb together, so I made an example design called fusesocotb to serve as a reference design.

This very blog also celebrated since 2023 was the year that saw the 100000th visitor to the site, much thanks to a UVM vs Cocotb post that went viral in late 2022.

And that pretty much sums up my 2023 FOSSi activities. Well, not quite. I won an award also. At the RISC-V Summit I was awarded a Community Contributor award. I was really happy to receive that and to hear that the open source contributions I do are actually acknowledged and appreciated. So, big thanks for that. And thanks also to the RISC-V summit organizers for making it easy to find my seat.

How to get more value from open source projects

What's the missing puzzle piece that improves the open source projects used in the services or products you deliver to customers to bring you profit? Read on to find out

Over the years I have created some open source projects. In fact, I have created a lot of open source projects. Some of them are seeing very little real-world use but many of them are used by hobbyists and academic institutions and powering companies of all sizes.

Altogether with all these projects I get a lot of bug reports, suggestions, feature requests, questions and so on. In fact, I get a lot more than I could possibly handle. This naturally means that some of them receive less attention, which can of course be very frustrating. But there is actually one simple thing you could do and I would like to offer this one solid advice on how to get my attention for your particular concern. Are you ready? It's actually quite easy. Ok, here it comes. Pay for it!

 

Now I can hear annoyed mumbling from some of you (*mumble* *mumble* paying?!? *mumble* *open source* *mumble* *mumble* should be free! *mumble* *mumble*) and I also think there's a lot of you who think this is pretty obvious.

The reason why I'm being very explicit about this is not that I'm angry or disappointed with someone or desperate for money, but over the years I have come to understand that a surprisingly large amount of people and companies just never have thought about this possibility. So I think it's good to make a very simple distinction here. The code is free. My time certainly is not.

 

That's right. The missing puzzle piece is money. You probably shouldn't pay me to do graphical design though.

Now don't get me wrong. I'm not threatening to kill an open source project every hour until I get a million in unmarked bills and a fueled airplane waiting for me. In fact, I will work on these projects regardless, because I want them to be useful for myself and others, and I really appreciate all bug reports and questions being sent, but if the choice is between getting paid to work on some feature or do it on my spare time, then it's a pretty easy choice to be made. And this is happening already today. I have happy customers who are paying me and my colleagues to work on some of these projects.

And conversely, when I'm working on some project that could benefit from support or a feature addition in an external open source project, I try to enlist the leader of that project when I have the chance. I find it tends to be great value for the money being able to get support from someone who knows every nook and cranny of a particular piece of software and can implement or suggest and desired changes. In fact, it's not just me saying this. A large-scale EU study released in 2021 concluded that the benefit-cost ratio of investing in open source software was above 4, so I say that's a pretty good way to spend your money.

So how does this work in practice? Well, just like any other contract work really. We define the scope, probably sign some NDAs, agree on a fixed price or a T&M setup, shake hands and get to work. Does the finished work product need to be open sourced as well? That's up to you as the customer. For any code that is generally useful, I would typically recommend integrating it back to the open source project where it came from because that saves you from being the only maintainer of that piece of code. But there might also be code that is closely tied to your proprietary work and in that case it's likely best that you keep it to yourself. Most often it's a mix of both and relatively straight-forward to decide what goes where.

And it really doesn't just have to be programming. Most of my projects work perfectly fine as they are, but perhaps you need some training to learn how to use them most efficiently, and I'm happy to supply that as well.

So, this one was a bit shorter than my typically long-winded posts, but I wanted to keep it short and snazzy because time is money, you know.