RISC-V Summit

The specification of the IOPMP, I/O Physical Memory Protection Unit, is nearing stability, making it an opportune moment to introduce the IOPMP programming model to users. This presentation will demonstrate the bottom-up programming model of IOPMP in M-mode, H-mode, and VS/S-mode.
In M mode, we utilize a native library, libiopmp, while H/S/VS-mode employs the SBI for IOPMP with necessary security checks. Within libiopmp, we will explore how to group the regions of a specific device into a memory domain, which can be easily switched and shared. This clarifies why IOPMP prefers the per-device association programming model over ARM's per-rule association model.

The SBI, positioned above the libiopmp, allows the other modes to manipulate the IOPMP. A hypervisor should be able to allocate devices for a guest OS. IOPMP's memory domain offers a convenient method for associating devices with a specific guest OS.

In H/S mode, hot-plug devices may necessitate IOPMP updates. In VS mode, a guest OS typically lacks knowledge about the physical memory, so the IOPMP's updates are generally transparent. Software in the higher privileged modes helps to manipulate IOPMP(s) behind guest OS requests.

This talk covers the basics of CHERI to give a solid understanding of the technology. It covers the impact on the design of the CPU as well as how it is actually used to give memory safety, control flow integrity etc. and covers the progress with the standardization.

How Codasip verified a configurable CPU using the open source RISC-V Sail model.

The Packed-SIMD specification (P spec) is critical and integral in expanding the RISC-V ecosystem in the MCU domain and will further the development of higher value applications needing cost-efficient processing of small data parallelism for audio, voice, sound, small images, slow video, tinyML, consumer electronics, and more. 

Processors which support DSP functionality are usually used to measure, filter, or compress continuous real-world analog signals. Although many DSP algorithms can be executed on a general-purpose CPU, there will be an unacceptable loss in performance for these time-critical applications. One could use the RISC-V vector extension to greatly improve performance of these algorithms, but the vector unit is typically an order of magnitude larger than a processor which implements the P specification. 

This presentation will provide an overview of the specification, benchmarking numbers, development tools, and task group status.

Sail is a powerful language for describing a processor architecture and is already used to define a number of widely-used architectures like Arm, x86, and RISC-V.

For a Sail representation to serve as a “single source of truth” for an ISA, though, there are some unmet requirements, including comprehensive human-readable ISA documentation, as this must currently be created and maintained separately.

In addition, to make good use of Sail, some sort of transformation is required, as there are no meaningful projects that directly consume Sail. The only parser for Sail is written in OCaml. Both languages are arguably obscure enough that they present barriers to effective utilization of the RISC-V Sail specification to its full potential.

This presentation outlines alternative approaches to providing a single source of truth for the RISC-V ISA that meets the criteria of: simple format, easily parsed by both machine and human, reasonably comprehensive including providing human-readable documentation, and does not necessarily preclude the use of Sail, in which the RISC-V ecosystem has significantly invested.

This would be an update of the work done in the Unified Discovery TG. Unified Discovery TG is tasked to define a schema format intended for allowing the software to easily decide which ISA extension is present on the platform. This session shows the schema and related PoC.

Yocto project is a widely adopted standard set of tools and infrastructure for building Embedded systems, 
ranging from complex systems based on Linux to RTOS and bare-metal applications.
It's based on OpenEmbedded build technology which has supported RISC-V the architecture from its early days. 


The Yocto project has a layered architecture, which provides a scalable mechanism for adding and
customizing new hardware and software support. However, there is a balance required for the best outcome.  Core architecture support in the Core layer provides common policies for RISC-V. The architecture layer (meta-riscv) adds additional RISC-V specific customizations and holds support for many SBCs with RISC-V processors. 


The Yocto Project has gathered years of experience in deploying into a wide range of products e.g. cars, streaming devices, routers, and cameras to name a few.  It is important to leverage these learnings and benefits for the RISC-V ecosystem. This presentation will address the challenges and gaps we have for RISC-V to become tier 1 supported architecture. 


In this talk we will provide an overview of how RISC-V is supported in the Yocto project and adjacent layers. Additionally, we will describe the huge opportunity to get RISC-V supported as core architecture.  RISC-V is a fast developing architecture. An important aspect of this presentation will be how to get involved in OSS development on RISC-V.

The RISC-V custom instruction encoding space provides vendors a rich opportunity to innovate. Now, the pending Composable Extensions (CX) Task Group is planning to develop ISA and non-ISA specifications to avoid collisions in opcodes and provide uniform naming, discovery, error handling, context management, and other features that will enable vendors to create a marketplace for composition and reuse of their independently authored custom (instruction) extensions and their software libraries. Instruction set switching is a way to manage this problem. A critical missing piece of the puzzle is the end user perspective: what is the application API, how will the OS manage requests, and what are the implications on the ABI? This presentation outlines a simple plan to address these issues through an API that allows users to allocate and virtualize state context in a uniform manner. We will also discuss the presently manually enforced ABI that keeps the active selector correct at all times while providing backwards compatibility with legacy custom instructions.

During this session the attendees will learn about the goals, proposals, and status of the High Assurance Cryptography (HAC) Instruction Set Extension (ISE) for RISC-V vector CPUs. While overlapping the functionality of the ratified vector cryptography extensions somewhat, the HAC extensions will provide for better key management – including key encryption – and the possibility for microarchitectures to implement countermeasures against side-channel analysis, thus enabling the HAC instructions to provide secure cryptography in more use cases than the existing instructions. For example, when an adversary can gain close enough physical proximity to the CPU to monitor its electromagnetic emanations during operation, side-channel countermeasures are necessary for secure cryptographic implementations.

What may be of extra interest is that Barry Spinney, an active HAC task group member, is designing a proof-of-concept design of the core cryptographic functional unit, including the optional side-channel countermeasures, and intends to make it fully publicly available as open-source code. This talk will introduce Barry’s design to the audience.