RISC-V Summit

In this talk I will present ongoing work as part of the RISC-V golden model working group to develop and maintain the Sail language and  golden reference model for the RISC-V ISA. Sail is an open-source domain-specific language for ISA design and definition, which supports many use-cases, including documentation, use as a reference simulator, relaxed-concurrency semantics, hardware verification, and more.

This talk will describe our vision for the future of the RISC-V golden model. There are many challenges faced by model developers, such as the vast ecosystem of extensions and configurable options supported by RISC-V. We also need to provide a model that is more broadly useful as a source of documentation and learning for the wider RISC-V community.
I will discuss solutions for these challenges, which we intend to address both within the golden model itself, and by co-evolving Sail language itself to better support the unique needs of RISC-V. For example, we are introducing a module system for organising RISC-V extensions, a unified configuration system that supports all the aforementioned Sail use-cases, and enhanced Asciidoctor support for documentation integration.

By presenting this talk, I also hope to be able to engage further with attendees regarding their needs from a golden model.

The Zilsd & Zclsd extensions provide load/store pair instructions for RV32, reusing the existing RV64 doubleword load/store instruction encodings. The extensions are expected to be implemented in all kinds of embedded processors, with optimal performance being reached in core with a data bus of at least 64 bit - a property commonly given in superscalar implementations. The impact on code size of this extension is discussed in detail, leading to recommendations for future compiler improvements.

We introduce the practical applications and innovative explorations of RISC-V processors in the field of graphics processing.Especially the application of RVV in graphics acceleration.

Traditional post silicon HW debug data collection involves the gathering of a snapshot of the design state at the point of failure using scan and an array dump. We propose a hardware mechanism called Debug Signal Trace (DST) that provides the ability to trace a set of design signals over multiple cycles leading to the point of the failure and to store the trace to an on-chip memory like SRAM, or to off-chip System memory. Post processing of the stored debug trace data not only gives debug visibility, but also the ability to build post silicon coverage points. Debug Signal Trace data is timestamped to correlate with instruction trace data. This extends the use-case to SW performance analysis. To ease adoption and usability, the DST control register definition mirrors that of the RISC-V Trace Control Interface which is familiar to the RISC-V debug community. DST supports signal compression to minimize the memory storage footprint. DST leverages the triggers specified in RISC-V Debug Spec while adding user configurable triggers using a select set of design signals.

The RISC-V Foundation's Olympia Performance Model is a great tool as the basis for designing a high-performance RISC-V CPU design. This session will provide a high-level overview of the Olympia Performance Model and then provide examples of how to use the model for tradeoff analysis on different RISC-V Out-of-Order superscalar designs.

With the increased usage of RISC-V processors across the whole range of SoC market segments, quality of the RISC-V processor is an increasingly important issue. Historically, processor IP has been purchased from single-source vendors who own the ISA, and this IP was assumed to be of excellent quality. However, in the RISC-V ecosystem with vendor-supplied IP, open source IP and IP developed in-house, such quality cannot be taken for granted. This creates a verification “disconnect” between SoC developers expecting high-quality IP and processor developers that do not have the verification resources of the single source processor IP vendors. This talk will discuss how dynamic and formal methods can be used together for a more thorough and efficient verification process, helping to bridge the verification disconnect. Examples of using this combined methodology on open-source cores from OpenHW Group, specifically the CV32E40 family, CVW and CVA6, will be presented, including functional coverage results. A key feature of the RISC-V ISA is its extensibility, enabling custom instructions and CSRs to be added. The combined approach will also be shown to work well in this common situation.

QEMU is an emulator that developers can developer and debug their software on it before getting the real RISC-V hardware. We observed that vectorized executables run much slower than non-vectorized ones on QEMU. From benchmarks (e.g. SPEC CPU2k6 h264), we can see that most of the execution time is occupied by RVV load/store instructions. The same observation has been reported in the QEMU community. For example, the glibc memcpy benchmark runs 2x to 60x slower than its scalar equivalent on QEMU. We aim to improve the performance of RVV instructions in QEMU, thereby reducing the execution time required for tasks such as Android bootup. In this talk, we will provide an overview of how we enhanced the performance of QEMU RVV load/store instructions and discuss future work.