RISC-V Advantage in Accelerator Control Highlights System Verification Challenges

When considering best-fit applications for RISC-V, the appeal of extending the instruction set and competitive pricing for storage and edge applications has been pretty clear. But I have always struggled to understand the appeal in head-on competition with Arm in premium applications such as servers and infrastructure systems. There may still be a price argument but how much difference can there really be in a specialized ISA for big infrastructure, aside from geopolitical sensitivities? Dave Kelf (CEO, Breker) introduced me to a use-case I hadn’t considered which looks like a perfect fit for RISC-V: embedded controllers in accelerators. In what follow I’ll talk about AI accelerators, both topical and a good example of the need.

Recap – AI accelerators and the need for a controller

The accelerators themselves are just big matrix engines, commonly single instruction multi-data (SIMD) in CPUs processing vectors in parallel, or single-instruction multi-thread (SIMT) in GPUs processing multiple threads in parallel. Neither is optimized for the control aspects of such processing: loading parameters and input data, postprocessing and returning output data. Those tasks have been delegated to CPU clusters (often Arm-based) which work well for that purpose, apart from latency between the controller cluster and the accelerator.

That latency might not be so bad if input and output were one-time activities, but matrix engines aren’t arbitrarily large so must window their way across data, also recent models such as transformers and recurrent are inherently iterative, storing intermediate calculations in some kind of scratch memory. Control is more tightly coupled to calculation and latency between control and the matrix engines becomes much more important. Controllers embedded in the accelerator are very attractive here, allowing for simple protocol connectivity within the accelerator rather than powerful but higher latency NoCs. Arm clusters will likely remain important in a supervisory role but not in tight loop iteration.

SIMT is the easier model for programmers – regular multi-thread programming with hardware support – but must deal somehow with divergent branches, where a thread may take a branch that other threads do not. As in any multi-threaded process, maintaining coherency between divergent threads is very important. We know how this works in a conventional CPU cluster with a cache coherent network but here low latency in the accelerator demands a specialized controller and specialized verification.

Coherency is one obvious example where comprehensive IP verification plus system connectivity checking alone is insufficient for system-level verification. Further, AI accelerators are known for specialized optimizations like broadcast to accelerate parameter updates. In general, integration-level fabrics or optimizations must be verified together with the IPs they connect, in-system.

Clearly this is a system verification problem with accelerator, embedded controller, scratch memory, and unique fabrics must be verified using system workloads. As is common in system verification, these workloads will be synthetic rather than real loads, designed to stress behaviors likely to be challenging as determined by designer/architect insight.

Breker extends its System VIP portfolio

Breker has a nice fit to meeting this need. They are already well established in RISC-V verification, particularly (in this context) in system-level verification with their System Ready options for RISC-V, similar to the SystemReady concept for Arm. They also have modules for cache and I/O coherency checking. Now they are actively involved with customers in extending this library to add AI/GPU testing with what looks like a very extensive set of tests around thread divergence, convergence, work groups, barriers, atomics and more. For more info on Breker system verification techniques around RISC-V, check this out.

Naturally users can build their own tests on top of these tests; Breker’s test synthesis approach ensures that user-defined scenarios merge together with Breker library components for comprehensive stress testing. This is particularly apparent in multi-thread verification where tests can cross between all these test function components to truly stress behavior.

I have mentioned before that Breker are working with MooresLab (the agentic system guys who go from spec to verification) to extend that capability to system level testing. I’m told they will be jointly demoing some of this work in the MooresLab booth (826) at DAC 2026. MooresLab say they will be demoing Breker capabilities alongside their own spec-drive verification.

Also Read:

Agentic AI and the Future of Chip Design: From Productivity Tool to Engineering Partner

CEO Interview with Dave Kelf, CEO of Breker Verification Systems

Breker Hosts an Energetic Panel on Spec-Driven Verification