Uniting diversity and compatibility
Processor vendors have always tried to create a large software ecosystem around their products, because it creates stickiness and it naturally “locks-in” large numbers of customers who have invested in the creation of dedicated software. This effect is growing over time as the quantity of software is ever increasing per product: we could talk about more than 100 million lines of code in a car!
The coupling between hardware and software comes from the selected Instruction Set Architecture (ISA) and explains why processor designers have historically strongly protected it. The ISA brings value to the processor, and so justifies higher selling prices.
Even though the RISC-V ISA is freely used and shared by multiple processor vendors, the story is not different: the value comes from the accumulation of RISC-V compatible code. However, with the ability to customize, some competitors are raising the risk of fragmentation as a weak point of the architecture. Let’s examine the facts and debunk the myths.
Breaking free from fixed ISA
To protect their ecosystem, traditional proprietary ISAs have locked users into predetermined standards, avoiding at all costs to enable deviation to ensure software compatibility. This explains why some modern processor architectures still bear the scars of decisions made in the 1970s, when constraints and systems were totally different. This leads to huge inefficiencies. The RISC-V architecture is changing this landscape by offering an open and customizable ISA. One of the most compelling aspects of RISC-V is its ability to enable customization of the instruction set: a feature that is demanded by many companies. This capability brings a host of benefits, highlighted in the following figure.
This looks extremely appealing, and this is why legacy vendors try to defend their position by raising concerns about compatibility. After all, if every entity starts modifying the architecture, won’t it lead to a fragmented ecosystem where software and hardware become incompatible?
Staying together
This is a legitimate concern, but first let’s examine the facts.
Fragmentation: the facts
First, we must acknowledge that for many applications, very little – if any – of the software is truly dependent on the ISA. Because software developers want to be as productive as possible, they use high-level languages that are compiled into ISA-dependent assembly code. A large quantity of software elements is readily available in these languages: porting them just means recompiling the libraries along with the application. What does this mean? Well, to retarget this code to a processor with custom instructions, you just need a good, dedicated compiler. This is indeed a tricky point, as a custom compiler could require a very skilled and expensive team to build it… Luckily, Codasip Studio generates a dedicated compiler along with your custom processor!
Sometimes you need ISA-dependent code
Now there are still a few cases where you will want ISA-dependent code:
- For tightly optimized code, where each cycle has been counted to guarantee a certain level of performance.
- In large software systems, where you want to execute pre-compiled applications, for example containers in datacenter-like applications or apps in computers or mobile devices.
- The operating system may have ISA specific code such as context or thread switching.
Such cases indeed require efforts to port from another ISA to RISC-V, but once this is done, then customization doesn’t get in the way, because RISC-V is built with customization and compatibility in mind. But before we explain how, let’s just note that custom instructions very often can significantly improve the tightly optimized code you will want to port, so you might want to weight this against easy portability.
No fragmentation with RISC-V
To ensure compatibility, RISC-V has taken the following approach:
1. Standardized base ISAs
RISC-V defines a guaranteed set of standard base instructions. This ensures that a common baseline remains consistent across different implementations. This fundamental compatibility even ranges all the way from the tiniest devices to the most complex server-class multi-core processors. Customization can then be built on top of these standards without disrupting the compatibility.
2. Modular design
RISC-V’s modular design approach separates the ISA into different parts, clearly defining extensions to ensure compatibility. If a piece of software requires a floating-point unit, for example, it would execute unmodified on any RISC-V processor that has such a unit.
3. Profiles
RISC-V has defined complex profiles that define various extensions and simplify the conditions for compatibility to types of devices. This is essential for high-end applications, where the basic compatibility offered by the core instruction set is not sufficient to manage the complexity of the software workloads.
As a processor with custom instructions is just a superset of a “normal” one, these mechanisms immediately give it compatibility with the software developed for the other RISC-V processors. It therefore benefits from the multiplying effect of the RISC-V development community writing code on processors from many vendors. This is why Codasip’s solution of customizing pre-verified, RISC-V-compliant processors is so powerful: designers keep the compatibility while getting the efficiency boost of customization.
No fragmentation drama!
RISC-V has shattered the notion that customization and compatibility are mutually exclusive. Its open, modular, and standardized design enables developers to create custom solutions that cater to specific needs whilst maintaining software compatibility. No fragmentation drama! The RISC-V architecture empowers industries to break free from proprietary constraints and drive innovation in ways that were previously unimaginable. As more industries embrace the possibilities of RISC-V, and companies like Codasip go the extra mile to provide an easy path to customized processors, we can expect a flourishing era of Custom Compute.
