ONiO RISC-V Coremark Results

One Coremark is a single execution or iteration of the program so it lends itself handy in two ways. Both benchmark how many iterations can be executed per clock cycle (MHz) and how many iterations per energy unit (mJ). Typically a CPU will display a certain number for Coremark per megahertz; CM/MHz. Broadly speaking the higher this number is the better or more computational load can be performed by the CPU.

When designing digital IPs such as a CPU there is no problem to achieve high computational efficiency if no weight is to be put on how much energy is being used. Now, to use Coremark to also benchmark computational energy efficiency: one measures the number of Coremark per millijoule; ULPMark-CM.

Now that we know a bit more about Coremark and what we can use it for - let’s consider a few things.

The Coremark Applicability

There is certainly an argument to be had when it comes to how applicable or representative Coremark is for what you do in your application. Because the benchmark itself is written in a way where the CPU is loaded in a way that is very synthetic, especially for an embedded system. And here we can only nod and say yes, for many applications this is true. However, at the same time Coremark is a nice way to compare between various product offerings in the market. That naturally creates a momentum for pushing as high CM/MHz or CM/mJ. One can certainly see this in the ARM Cortex M lineup, where the M0, M0+, M3, M4 and M33 largely share the same instruction set - but due to implementation differences they yield different Coremark scores.

RISCY ARM wrestle?

At ONiO we utilise the RISC-V instruction set. Everyone will have their own justification for licensing an CPU IP or implementing their own. Certainly, it is very clear that over time ARM’s Cortex M lineup provides some very strong CM/MHz numbers where for instance an M33 in some of the products from ST, Nordic Semiconductor etc. will yield around 4CM/MHz. This is very strong compared to most RISC-V implementations that can be licensed. These seem to offer between 2.8-3.4CM/MHz, something that is certainly not bad scores - but seemingly a bit short compared to ARM. And of course there are some IPs that are better than the numbers listed here!
At ONiO we knew pushing beyond 3.2-3.4CM/MHz meant that we had to compromise computational efficiency. Or in other words energy had to be wasted to get more computational power. Being an energy harvested system the gravity is always towards energy efficiency. And thus no such tradeoffs were done.

Gameplay: Upperhand

Luckily a CPU by itself is pretty meaningless - you need a bus system, memories, a clock source and some kind of power management system. And  this is where the battle is ultimately going to be won - and where ONiO does its magic. Make all of these pieces really well, fabricate them in a good CMOS process and you have a great combination.

For an energy harvesting system like the one implemented on ONiO,there are some disadvantages. Typically when you make a power management system it is easier to achieve a high efficiency number as the power load increases. Simply because at low loads, the quiescent power of the switcher is non negligible. Furthermore - Coremark is run at 3V fixed rail not a solar cell. So while most MCUs will optimise their power delivery system to alway buck down a 3V source to a core voltage and thus have great current translation rate.

Conclusion

ONiO.zero is capable of a very respectable 135CM/mJ and 22uW/MHz while running Coremark from non-volatile memory! A result we are very proud of and an excellent tradeoff between computational and power efficiency.