Accelerate Your Applications with Tailored RISC‑V Custom Instructions

The open instruction set architecture (ISA) of RISC‑V offers unparalleled flexibility, enabling developers to design extensions that precisely fit their application requirements. While the base processor can be configured with standard extensions, the real advantage lies in creating new instructions that address specific performance or power challenges.

The Software Challenge of Fixed ISAs

Historically, ISAs were proprietary intellectual property owned by commercial vendors. Embedded developers had to benchmark multiple fixed ISAs to find the best fit for their workloads, but the inability to alter instruction semantics meant that critical optimizations—such as a dedicated encryption instruction—were impossible. This limitation often forced designers to rely solely on process scaling or peripheral integration to achieve differentiation, which can be costly and time‑constrained.

The RISC‑V ISA originated at UC Berkeley and is now stewarded by the RISC‑V International Association, a non‑profit with over 300 members. Its free, open license gives developers a clean slate: a standard core that can be extended, or a brand‑new design built from scratch.

Open ISAs attract academia, start‑ups, and large enterprises alike. They can be used in FPGAs, SoCs, or as the heart of a microcontroller, and they support a range of business models—from commercial IP to open source and custom silicon.

Leveraging RISC‑V’s Flexibility

Getting started is straightforward. A typical entry point is the 32‑bit RV32IM configuration, which includes the integer “I” and multiply “M” extensions. Simulation tools let you instantiate a base ISA, attach a memory model with realistic delays, and run C/C++ code on a virtual processor.

Using an IDE such as Eclipse and the GNU debugger (GDB), developers can profile applications, identify hotspots, and model candidate custom instructions. The resulting RTL specification and performance estimates are then fed back into the development loop.

Consider ChaCha20 encryption—a common benchmark in low‑power devices. After compiling a vanilla RV32IM binary and running a basic‑block profiler, the majority of execution time concentrates in the XOR and rotate “quarter‑round” operations (see Figure 2).

Visualization tools produce a collapsible tree of execution statistics, making it easy to spot the dominant functions—such as processWord()—and their sub‑calls (Figure 3).

Once the performance bottleneck is clear, the next step is to design custom instructions that consolidate the XOR‑plus‑rotate pattern into a single micro‑operation. Because RISC‑V is a load‑store architecture, these instructions must operate on 32‑bit registers, making them suitable for the custom‑1 opcode space.

With the ISA’s encoding rules, the lower seven bits identify the opcode, while three funct3 bits give room for eight distinct operations. Four of these—XOR plus a 7‑bit, 8‑bit, 12‑bit, or 16‑bit left rotation—suffice for ChaCha20.

Before committing to hardware, developers model these instructions in the ISS environment using the OVP VMI API. This rapid simulation step verifies functional correctness and provides a first‑hand look at performance gains.

Two approaches exist for functional validation:

1. Invoke the original C/C++ routine and bind the new instructions via inline assembly (Figure 5a).
2. Implement the instructions as VMI morph ops that reproduce the same behaviour (Figure 5b).

After recompiling the application with inline assembly, the simulator reports a dramatic reduction in instruction count and cycle time:

Results with original C implementation

Info  Simulated instructions: 316,709,013
Info  Simulated time: 5.15 seconds

Results with Custom instructions

Info  Simulated instructions: 60,474,426
Info  Simulated time: 1.38 seconds

With the new instructions, the processWord() function still consumes the bulk of runtime (≈66 %) but the overall algorithm is now three‑times faster.

Further refinement involves assigning realistic cycle latencies to each custom instruction and re‑profiling, including memory wait states that would appear in a silicon implementation.

Because the ISS integrates seamlessly with Eclipse and GDB, full debugging of both the host application and the custom ISA can be performed before hardware commitment.

From Simulation to RTL Implementation

With validated performance metrics in hand, developers translate the custom instructions into RTL. The previously generated functional model and verification plan serve as a gold‑standard reference, reducing risk during synthesis and timing closure.

Documentation follows the same workflow: OVP fast‑processor models include templated documentation that can be extended to describe new instructions. Once formatted in TeX, a PDF is generated for community reference (Figure 8).

Conclusion

RISC‑V’s open ISA unlocks a world of custom extensions that can dramatically improve application performance, reduce power consumption, and meet stringent real‑time deadlines—capabilities that fixed ISAs cannot match. By profiling real workloads, modeling custom instructions in simulation, and rigorously verifying RTL, developers can confidently bring tailored silicon to market with proven gains.