Skip to content
STIMSMITH

riscv_instr_registry class

CodeArtifact WIKI v1 · 5/26/2026

The `riscv_instr_registry` class is an eUVM RISCV-DV code artifact created to hold instruction-registration state and related functions that were previously static in `riscv_instr.sv`. It supports RISCV-DV instruction generation by preserving singleton-style registry behavior through an instance stored in `riscv_instr_gen_config`, and it is associated with RISCV-DV’s custom instruction factory approach that avoids slow UVM Factory lookups for large instruction sets.

Overview

riscv_instr_registry is a class introduced in the eUVM RISCV-DV port for instruction registry management. The DVCon paper describes that the original RISCV-DV SystemVerilog source had statically scoped variables in riscv_instr.sv used to register RISC-V instructions with the instruction generator. In the eUVM port, those variables and related functions were refactored into a separate class named riscv_instr_registry, specifically for instruction registry functionality. [registry-refactor]

Purpose

The class exists to avoid keeping instruction-registration state as global or static state in a concurrent eUVM/D-language environment. The cited paper explains that global or statically scoped variables can hurt runtime effectiveness in concurrent software because shared access requires synchronization to avoid race conditions. The eUVM port therefore moves the instruction-registration variables and functions into riscv_instr_registry. [concurrency-motivation]

Singleton-style ownership

Although the registry state was moved out of static variables, the eUVM port preserves the singleton nature of the original SystemVerilog implementation. An instance of riscv_instr_registry is created inside the singleton riscv_instr_gen_config class, matching the singleton behavior of the original static variables. [singleton-preservation]

Relationship to instruction creation

RISCV-DV implements each instruction in the RISC-V ISA as a separate class, which can require hundreds of instruction classes to be registered. The paper states that registering many classes with the standard UVM Factory makes factory creation slow because type_id::create must match class names against registered factory class names. To accelerate instruction generation, RISCV-DV implements its own custom factory. [custom-factory-motivation]

The custom factory uses riscv_instr_name_t, an enumeration that tags each instruction numerically. Factory objects are hashed using this enumeration, resulting in faster matching when instruction objects are created. [enum-hashing]

Registry operations shown in the evidence

The custom-factory listing shows instruction-registry behavior including:

  • an instruction-template map keyed by riscv_instr_name_t, represented as riscv_instr[riscv_instr_name_t] instr_template;
  • a register(riscv_instr_name_t instr_name, string qualified_name) function that records instr_registry[instr_name] = qualified_name and returns true;
  • a create_instr_list() routine that iterates over instr_registry, skips entries in unsupported_instr, creates an instruction object with create_instr(instr_name, instr_class_name), and stores the created object in instr_template[instr_name]. [custom-factory-listing]

Technical significance

Within the evidence, riscv_instr_registry is significant for two related reasons: it localizes instruction-registration state that was formerly static, making the eUVM port better aligned with concurrent execution semantics, and it participates in RISCV-DV’s optimized instruction-generation path by supporting registry data used by the custom factory rather than relying on the slower UVM Factory path for many instruction classes. [registry-refactor] [custom-factory-motivation]