How to Verify Complex RISC-V–based Designs?
In short: Verifying a RISC-V design has two parts: prove the core is correct and ISA compliant, and prove the whole system built around it works. As the system grows with more cores, peripherals, and custom hardware, RTL simulation alone gets too slow. Transaction-level hardware emulation (ideally on the Accellera SCE-MI standard), with an ISS golden model and a reusable UVM testbench, lets you run long tests fast and even co-verify hardware and software together.
As RISC-V matures and shows up in more SoCs and microcontrollers, the hard part of verification is not the RISC-V core itself but the system built on and around it. That work is just as complex and time-consuming as verifying, say, an Arm-based project. So far, industry effort has focused on ISA compliance to standardize the core. The newer question is how to handle verification as the system grows, which gets harder with multiple cores plus off-the-shelf peripherals and custom modules. This post explains RISC-V verification for complex designs: how to verify the core and the whole system built around it.
A simple way to picture it
Think of testing a new car engine. First you prove the engine alone meets the standard: you run it on a test bench and compare its readings against a reference engine you already trust (that is the ISA-compliance check against a golden model). But a car is more than an engine. You still have to prove the whole car works: gearbox, brakes, electronics, and the driver’s software all together. Doing that by pushing the car around the yard by hand (pure RTL simulation) is far too slow, so you move it onto a fast rolling road (an emulator) where you can drive it for hours of simulated road in minutes. That fast rolling road is what makes full RISC-V system verification practical.
Two verification challenges
- The core: make sure the RISC-V core is correct and ISA compliant.
- The system: test the whole system that uses the core, including other cores, peripherals, and custom hardware.
For both, transaction-level hardware emulation is a strong choice, especially when it is based on the Accellera SCE-MI standard, which lets you reuse the setup across different platforms and vendors. Combined with automatic design partitioning and wide debugging, that gives a complete verification platform.
Verifying the RISC-V core with emulation
When the core grows more powerful and gains functionality, RTL simulation is not enough and cannot give complete coverage in a reasonable time. Emulation runs much faster (in the MHz range), and because it stays cycle accurate, you can make tests longer and more complex while still finishing quickly.
During emulation, the core can be compared automatically against a RISC-V instruction set simulator (ISS) golden model to confirm it is accurate and ISA compliant. Figure 1 shows a RISC-V CPU under test: a UVM testbench in the simulator (test data, sequencers, drivers, an ISS, a scoreboard, and a monitor) connects through DPI-C and SCE-MI to the RISC-V RTL running in an FPGA emulator with an AXI interconnect and RAM.
The testbench you build for simulation can be reused for emulation, so it is worth making the testbench “emulation ready” while you are still at the simulation stage. That lets you switch between simulator and emulator without writing a new testbench. It also pays off when you add custom instructions to the RISC-V (to speed up algorithms), because hardware emulation lets you test and benchmark those instructions against your algorithms faster than pure simulation. For how to build a reusable testbench, see our UVM guides.
Verifying the whole system
Once the CPU or CPU subsystem is checked, you move on to the whole system. The same technique works for the other SoC hardware, custom hardware, and peripherals: implement them in the emulator and verify them with the same UVM or SystemC testbench used in simulation (see Figure 2).
This approach supports long test sequences, for example UVM constrained-random tests, to build complicated scenarios, and it supports accelerated SoC benchmarking so you can tune the hardware structure and components. For a refresher on constrained-random stimulus, see our directed vs constrained-random guide.
Bringing hardware and software together
SoC projects today need not just hardware but complex, multilayer software. That means hardware and software teams work on the same project with tricky requirements at the software-hardware boundary. Software teams usually start in isolation using a software ISS or a virtual platform, which is enough while they do not depend on the new hardware. But as the system grows with peripherals and custom modules, the software must support the RISC-V and its surroundings plus the rest of the hardware, through operating-system drivers, an API, and high-level apps. The question becomes: how do the hardware and software worlds stay synchronized while both are being built and tested?
The answer is again transaction-level emulation. A hardware emulator runs all RTL modules quickly with flexible debug, and its host-interface API (usually C/C++) lets you connect the software team’s virtual platform to create one integrated environment for both domains (see Figure 3).
With this setup, the whole system runs at MHz speeds, so an operating system that took hours to boot in pure simulation now boots in minutes, and you can debug the processor and hardware subsystems in parallel.
Why hybrid co-emulation helps
- Software engineers keep their usual virtual platform as the main development vehicle; they do not switch to a new environment when the RTL matures.
- Thanks to co-emulation, that virtual platform now represents the complete SoC, including custom hardware.
- Both teams work on the same revision of the project and check correctness and performance without waiting on each other.
- Problems are found much earlier in the project, which lowers the overall cost of the verification tools.
- The stronger hardware debug in emulation means RTL bugs can be diagnosed without rolling back to simulation.
What about FPGA prototyping?
A fair question is why not just use FPGA prototyping. The reason is timing. Prototyping needs the whole RTL to be ready and synthesizable to FPGA for every system element, which takes a long time, so the software team would be stuck working on virtual models alone until then. Even once the RTL is ready, giving prototyping hardware to every software developer can be costly. Co-emulation lets you verify the whole system and find problems much earlier while keeping tool cost down. Once that is done, FPGA prototyping is still very useful for high-speed final testing.
Simulation, emulation, and prototyping compared
| Aspect | RTL simulation | Hardware emulation | FPGA prototyping |
|---|---|---|---|
| Speed | Slow (Hz to kHz) | Fast (MHz) | Fastest (tens of MHz or more) |
| When available | From day one | Early, once RTL blocks exist | Late, needs full synthesizable RTL |
| Debug visibility | Very high | High | Lower |
| Best for | Block-level checks, early bring-up | Long tests, system verification, HW/SW co-verification | High-speed final testing |
| Testbench reuse | UVM/SystemC testbench | Same testbench if made emulation ready | Limited; runs standalone |
| Cost per developer | Low | Moderate (shared) | High (hardware per developer) |
Common mistakes when verifying RISC-V systems
- Stopping at ISA compliance and assuming the system around the core is fine.
- Building a testbench that is not emulation ready, so you must rewrite it to move from simulator to emulator.
- Delaying hardware and software integration until late, so boundary bugs surface near tape-out.
- Relying only on RTL simulation for long tests, which is too slow for full coverage.
- Jumping straight to FPGA prototyping before the RTL is complete, leaving software teams blocked.
- Not comparing the core against an ISS golden model, so compliance gaps slip through.
Expected result, in plain words
This is a methodology overview, not a single tool run. In practice, the core should match its ISS golden model with no compliance failures, long constrained-random tests should run in the emulator in minutes rather than hours, and an operating system should boot at MHz speeds so hardware and software teams can debug in parallel on the same project revision. Actual speeds and boot times depend on your emulator, design size, and setup, so confirm the numbers on your own platform. This material follows the EETimes article “How to verify complex RISC-V based designs”.
Frequently asked questions
What are the two challenges in verifying a RISC-V design?
First, proving the RISC-V core is correct and ISA compliant. Second, proving the whole system built around it works, including other cores, off-the-shelf peripherals, and custom hardware.
Why is RTL simulation not enough for complex RISC-V systems?
As the core and system grow, RTL simulation is too slow to give complete coverage in a reasonable time. Emulation runs in the MHz range and stays cycle accurate, so tests can be longer and more complex while finishing quickly.
What is the role of the RISC-V ISS golden model?
During emulation the core is compared automatically against a RISC-V instruction set simulator (ISS) golden model to confirm it is accurate and meets ISA-compliance requirements.
Why should the testbench be emulation ready?
Because the same testbench built for simulation can then be reused for emulation. Making it emulation ready at the simulation stage lets you switch between simulator and emulator without writing a new testbench.
What is the Accellera SCE-MI standard and why does it matter?
SCE-MI is a transaction-level standard for connecting a testbench to an emulator. Basing emulation on it allows reuse across different platforms and vendors, which makes a more complete and portable verification platform.
What is hybrid co-emulation?
It connects the software teams virtual platform to the hardware emulator through a host-interface API, creating one integrated environment. The whole system runs at MHz speeds, so an operating system can boot in minutes and hardware and software can be debugged in parallel.
Why not just use FPGA prototyping instead?
Prototyping needs the entire RTL to be ready and synthesizable, which takes a long time and blocks the software team. It can also be costly to give prototyping hardware to every developer. Co-emulation finds problems earlier and at lower cost; prototyping is still useful for high-speed final testing.
How are custom RISC-V instructions verified?
With hardware emulation you can test and benchmark custom instructions, which are added to speed up algorithms, against the developed algorithms much faster than in a pure simulation environment.
