ONiO is ARMed for the future with RISC-V

The ARM Legacy

What was always clear was that the ARM Cortex-M3 made a big splash in the market in the early to mid-2000s. It made a clear demarcation between the 8/16-bit world at the time and what seemed like overly complex 32-bit architectures. Not to step on too many toes, but with the 8/16-bits of the time, you could “just sit down and code” while it was actually a bit more painful to do so pre-Cortex-M3. AVR32 was another favorite of the early 2000s. A few years later, we saw the birth of the Cortex-M0 and, quickly thereafter, the Cortex-M4 and Cortex-M0+. The last two CPUs arguably being pretty damn good for what they were intended for; embedded applications where energy efficiency, code density, and ease of use are the most sought-after features. Lineup topped with the brutal Cortex-M7 behemoth of a CPU.

The Cortex Conundrum

With most any market and performance profile covered - what came next seemed like a solar eclipse and a 180-degree turn of direction. The introduction of TrustZone into the embedded world. The seemingly unstoppable Cortex-M bonfire ran out of premium fuel, and in came the “security” ready Cortex-M23 and Cortex-M33. Anyone that has ever touched the topic of CPUs and security knows that it is better to make that part of the initial plan of a device - not an afterthought. It is pretty near impossible to just retrofit a Cortex-M23/M33 device into an existing device. It is not a simple swap. And based on the speed at which secure enclaves, secure islands etc., popped up, it became pretty clear what embedded in reality wanted was safe and secure storage of encryption keys and use of these. Being able to run trusted and not trusted code in an embedded device is a bit of an elusive idea, to say the least. So as a consumer of embedded devices, you find yourself left with the ONLY option to fix your product’s security by classifying code as secure and not, it begs the question if product security was really well understood at all.

The Dawn of RISC-V

Now being well primed on ARM’s deliverables and a basic understanding of there being many better venues to solve device security than the CPU itself - in the CPU diary, we are now at 2015. Lo and behold, the RISC-V Foundation is created and the definition of the RISC-V architecture is being put in very fertile soil; strong industry players come aboard as backers, and CPU extensions for various application profiles are being defined. Slowly sprouting, it is clear that this is a great platform for embedded devices - and what’s there not to like?  Its appeal stems from an open instruction set architecture (ISA), the complete absence of fees or royalties, a versatile range of profiles for a perfect match, stellar performance alongside efficient code density, and the straightforward process of integrating bespoke instructions.

Why RISC-V Shines

And especially for what ONiO is doing, it was a match made in heaven. We have always believed embedded machines were all about; energy efficiency, code density and ease of use. But also being able to tweak the RTL implementation to our own liking, adding instructions to set us apart in applications we know well has tremendous value. If we as a collective pause for a second and reflect upon what a microcontroller is really up against:

It is clear that a great embedded CPU for a microcontroller has not one key feature to rule. It has a wide list of things to master well enough - it does not have to be perfect in all. But if the designer of the CPU can implement it, customize it, add and subtract from it to solve a specific application; there is tremendous potential and value in RISC-V.

Tailored for ONiO

And that is why we have chosen RISC-V as our CPU of choice at ONiO. We could have made a whitepaper about how well we stack up against an ARM Cortex-M4 with our RV32IMC implementation - but it defeats the purpose - and let’s face it there will always be pros and cons and multiple views on the topic of code editors and choice of CPUs (Pun intended). But being left with the option:

Made our choice being beyond Coremark/MHz, Dhrystone score or implementation size, supported standard cell library etc. - but rather based on freedom. By choosing RISC-V we gained the freedom to have energy efficiency, code density, ease of use, tweak the RTL implementation and instructions. And not to forget – the freedom to solve embedded security where it should.