feature article
Subscribe Now

The Custom CPU Paradox

Is RISC-V Generic or Custom?

“I think there’s something great and generic about goldfish. They’re everybody’s first pet.” – Paul Rudd

RISC-V, like Finn, is kind of a big deal. It’s free, it’s flexible, and it’s fast. It’s not particularly remarkable as microprocessors go, but neither is it offensive or saddled with terrible flaws. It’s the beige Toyota Camry of processors. 

That makes RISC-V the safe and easy choice for a lot of developers. But would you consider RISC-V a generic RISC processor or a custom anything-you-want processor? Is it plain vanilla or application-specific? A floor wax or a dessert topping? 

It’s both! It’s a paradox. It starts out as a mild-mannered RISC implementation, but when it jumps into the phone booth it becomes a super-processor! It can be as bland or as exciting as you want it to be, a trick that other CPU vendors have also tried to pull off. 

Customizable processors can seem like either the dumbest idea in the world or the best thing since canned beer. On one hand, processor ecosystems thrive on compatibility. You can’t develop compilers, debuggers, operating systems, applications, middleware, or even productive programmers if every CPU is different. Without compatibility, we might as well create programs by soldering wires and swapping out hardware. A CPU’s instruction set – a fixed instruction set – is what makes software, software. That compatibility feeds the virtuous cycle of more software, more tools, and more CPU sales. 

On the other hand, generic CPUs are boring. Workloads change over time, and not every programmer needs the same set of features. Lots of us don’t need floating-point arithmetic. Some need bit-manipulation instructions. Others need Linux support, or vector operations, or that weird table lookup and interpolate thing.  

Oddball instructions can make a big difference – a really big difference – to how your processor performs. Gamers argue over the relative merits of one Intel CPU versus another AMD processor, but those are nearly identical chips with differences of only a few percent. Compare that to how a low-end DSP handily outperforms a high-end ARM, PowerPC, or x86 design and the differences are striking. Architecture and instruction set really do matter. 

Trouble is, when you veer from the generic path you lose compatibility and you lose software support. Instructions that aren’t part of the RISC canon get ignored by the compiler, just wasted and superfluous hardware. Only assembly-language programmers or those willing to write compiler intrinsics get to leverage that extra muscle.  Unless you’re tweaking benchmarks for a living, what’s the point? 

RISC-V takes the middle ground and defines a base instruction set that all processors share, plus a set of optional add-on modules. You want floating-point? We’ve got that all designed, defined, created, and available. Everyone doing FP on RISC-V is doing it the same way, so the compiler writers are happy and your code is more or less portable. 

In addition to those semi-standard options, you can branch out and create your own radically custom instructions. This is, after all, an open-source CPU specification, so nobody can stop you. You can even try to sell your creations back to the community, if you want. 

Customizable instruction sets have been done before, and they mostly work. ARC and Tensilica, from Synopsys and Cadence, respectively, allow user-level customization. They work in the sense that users really do see large improvements in performance, or reductions in power, when they craft useful new instructions for their particular application. It’s not always a straightforward process, but it’s effective. The downside is that customizations have limited software support, and they’re not compatible with anyone else’s chips. 

Of course, that latter characteristic might actually be an advantage. Want to obfuscate your code and prevent reverse engineering? Simply add a few oddball instructions to your processor and use them liberally throughout your software. It doesn’t even matter much what the custom instructions do. The point is that nobody else knows, either. 

The real point, of course, is to find hotspots in your code and create custom instructions to accelerate them. Maybe you do a lot of memory walks with a particular stride; a custom load/store pair might help. Repetitive bit twiddling might be condensed into a single special-purpose operation. And so on. 

There’s little point in removing instructions, even though it’s possible. Every CPU needs a baseline of instructions to operate. Okay, sure, you can get by with an extremely minimal set of instructions, but that’s mostly of academic interest. The core set used by RISC-V and other designs over the past 20 years includes basic addition, subtraction (sometimes just negative addition), logical operations, and conditional flow control. All of these are useful and none of them is complex to implement in hardware. Meaning, they’re never a performance bottleneck, so there’s no upside to removing them. 

At the other extreme, you’ve got processors like Intel’s insanely complicated Ice Lake microarchitecture (officially Core 10th generation), with hundreds of instructions, many of which are little used. That baroque instruction set weighs down the chip, not only in terms of silicon real estate but in all the complex logic required to make it work. Complex CPUs have complex interconnects, large buses, and multiple clock domains – a far cry from RISC-V, even with its optional enhancements installed. 

The MIPS architecture has allowed user customization for years, but ARM steadfastly resisted the trend. Others fall somewhere in the middle, with most permitting only very limited tweaking. In that sense, RISC-V is among the more open-minded processors.  

As RISC-V proliferates, it’s going to get harder to pin down what the CPU is and isn’t doing. Everyone is free to customize, and many RISC-V designers already have. Apart from the core instruction set and one or two popular extensions, we’re going to see a big gap open up between the stock CPU and the custom hot rods. They’ll all be RISC-V at some level under the hood, but very different in outward appearance. Start your engines!

Leave a Reply

featured blogs
May 17, 2022
Introduction Healing geometry, setting the domain, grid discretization, solution initialization, and result visualization, are steps in a CFD workflow. Preprocessing, if done efficiently, is the... ...
May 12, 2022
Our PCIe 5.0 IP solutions, including digital controllers and PHYs, have passed PCI-SIG 5.0 compliance testing, becoming the first on the 5.0 integrators list. The post Synopsys IP Passes PCIe 5.0 Compliance and Makes Integrators List appeared first on From Silicon To Softwar...
May 12, 2022
By Shelly Stalnaker Every year, the editors of Elektronik in Germany compile a list of the most interesting and innovative… ...
Apr 29, 2022
What do you do if someone starts waving furiously at you, seemingly delighted to see you, but you fear they are being overenthusiastic?...

featured video

Increasing Semiconductor Predictability in an Unpredictable World

Sponsored by Synopsys

SLM presents significant value-driven opportunities for assessing the reliability and resilience of silicon devices, from data gathered during design, manufacture, test, and in-field. Silicon data driven analytics provide new actionable insights to address the challenges posed to large scale silicon designs.

Learn More

featured paper

Introducing new dynamic features for exterior automotive lights with DLP® technology

Sponsored by Texas Instruments

Exterior lighting, primarily used to illuminate ground areas near the vehicle door, can now be transformed into a projection system used for both vehicle communication and unique styling features. A small lighting module that utilizes automotive-grade digital micromirror devices, such as the DLP2021-Q1 or DLP3021-Q1, can display an endless number of patterns in any color imaginable as well as communicate warnings and alerts to drivers and other vehicles.

Click to read more

featured chalk talk

Multi-Protocol Wireless in Embedded Applications

Sponsored by Mouser Electronics and STMicroelectronics

As our devices get smarter, our communication needs get more complex. In this episode of Chalk Talk, Amelia Dalton chats with Marc Hervieu from STMicroelectronics joins me to discuss the various topologies present in today’s wireless connectivity, and how the innovative architecture and flexible use of resources of the STMicroelectronics STM32WB microcontroller can help you with your wireless connectivity concerns in your next embedded design.

Click here for more information about STMicroelectronics Wireless Connectivity Solutions