Papers
Topics
Authors
Recent
Search
2000 character limit reached

RISC-V Worlds: Scalable Isolation for SoCs

Updated 6 February 2026
  • RISC-V Worlds are hardware and software constructs that define isolation domains in SoCs using unique World Identifiers (WIDs) and specialized CSRs.
  • They provide low-latency, constant-cycle access control mechanisms to support mixed-criticality, multi-tenant, and safe real-time applications across industries.
  • The implementation leverages modular World Checkers with explicit permission tables to ensure predictable area scaling, functional safety, and robust system security.

RISC-V Worlds are hardware and software constructs that enable robust, scalable partitioning, isolation, and management of multiple concurrent execution contexts—"worlds"—within a RISC-V system-on-chip (SoC). The "worlds" abstraction, reflected both in microarchitectural primitives (notably WorldGuard and World Checker mechanisms) and in ecosystem-level design patterns, is essential for supporting mixed-criticality, multi-tenant, and open experimentation in domains spanning HPC, cloud, edge, automotive, space, and IoT. Worlds are represented by small integer World Identifiers (WIDs), carried as sideband signals in bus protocols and managed via new control and status registers (CSRs) in the ISA. The implementation of RISC-V Worlds is tightly linked to system-level security, functional safety, and composability, and is the subject of active research across isolation, privilege, and resource-sharing models.

1. Formal Definition and Microarchitectural Realization

RISC-V Worlds, also referred to as WorldGuard, define a system-level isolation domain via unique World Identifiers (WIDs), assigned to every software execution context (user, supervisor, machine, hypervisor modes), as well as to non-CPU agents (DMA, accelerators, I/O). Each initiator in the SoC tags every memory and I/O request with its current WID. At the interconnect or trusted I/O boundary, a World Checker (WC) or equivalent mechanism mediates access to protected resources. Each region of the memory map is specified by an address range and a permission vector, with per-world read/write bits or explicit world–permission pairs. Access is granted if the WID matches an allowed entry for the region and operation type (read/write).

The baseline specification provides up to N=32N=32 worlds (configurable to N=128N=128 in advanced proposals), each identified by a W=log2NW=\lceil \log_2 N \rceil-bit WID field. The corresponding per-privilege mode CSRs (uWID, sWID, mWID for U-mode, S-mode, and M-mode respectively; also hslwid, vslwid for Hypervisor mode) allow explicit control of world switching and delegation. Initiator WID transitions are strictly privilege-controlled, enforced via CSR bitmasks (e.g., mwiddeleg and hwiddeleg) to satisfy hardware security requirements such as "freedom from interference" and functional safety objectives (ASIL-D, ISO 26262, ISO 21434).

At the hardware level, the World Checker occupies a fixed position in the interconnect, processes each transaction in a constant number of cycles (2 cycles for the modern explicit-permission design), and supports both contiguous (SE: Start-End) and power-of-two-aligned (TOR/NAPOT) region encoding for address matching. The checker is synthesized with tunable width and slots, and supports advanced features such as general-read bits for globally shared, read-only regions (Cunha et al., 4 Feb 2026, Pinto et al., 2024).

2. Evolution of Worlds: Motivation, Challenges, and Specification Refinements

RISC-V Worlds address a critical shortfall in traditional isolation primitives such as PMP/SPMP, which cannot distinguish non-CPU initiators, nor scale to large multi-domain, mixed-criticality deployments characteristic of automotive, industrial, or safety-critical MCUs. Worlds are specifically motivated by:

  • The need to collapse tens of virtualized ECUs onto a single MCU, with per-domain isolation
  • Hardware-enforced boundaries for mixed-criticality, third-party, or legacy applications
  • Separation across privilege levels, VM boundaries, and initiator classes (CPU, DMA, crypto, etc.)

Initial limitations in the baseline proposal included the scalability bottleneck of the $2N$-bit flat bitmap per region, inefficiency in fragmented/sparse memory maps due to TOR-only representations, and variable combinational fanout in permission checks as N increases.

Refined architectures, such as the explicit WID–permission pairing (up to KK parallel entries per slot), SE address matching, and the addition of general-read bits, provide predictable area scaling, reduced worst-case latency, and greater flexibility with little impact on synthesizable timing. The modular slot structure accommodates arbitrary address ranges and per-world permission sets, with robust area scaling (\sim5% area reduction versus baseline at N=128N=128 worlds) and constant access latency (Cunha et al., 4 Feb 2026).

The latest implementations also unify initiator-side world tagging with system-level permission checking, facilitating the interoperation of RISC-V Worlds with alternative hardware domain managers such as IOPMP and SmMTT, and providing the necessary hooks for proof-of-concept integration with mainstream open-source SoC generators (e.g., CVA6, QEMU) and hypervisors (e.g., Bao) (Pinto et al., 2024, Cunha et al., 4 Feb 2026).

3. Isolation, Security, and Functional Safety Guarantees

In certified automotive and industrial contexts, stringent requirements for cyber-physical security, functional safety, and "freedom from interference" are realized via the Worlds mechanism. Hardware-enforced world separation prevents a fault or attack in world wiw_i from compromising resources belonging to a different world wjw_j. The world transition semantics, mediated via privilege-controlled CSRs and one- or two-cycle hardware world switching (WSWITCH instructions), eliminate software-based escalation paths.

For system-level safety, the World Guard checkers are locked in M-mode at boot; their configuration cannot be altered by software of lower privilege. This static configuration model ensures that the isolation barrier meets domain certification requirements (e.g., ISO 26262/21434, ASIL-D), since world-to-resource assignments and permissions cannot be dynamically bypassed. Where hypervisor mode is present, independent worlds are established for host supervisor (HS), virtual supervisor/user (VS/VU), and correspondingly for DMA masters, with flexible assignment up to 128 concurrent domains (Pinto et al., 2024).

Area and timing analysis confirm that with the explicit-permission-table model, area scales sub-linearly with N, and constant latency (LWC=2L_{WC} = 2 cycles) is maintained, critical for real-time safety use cases where worst-case transaction delay must be statically analyzable (Cunha et al., 4 Feb 2026).

4. Worlds in Practice: Heterogeneous SoCs, Co-Design, and Mixed-Criticality Applications

RISC-V Worlds instantiate isolation boundaries not only for MCUs but also for complex heterogeneous SoCs listed in recent case studies:

  • Automotive MCUs: Provide multi-domain isolation at the initiator side, handling concurrent harts, DMA engines, crypto accelerators, and I/O (Pinto et al., 2024, Cunha et al., 4 Feb 2026).
  • Space and safety-critical systems: Platforms such as METASAT partition CPU, AI accelerators, and RISC-V-based GPU, mapping each to isolated domains with strictly enforced world boundaries and managed via hypervisors or real-time kernels (Bonet et al., 28 Feb 2025).
  • Edge/IoT systems: Sub-250 mW SoCs like HULK-V use Worlds-like tagging for PMCA cluster, host CPU, and DRAM controller separation, with fully open-source Linux + OpenMP software stacks (Valente et al., 2022).
  • FPGA/RTL research flows: Open-source toolkits such as BRISC-V, RVSoC, and Software Development Vehicles (SDV) enable rapid assembly and exploration of "worlds" with pluggable initiator, NoC, and interconnect configurations, facilitating design space exploration, prototyping, and co-design for bespoke SoCs (Bandara et al., 2019, Miura et al., 2020, Mantovani et al., 2023).

Tables below illustrate representative implementations:

Domain Initiators Max Worlds Checker Type Key Feature
Automotive CPU, DMA, Crypto 128 M-WC explicit ISO26262/21434, ASIL-D
MCU/Safety CPU, RT, I/O 32–128 S-WC, PE-WC Static config, low latency
SoC Research CPU, VPU, GPU Varies WC, IOPMP Pluggable, RTL-parametric

A critical generalization is that Worlds abstraction is sufficiently orthogonal to privilege and VM: a system may assign worlds per {hart, privilege, VM, DMA, I/O function}, supporting both coarse-grained and fine-grained partitioning.

5. Comparison with Other RISC-V Isolation Primitives

Worlds are one of several system-level RISC-V hardware primitives for isolation. They are often compared with:

  • IOPMP (I/O Physical Memory Protection): Provides domain-based memory access filtering for initiators, but scales area and access latency with the number of memory domains (LIOPMP,WC=3+(d1)L_{IOPMP,WC} = 3 + (d-1) cycles, where dd is the number of domains), and has more complex runtime configuration requirements.
  • SmMTT (Secure Memory Management Table for Target/Initiator): Supports virtualized isolation with memory frame walks, but introduces unacceptable worst-case latency for hard real-time workloads (~10–30 cycles unpredictable).
  • Standard PMP/SPMP: Hart-local privilege/domain discrimination, insufficient for system-level or non-CPU isolation.

The refined World Checker with explicit permission tables (M-WC) maintains constant 2-cycle access latency, outperforms IOPMP and SmMTT for both area and worst-case timing in safety-critical deployment, and offers sufficiently expressive region-to-world mapping for typical automotive and industrial scenarios (practical K=8 per slot suffices for domain groupings) (Cunha et al., 4 Feb 2026).

6. Open Research, Ratification, and Ecosystem Directions

The ongoing evolution of RISC-V Worlds is shaped by needs across vertically integrated domains (automotive, cloud, HPC, IoT), and is supported by open-source release of RTL artifact, software stacks, and integration with mainstream simulation/emulation platforms. Key open questions and directions include:

  • Ratification of open standards accommodating N128N \geq 128 worlds, explicit permission lists, SE/TOR/NAPOT hybrid region specification, and unified initiator tagging across all domain control mechanisms.
  • Transparent integration with distributed hypervisor environments (e.g., Bao) and mainstream software stacks without diverging from canonical Linux, real-time OS, or cloud-managers.
  • Increasing shareability and fine-grained resource allocation with predictable area scaling and sub-2 cycle latency for larger NN.
  • Harmonization across domain-specific SoC generators (CVA6, QEMU, etc.), and adaptation for formal verification and certification toolflows (Cunha et al., 4 Feb 2026, Pinto et al., 2024).

The RISC-V Worlds abstraction is actively influencing the design of future heterogeneous SoCs, co-design methodologies, and safety/security architectures across research and industry. Its open-source, scalable, low-latency, and highly composable qualities establish Worlds as a central pillar of the evolving RISC-V system landscape (Cunha et al., 4 Feb 2026, Pinto et al., 2024, Bonet et al., 28 Feb 2025).

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to RISC-V Worlds.