Open Collections

Freiberger, Brandon

University of British Columbia

Adding application-specific custom extensions to a system is a common way to gain performance. However, these extensions are generally created in isolation without mutual co-existence in mind, and may conflict with each other when composed together in the same system. For example, one of the main contributing factors is that different extensions may use the same op- codes. Although a regulatory body could allocate different opcodes for each extension, this resource is limited and cannot be provided indefinitely. The Draft CX Specification addresses this by describing a hardware mechanism for bank-switching the custom opcode space among multiple accelerators. The CX accelerator model is very powerful; each accelerator is allowed to use the entire custom opcode space, and may contain one or more distinct copies of state context. However, the Draft CX Specification is missing a programming model (API) that allows users to discover, use, and share these accelerators (and their state contexts) among multiple libraries and processes. This thesis proposes an API and corresponding modifications to the Linux kernel to manage multiple custom instruction extensions and their state contexts in RISC-V. The API uses an integer-sized quantity called a selector to identify the underlying accelerator and corresponding state con- text. Selectors use an open/select/close model similar to Linux kernel file descriptors to acquire, use, and free an accelerator and context. The API also assigns four different virtualization types to a state context; these types in- form the OS whether a state context is held for exclusive use by a process for maximum performance, or is time-shared with other processes through lazy context-switching to enable concurrent use of the accelerator. In addition to the API contributions, this thesis introduces a new hardware approach to isolate state contexts that is simpler than the approach described in the Draft CX Specification. Intended for embedded systems, this new approach can also implement the proposed API in Linux and in bare metal environments, but it supports fewer features. The API has been implemented and tested in Linux under QEMU, as well as bare metal on an FPGA-based processor.

Text

2025-04-25

Attribution-NonCommercial-NoDerivatives 4.0 International

http://hdl.handle.net/2429/90784

Electrical and Computer Engineering

University of British Columbia

UBCV

http://creativecommons.org/licenses/by-nc-nd/4.0/