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.