Beyond The RISC-V ISA

For chip architects and designers today, “the ISA” in RISC-V is a small consideration. The concern isn’t even choosing “the core.” Designers today are faced by a “whole system” problem—a problem of systemic complexity.

That fact is implicit in the picture that I show people to explain the UltraSoC embedded analytics architecture. It shows a block-level representation of an SoC, with a broad range of compute nodes, memory and custom logic, interconnected by a NoC. One of those compute blocks is a RISC-V processor. It’s an important component. But it’s one amongst many. RISC-V is going to be used alongside other architectures for the foreseeable future, and probably forever.

Everything will change: but we’re not faced with a binary choice.

The central question is what do we need to do to build a coherent infrastructure that supports designers in this age of systemic complexity? For example, how can we successfully use RISC-V alongside Arm processors?

There are many issues to deal with: the increasing number of systems which are not architected (in the accepted sense of the word); on the software side, ad-hoc programming paradigms; processor-processor interactions; hardware-software interactions; interconnects, NoC and deadlock; dealing with coherency.

At the top level, we need to deliver heterogeneous (ie they cope with the presence of different processors) architectural and modeling exploration systems. It should be possible to feed in run-time system data to close the loop in that environment.

The architectural tools I have described are necessary, but not sufficient.  As we implement the design, we need truly heterogeneous core tool chains – a single cockpit for the different cores in a system. This is especially true in the world of debug. Open source tools such as GDB and OpenOCD need to handle this in an efficient manner; but we must also accept that many engineers don’t trust open source tools.  They would prefer to use mature, robust commercial tools that are well supported, regularly improved, and fit for the specific purpose to which the engineer is going to put them.

Finally, there is a compelling need for tools that give engineers clear visibility of the run-time behavior of their systems – and these need open APIs so that information can be passed between the diverse parts of the toolchain. The move towards less structured and disciplined ways of working are not going away: and in many areas, such as machine learning, the chip’s behavior is inherently non-deterministic.

That creates an inevitable need for better visibility at run time, and for tools that can interpret and analyze run-time behavior – with powerful capabilities like autonomous causality detection to assist the engineer through layers of complexity that are simply beyond the human brain to comprehend unassisted.

As it builds out a new ecosystem, the RISC-V community is uniquely placed to rise to this challenge of systemic complexity. Now, we need to move our focus away from the ISA and the core, to the broader issues that are exercising the thoughts of today’s designers (and creating pain in the process!) Part of this is, as I have said, acknowledging that RISC-V will be used alongside more established architectures such as Arm long into the future. Just as importantly, we need to create a fertile environment that will encourage the development of the commercial and open source tools needed by developers of these heterogeneous systems.