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.