RISC-V SDKs, from IP Vendor or a Third Party?

Like many of us, I’m a fan of open-source solutions. They provide common platforms for common product evolution, avoiding a lot of unnecessary wheel re-invention, over and over again. Linux, TensorFlow, Apache projects, etc., etc. More recently the theme moved into hardware with OpenCores and now the RISC-V ISA. All good stuff. Then I remember Richard Stallman’s comment about “free as in free speech, not free beer” and I realize that markets around these areas don’t disappear, they just morph into providing value on top of those platforms, especially in delivering commercial-grade equivalents. Such as a third-Party RISC-V SDK.

The siren song of “free”

We can still build software especially from scratch in our home office ventures, but that’s generally a lot less easy than it sounds. Not to mention a major distraction from whatever we thought the goal of our brave new venture was going to be. It’s great to have no license fee overheads, not so great when your customers are finding basic bugs or security bugs in your product. Then it’s nice to have the assurance of commercial-grade toolchains or IPs underpinning your development. Letting those suppliers worry about staying ahead of bugs, enhancements, CWEs and the like.

Build your own RISC-V SDKs?

Mentor recently released a white paper on this topic, highlighting the advantages of their RISC-V SDK over build-your-own (BYO) or RISC-V supplier implementations. BYO is an easy option to dismiss. For either GCC or LLVM compilers, you can’t just compile and link the source. You have to run the project test suites through a test framework. Fixes both to code and to the tests are coming in constantly from the open-source community. Some tests are expected to fail, you have to deal with those. You figure out what to do with unexpected fails, rarely simple. You have to incorporate security patches, usually into libraries, based on the latest and greatest CWE discoveries and patches. Fixes come in according to agreements within the community, on whatever schedules they can deliver. If a customer is screaming at you, you’ll have to figure out your own fix and re-regress. Then maybe swap in the official fix when that appears. A constantly evolving problem. Acceptable maybe if you’re going to make money selling SDKs, not otherwise.

What about the IP vendor RISC-V SDKs?

Why wouldn’t SDKs from RISC-V hardware suppliers be good enough? The white paper doesn’t elaborate on this point, but I’ll take a stab. I’ve worked in software companies for most of my career and I know that software productization isn’t free. Or even close to free. It grows to become a significant chunk of the total company spend. In R&D development and debug. DevOps. Online support. Applications support. In fairness to the RISC-V product suppliers, they put a lot of work into building their toolchain solutions. I’m sure they would object strenuously to any suggestion that their SDKs are anything less that fully robust.

Maybe there’s room for both

And yet I think back to my software company experience and wonder how they are going to scale that part of their business every bit as effectively as the hardware parts of the business.  Especially if they plan to offer the software for free, or close to free. As far forward as I can see, mixing software and hardware in one company is going to remain a challenge. It can be done but it’s not easy. It’s good to have alternatives in the ecosystem. Such as the Mentor RISC-V SDK options.

You can read the white paper HERE.