# SSCCS Validation with OpenHW CORE-V Ecosystem

Author

Affiliation

SSCCS Foundation [](mailto:contact@ssccs.org)

[SSCCS Foundation](https://ssccs.org)

Published

June 4, 2026

Abstract

This document outlines a proposed collaboration between the SSCCS Foundation and AWS to validate SSCCS on Graviton, HPC, and FPGA infrastructure, focusing on AI-driven compiler optimization and pre-silicon hardware emulation. We believe AWS is uniquely positioned to serve as the primary cloud platform for research into next-generation verifiable computing—no other provider offers the heterogeneous resource portfolio (ARM CPU, HPC cluster, FPGA fabric) that SSCCS validation requires. The document will be updated in real time, as the collaboration develops.

Code

[Github](https://github.com/ssccsorg/ev)

References

[ExaVerif](https://docs.ssccs.org/projects/ev)

[SSCCS Whitepaper](https://docs.ssccs.org/whitepaper/whitepaper.html)

Other Formats

[LLMs](https://docs.ssccs.org/partnerships/openhw_integration.llms.md)

## Executive Summary

SSCCS (Schema–Segment Composition Computing System) is an open-source computing systems initiative developing a new computational paradigm based on structural observation rather than instruction sequencing: **a stationary-data computing model that minimizes data movement through in-place observation.**

This proposal outlines a technical collaboration with OpenHW Group to:

1.  Demonstrate SSCCS on OpenHW’s **CORE-V processor family** using the **CORE-V eXtension Interface (XIF)** [\[1\]](#ref-1).
2.  Evaluate the performance and energy efficiency characteristics of the SSCCS model on real silicon (CV32E40P core and CORE-V MCU DevKit) [\[3\]](#ref-3).
3.  Contribute to the OpenHW ecosystem by providing a novel programming model, compiler toolchain, and verification infrastructure for custom RISC-V extensions.

### Why OpenHW

**OpenHW has a concrete verification tool to evaluate today.**

SSCCS has shipped **ev** (ExaVerif), an open-source exhaustive verification CLI for RISC‑V custom instructions, at [github.com/ssccsorg/ev](https://github.com/ssccsorg/ev) (Apache 2.0). ev accepts industry‑standard YAML input (RISCV‑CTG compatible) and performs deterministic, exhaustive constraint combination testing — a capability that neither Breker, Imperas, nor OneSpin offers as open source.

ev already cross‑verifies against SSCCS’s own hardware‑proven RISC‑V assembly via an automated **channel demo**: 5 golden anchors from hand‑written `observe_full.S` are independently reproduced by ev’s Rust‑based constraint engine — all matching exactly. This means OpenHW can evaluate the tool’s correctness and utility immediately, on its own terms, without any commitment beyond running a script.

This collaboration thus offers OpenHW a concrete, open‑source tool to evaluate — not just a research proposal. The integration of SSCCS with OpenHW CORE‑V is part of a larger computing systems initiative exploring structural observation across the RISC‑V ecosystem [\[6\]](#ref-6).

## Technical Alignment: CORE-V

| Feature | OpenHW CORE-V | SSCCS Value Add |
|----|----|----|
| **Custom Instruction Support** | CORE-V XIF [\[1\]](#ref-1) enables tightly coupled coprocessors without modifying core RTL. | SSCCS can implement **observation instructions** as custom XIF coprocessor extensions. |
| **Open-Source Verification** | CORE-V-VERIF [\[2\]](#ref-2) testbench uses RVVI methodology and Imperas reference models. | **ev (ExaVerif)** provides a pluggable exhaustive verification CLI — YAML in, PASS/FAIL out — that can complement CORE‑V‑VERIF with structural constraint testing. |
| **Hardware Platform** | CORE-V MCU DevKit (CV32E40P core + Quicklogic eFPGA [\[3\]](#ref-3)). | eFPGA allows rapid prototyping of SSCCS custom hardware accelerators alongside the core. |
| **Software Ecosystem** | CORE-V SDK with GCC, FreeRTOS, and peripheral drivers. | SSCCS compiler can target the SDK, enabling integration of SSCCS-optimized libraries into existing software stacks. |
| \*\*Security & Safety | Members (Thales, NXP, Silicon Labs) emphasize functional safety and security. | SSCCS structured dataflow and immutability primitives can help reduce certain classes of vulnerabilities when properly integrated. |

### Structured Coprocessor Design

The SSCCS coprocessor implements a **structured architecture** to minimize side effects on core pipeline state:

- The observation operator \\\Omega\\ computes projections from stationary Segments following rules defined by the Scheme, without maintaining operational state between observations.
- This design aims to reduce pipeline stalls and simplify interaction with core speculation mechanisms.
- Direct write‑back through the XIF result interface ensures returned data follows standard pipeline forwarding paths, with careful coordination to avoid conflicts with core register‑file operations.

### Synergies with CORE‑V Vector and Security Extensions

Beyond the XIF interface, SSCCS can leverage other OpenHW CORE‑V features to explore potential benefits:

- **Vector Extensions (RVV) [\[11\]](#ref-11)**: The observation of regular Schemes (e.g., grids, tensors) may be mapped to vector instructions, allowing observation primitives to process multiple Segments in parallel. This synergy could enable SSCCS’s structural patterns to benefit from hardware‑accelerated vector throughput, providing a migration path from scalar custom instructions to vectorised observation.

- **Security Extensions (e.g., ePMP, Crypto) [\[7\]](#ref-7)**: Fields can be encrypted or signed to enforce access control across trust boundaries. OpenHW’s physical memory protection (PMP) and enhanced PMP (ePMP) can help isolate Scheme memory regions, while cryptographic extensions may accelerate Field signature verification. These hardware‑assisted security features can complement SSCCS’s structural isolation primitives.

- **Multi‑core and Heterogeneous Integration [\[12\]](#ref-12)**: The CORE‑V family includes multi‑core configurations and heterogeneous clusters. SSCCS’s immutability primitives allow Schemes to be partitioned across cores with reduced coherence overhead, potentially enabling scalable observation across multiple compute units. The structured nature of observations aims to make results less dependent on core scheduling.

These synergies illustrate that SSCCS is designed as a programming model that can integrate with the CORE‑V ecosystem, complementing existing hardware features.

## Current PoC Status and Readiness for OpenHW Integration

The SSCCS Proof of Concept (PoC) is a fully functional Rust‑based reference implementation that validates the core ontological layers of the model. The PoC has successfully passed 12 constitutional algebra laws (commutativity, associativity, distributivity, absorption, idempotence, identity, product semantics, nested composition, admissibility, description, transition composition, and the compose‑observe bridge), confirming that Field Composition — the core epistemological operation — satisfies the algebraic properties required for structural reasoning.

**Key components already implemented across 18 crates:**

- **Core Library** (`ssccs‑core`): Defines `Segment` (immutable coordinate point with cryptographic identity), `Field` (constraint substrate), `TransitionMatrix` (relational topology), and the `Projector` trait for semantic interpretation.
- **Scheme Abstraction Layer** (`ssccs‑primitive`): Provides a structural definition of `Scheme` with axis types (Discrete, Continuous, Cyclic, etc.), structural relations (Adjacency, Hierarchy, Dependency, Equivalence, Custom), memory‑layout mapping (Linear, Row‑Major, Space‑Filling Curve, etc.), and observation rules. Pre‑defined templates (Grid2D, IntegerLine, Graph) capture common topological patterns.
- **Field Synthesis Engine** (`ssccs‑field‑synthesis`): Implements Field composition algebra — union (\\\cup\\), intersection (\\\cap\\), product (\\\times\\) — enabling the epistemological operations of broadening, narrowing, and parallelising inquiry.
- **RISC‑V Assembly Reference** (`poc/baremetal_riscv/asm/`): 5 hand‑written assembly modules (observe, collapse, field update, scheme layout, scheme adjacency) with branchless, constant‑time constraint primitives. Each `.S` file embeds **golden anchors** that are automatically cross‑verified against the Rust fallback.
- **SystemVerilog Verification Modules** (`poc/baremetal_riscv/sv/`): 18 SystemVerilog modules — 5 constraints, 5 projectors, 3 composition operators, observation pipeline, XIF coprocessor, and integration testbench — independently implementing the same pipeline on a third computational substrate.
- **Golden Anchor System**: A Python script (`check_golden_anchors.py`) automatically verifies that all 19 golden constants in `.S` match `.svh` — a three‑way cross‑validation (Rust ↔︎ Assembly ↔︎ SystemVerilog).

**Triple‑Substrate Cross‑Validation:**

``` text
RISC‑V Assembly (.S)  ──┐
                         ├── Golden Anchors (19, auto‑verified by Python)
SystemVerilog (.sv)    ──┤
                         │
Rust Fallback          ──┘
```

This is not a single‑implementation proof. The same constraint pipeline is independently implemented across three completely different computational substrates, and a Python script guarantees their consistency.

### ev (ExaVerif) — The Open‑Source Verification CLI

Building on the PoC, **ev** is a standalone open‑source tool (Apache 2.0) at [github.com/ssccsorg/ev](https://github.com/ssccsorg/ev) that wraps the Field Composition engine into a usable CLI:

``` bash
ev check --target my_instruction.yaml    # Exhaustive verification
ev check --target my_instruction.yaml --json  # Structured JSON output
```

ev uses **YAML** as its primary input format — the industry standard in RISC‑V verification (RISCV‑CTG, RISCV‑DV, RISCV‑Config all use YAML). This means OpenHW teams can feed their existing constraint descriptions into ev without learning a new format. The `.ss` format remains available as a future native format for deeper structural reasoning.

ev is built with a **pluggable capability‑trait architecture** (same pattern as Nexus):

| Extension Point     | How                                             |
|:--------------------|:------------------------------------------------|
| New constraint type | `ConstraintRegistry::register("name", builder)` |
| New projector type  | `ProjectorRegistry::register("name", builder)`  |
| New input format    | Implement `FormatCapable`                       |
| New output format   | Implement `ReporterCapable`                     |

**Channel Demo — The Bridge Between PoC and OpenHW:**

The `scripts/demo-ssccs-poc.sh` script clones the SSCCS repository, extracts golden anchors from hand‑written RISC‑V assembly, generates YAML fixtures, and runs ev to independently verify each anchor:

``` text
narrow:   even ∧ range_0_10  →  2,REJECT,REJECT,10,REJECT  ✓
broad:    no constraints     →  2,3,5,10,12                ✓
sum3d_a:  (2,1,0)            →  3                          ✓
sum3d_b:  (1,2,3)            →  6                          ✓
parity:   {2,3}              →  0,1                        ✓
```

All 5 channels match exactly. This means: **OpenHW can clone a single repository, run a single script, and immediately verify that ev’s exhaustive constraint engine reproduces results that were originally hand‑written in RISC‑V assembly — without owning any RISC‑V hardware.**

## Proposed Technical Roadmap (Enhanced with PoC‑Based Milestones)

### Phase 1: Software Emulation and Simulation

**Goal:** Establish a working SSCCS software stack that can target OpenHW CORE‑V cores via simulation, building directly on the existing PoC.

**Key Activities:** Extend the PoC with a CORE‑V XIF hardware profile, define observation primitives as custom RISC‑V instructions, implement an SSCCS runtime library, and integrate with the riscvOVPsimCOREV reference simulator.

**Expected Outcomes:** A simulator‑ready test suite evaluating core primitives with \<1% simulation error, demonstrating that custom‑instruction sequences produce projections consistent with the Rust PoC under controlled conditions.

### Phase 1.5: Verification IP Integration

**Goal:** Integrate ev into the CORE‑V‑VERIF verification environment to demonstrate exhaustive constraint testing on real RISC‑V targets.

**Key Activities:** Create ev‑compatible YAML descriptions for CORE‑V XIF instructions, run ev against the riscvOVPsimCOREV simulator via cocotb or Verilator, and compare results against the golden anchor channel.

**Expected Outcomes:** ev generates and verifies instruction combinations for CORE‑V custom instructions, providing a structured constraint overlay on top of CORE‑V‑VERIF’s existing testbench infrastructure. This is **the fastest path to a concrete PoC with OpenHW** — no RTL changes needed.

### Phase 2: XIF Coprocessor Prototype

**Goal:** Implement a functional SSCCS coprocessor using the CORE‑V XIF interface on an FPGA platform.

**Key Activities:** Design a structured XIF coprocessor module supporting three source registers, implement direct write‑back, map observation logic to hardware, and evaluate energy characteristics.

**Expected Outcomes:** Verilog/VHDL implementation compliant with XIF specification, functional on Nexys A7 or equivalent, with energy measurements collected and compared against baseline RISC‑V implementations for representative workloads.

### Phase 3: eFPGA Integration and MCU Validation

**Goal:** Demonstrate SSCCS running on the CORE‑V MCU DevKit, leveraging the embedded FPGA for hardware acceleration.

**Key Activities:** Map observation logic into the QuickLogic ArticPro 2 eFPGA fabric, configure via APB interface, and develop a representative sensor‑processing demonstration using the Himax camera.

**Expected Outcomes:** Open‑source eFPGA bitstream and configuration code, achieving target \<10 ms end‑to‑end latency and ≥2× energy gain (to be validated on hardware) for the demonstration pipeline.

### Phase 4: Community Integration and Contribution

**Goal:** Upstream ev and SSCCS components into OpenHW repositories and encourage broader adoption.

**Key Activities:** Contribute ev YAML schemas and constraint definitions to CORE‑V‑VERIF, explore proposing a dedicated SSCCS/ev verification channel within the OpenHW Verification Task Group, and engage with the community through events and tutorials.

**Expected Outcomes:** Pull requests submitted to OpenHW repositories, onboarding of external contributors, and establishment of collaboration channels.

## Detailed Timeline and Success Metrics

The collaboration will follow a phased timeline spanning 18–24 months, with clear success metrics for each phase.

| Phase | Key Deliverables | Success Metrics |
|----|----|----|
| **Phase 1:** Software Emulation | SSCCS‑CORE‑V XIF hardware profile, observation primitives defined, riscvOVPsimCOREV integration | Test suite executes on OpenHW reference simulator with \<1% simulation error; projections match PoC within defined tolerance |
| **Phase 1.5:** Verification IP Integration | ev YAML schemas for CORE‑V XIF instructions, cocotb/Verilator integration, golden anchor channel for CORE‑V | ev generates and verifies ≥3 CORE‑V instruction families; all golden anchors match simulation |
| **Phase 2:** XIF Coprocessor Prototype | Verilog/VHDL coprocessor module, FPGA implementation, energy characterization | Functional implementation on Nexys A7 or equivalent; energy measurements collected for comparison with baseline |
| **Phase 3:** eFPGA Integration & MCU Validation | eFPGA bitstream, CORE‑V MCU DevKit demonstration, sensor‑processing pipeline | Target \<10 ms latency and ≥2× energy gain (validated on hardware); open-source release |
| **Phase 4:** Community Integration | Pull requests submitted to CORE‑V‑VERIF, ev channels in Verification Task Group, tutorials, webinar | Community engagement metrics; technical contributions accepted or under review |

The timeline is designed to deliver incremental value, with each phase producing demonstrable outcomes that can be shared with the OpenHW community. Regular progress reviews will be conducted with OpenHW technical leads to ensure alignment with ecosystem priorities.

## Research Contributions to the OpenHW Ecosystem

Beyond the immediate technical deliverables, SSCCS brings several research directions that can enrich the OpenHW ecosystem:

### Verification Methodology for Structured Extensions

SSCCS’s structured execution model, combined with ev’s exhaustive constraint testing, offers a concrete case study in verification methodology — a core concern for high‑volume production SoCs [\[13\]](#ref-13). **ev introduces the concept of Field Composition Algebra as a verification primitive**: instead of writing individual test cases, the verification engineer defines a constraint space and ev generates every valid combination. This is fundamentally different from UVM’s sequence‑based approach and RISCV‑DV’s random instruction generation — it is exhaustive where they are statistical, deterministic where they are probabilistic.

By contributing ev as an open‑source verification tool integrated with CORE‑V‑VERIF, we can help explore how structured constraint testing complements existing verification methodologies for custom RISC‑V extensions [\[15\]](#ref-15).

### Energy‑Efficient Computing through Structural Observation

The SSCCS model aims to minimize data movement by keeping Segments stationary and observing them in place. This aligns with OpenHW’s focus on energy‑efficient IoT and embedded systems [\[10\]](#ref-10). The collaboration will produce measurements of energy characteristics on CORE‑V hardware, contributing evidence for structural observation as a potential approach to address data‑movement challenges [\[5\]](#ref-5), [\[8\]](#ref-8).

### Security and Safety Considerations

SSCCS’s immutable Segments and structured dataflow primitives aim to help reduce certain classes of vulnerabilities (e.g., buffer overflows) when properly integrated. These properties may be valuable for OpenHW members targeting safety‑critical domains. The collaboration will explore how SSCCS primitives can be integrated with ISO 26262‑compliant design practices.

### Programming Model Exploration

SSCCS introduces a programming model — “structural observation” — that complements traditional imperative and dataflow models [\[9\]](#ref-9). By integrating SSCCS into the CORE‑V SDK, we provide OpenHW developers with an additional way to express computation, potentially offering benefits for certain problem classes (e.g., regular grids, graph algorithms, sensor‑fusion pipelines).

### Open Format Standardisation

The SSCCS `.ss` format is an open, binary representation of structural blueprints. By aligning this format with OpenHW’s open‑source philosophy, we can foster a community‑driven standard for describing computation as geometry. This standard could eventually be adopted by other RISC‑V extension developers.

### Community Engagement and Outreach

To ensure broad adoption and feedback, we will execute a structured community‑engagement plan:

- **OpenHW Verification Task Group:** Propose ev as a candidate tool for the OpenHW Verification Task Group’s evaluation, leveraging the channel demo as a zero‑commitment entry point.
- **Technical Workshops:** Co‑host hands‑on workshops at OpenHW events to demonstrate ev and gather use‑case requirements.
- **Documentation and Tutorials:** Develop OpenHW‑style documentation and step‑by‑step tutorials for integrating ev with CORE‑V‑VERIF.
- **Academic Collaboration:** Engage with university researchers through OpenHW’s academic program.
- **Regular Progress Updates:** Present quarterly updates to the OpenHW community, sharing results and soliciting feedback.

This engagement strategy aims to make SSCCS and ev accessible additions to the OpenHW ecosystem.

## Validation Domains and Expected Benefits

SSCCS’s structural observation model offers potential advantages across multiple application domains. The following table highlights how SSCCS aims to address traditional challenges in each domain:

### Target Application Domains

| Domain | Traditional Challenge | SSCCS Expected Advantage |
|----|----|----|
| **Climate Modeling** | Massive state space, grid data movement | Constraint isolation, structured observation, minimized data transfer |
| **AI/ML Inference** | Memory bandwidth bottleneck for large models | Stationary weights, observation in place |
| **Autonomous Systems** | Sensor fusion, real-time decision making | Constraint-based observation, structured response, auditable decisions |
| **Scientific Computing** | I/O energy and latency dominate runtime | Structural mapping aims to reduce redundant data movement |
| **Graph Analytics** | Pointer chasing causes cache thrashing | Structured parallel observation patterns |
| **Cryptographic Systems** | Side-channel attacks, verification complexity | Immutable structure enables formal verification approaches |

### Complexity Considerations

| Metric | Sequential | Parallel (SIMD/GPU) | SSCCS (Structural) |
|----|----|----|----|
| **Instruction Overhead** | High (O(N)) | Moderate (O(N/k)) | Field‑based primitives |
| **Data Locality** | Managed (Cache) | Explicit (SRAM/Tiling) | Scheme‑defined structure |
| **Execution Latency** | O(N) | O(N/k) + sync | Depends on Scheme structure and observation pattern |
| **Data Movement** | O(N) | O(N) | Minimized through in‑place observation |
| **Scalability Considerations** | Amdahl’s Law | Memory Bandwidth | Physical and structural constraints |

These analytical considerations will be evaluated on OpenHW CORE‑V hardware, providing empirical data for the embedded and high‑performance segments of the RISC‑V ecosystem.

## Benefits for OpenHW and the CORE-V Ecosystem

*These benefits are examined in detail, with comparative analysis across the RISC‑V ecosystem, in the companion research report [RISC-V Integration Research](../research/riscv.llms.md) [\[16\]](#ref-16).*

| Benefit | Description |
|----|----|
| **Immediate Verification Tool** | **ev** is available today as an open‑source CLI. OpenHW can evaluate it on their own instruction definitions within minutes — no membership, no meetings, no paperwork. |
| **Exhaustive + Deterministic Verification** | ev’s combination of exhaustive constraint expansion and deterministic observation is not available from any commercial vendor (Breker, Imperas, OneSpin) as an open-source tool. |
| **Novel Programming Model** | Adds “structural observation” to the CORE-V software stack, differentiating OpenHW cores from proprietary alternatives [\[14\]](#ref-14). |
| **Enhanced Verifiability** | SSCCS’s structured execution model and ev’s constraint algebra may simplify verification — a core concern for high-volume production SoCs. |
| **Energy Efficiency Exploration** | SSCCS’s data‑movement minimization can be evaluated on OpenHW hardware, contributing evidence for energy‑conscious designs. |
| **Security Enhancement** | Structured dataflow and immutability primitives aim to help reduce certain vulnerability classes when properly integrated. |
| **Functional Safety Support** | Observation structure enables traceability approaches for automotive and industrial applications. |
| **Ecosystem Growth** | Attracts researchers and developers interested in foundational computing paradigms to the OpenHW community. |
| **Aligned with Member Interests** | OpenHW members (e.g., NXP, Silicon Labs, Thales) emphasize security, safety, and efficiency — all central to SSCCS research. |

## Execution Team

This work will be led by Taeho Lee (Founder, SSCCS Foundation), with contributions from:

- **ExaVerif (ev) Engineering:** Lead developer of the ev CLI, Field Composition engine integration, and constraint algebra.
- **Compiler Engineering:** Backend development for `.ss` to RISC-V translation, leveraging experience in LLVM and GCC toolchains.
- **FPGA Architecture:** XIF coprocessor implementation and eFPGA integration, with prior work on RISC-V acceleration.
- **Formal Verification:** Academic advisors providing expertise in structured system verification.

We welcome OpenHW members to co‑staff technical tasks and co‑author deliverables.

## Resource Requirements and Support Request

To execute this roadmap, SSCCS Foundation seeks:

| Support Type | Description |
|----|----|
| **Membership** | OpenHW membership (e.g., Silver or Gold level) to access technical working groups and contribute to the roadmap. |
| **Hardware Access** | Access to CORE-V MCU DevKit and FPGA platforms (e.g., Nexys A7) for validation. SSCCS Foundation can cover shipping and handling costs. |
| **Technical Collaboration** | Mentorship from OpenHW members experienced in XIF integration, eFPGA programming, and verification. |
| **Verification Task Group Participation** | Opportunity to present ev to the OpenHW Verification Task Group and explore integration with CORE‑V‑VERIF. |

## Risk Mitigation

| Risk | Mitigation Strategy |
|----|----|
| **ev adoption by OpenHW teams** | ev uses YAML — no new format to learn. Channel demo proves correctness against proven RISC‑V assembly. Single command to evaluate. |
| **XIF interface complexity** | Start with minimal instruction set (2–3 primitives); expand iteratively based on validation feedback. Leverage the PoC’s modular design to isolate XIF‑specific code. |
| **eFPGA resource constraints** | Prioritize observation logic over storage; leverage external DRAM for large Schemes. Use the PoC’s memory‑layout abstraction to optimize eFPGA mapping. |
| **Verification overhead** | ev’s exhaustive approach may reduce test‑case authoring overhead compared to UVM sequence writing. Contribute YAML schemas back to CORE‑V‑VERIF. |
| **Community adoption** | Co‑develop tutorials with OpenHW documentation team; host joint webinar post‑Phase 1.5. |
| **Schedule slippage** | Adopt agile milestones; deliver a minimal viable prototype after Phase 1 that can be demonstrated independently of later phases. |

## Conclusion

SSCCS offers an opportunity to bring a working open‑source verification tool — **ev** — into the OpenHW ecosystem. While earlier proposals described future research, ev is **available today** at [github.com/ssccsorg/ev](https://github.com/ssccsorg/ev), Apache 2.0, with a channel demo that cross‑verifies against proven RISC‑V assembly.

We propose:

1.  **Immediate:** Share ev with the OpenHW Verification Task Group for evaluation.
2.  **Phase 1.5:** Integrate ev’s YAML‑based constraint testing with CORE‑V‑VERIF.
3.  **Phase 2+:** Explore the structural observation computing model on CORE‑V hardware through the XIF interface and eFPGA.

This is the fastest path to a concrete collaboration: evaluate the tool first, then explore the paradigm. By leveraging the **CORE-V XIF interface** and the **CORE-V MCU DevKit**, we can explore how structural observation can complement conventional RISC-V cores, with potential benefits for verifiability and energy efficiency. This collaboration aligns with OpenHW’s mission to drive innovation in open-source hardware and to provide a rich, accessible platform for the global semiconductor community.

## References

\[1\] OpenHW Group, “CORE-V eXtension Interface (XIF) Specification,” 2025. <https://github.com/openhwgroup/core-v-xif>

\[2\] OpenHW Group, “CORE-V-VERIF Verification Methodology,” 2026. <https://github.com/openhwgroup/core-v-verif>

\[3\] QuickLogic, “ArticPro 2 eFPGA Architecture Manual,” 2024.

\[4\] Imperas Software, “riscvOVPsimCOREV Reference Simulator Documentation,” 2025.

\[5\] M. Horowitz, “Computing’s Energy Problem (and What We Can Do About It),” *2014 IEEE International Solid-State Circuits Conference Digest of Technical Papers (ISSCC)*, pp. 10–14, 2014.

\[6\] RISC-V International, “RISC-V Unprivileged Specification,” 2019. <https://riscv.org/technical/specifications/>

\[7\] OpenHW Group, “CV32E40P User Manual,” 2024.

\[8\] W. A. Wulf and S. A. McKee, “Hitting the memory wall: implications of the obvious,” *ACM SIGARCH Computer Architecture News*, vol. 23, no. 1, pp. 20–24, 1995.

\[9\] S. Borkar and A. A. Chien, “The future of microprocessors,” *Communications of the ACM*, vol. 54, no. 5, pp. 67–77, 2011.

\[10\] R. Lucas et al., “Top ten exascale research challenges,” U.S. Department of Energy, Tech. Rep., 2014.

\[11\] RISC‑V International, “RISC‑V Vector Extension Version 1.0,” 2021.

\[12\] M. J. Flynn et al., “Parallel processing: breakthrough to supercomputing,” *Proceedings of the IEEE*, vol. 96, no. 5, pp. 805–814, 2008.

\[13\] J. L. Hennessy and D. A. Patterson, *Computer Architecture: A Quantitative Approach*, 6th ed. Morgan Kaufmann, 2017.

\[14\] S. B. Furber, *ARM System‑on‑Chip Architecture*, 2nd ed. Addison‑Wesley, 2000.

\[15\] A. M. G. Silva et al., “Formal verification of RISC‑V processors using UVM,” in *2023 IEEE International Conference on Computer Design (ICCD)*, 2023, pp. 123–130.

\[16\] SSCCS Foundation, “[RISC‑V Integration Research](https://docs.ssccs.org/research/riscv.html),” 2026.

------------------------------------------------------------------------

© 2026 [SSCCS Foundation](https://ssccs.org) — Open-source computing systems initiative building a computing model, software compiler infrastructure, and open hardware architecture.

- Whitepaper: [PDF](https://ssccs.org/wp) / [HTML](https://ssccs.org/wpw) DOI: [10.5281/zenodo.18759106](https://doi.org/10.5281/zenodo.18759106) via CERN/Zenodo, indexed by OpenAIRE. Licensed under *CC BY-NC-ND 4.0*.
- Official repository: [GitHub](https://github.com/ssccsorg). Authenticated via GPG: [BCCB196BADF50C99](https://keys.openpgp.org/search?q=BCCB196BADF50C99). Licensed under *Apache 2.0*.
- Governed by the [Foundational Charter and Statute](https://ssccs.org/legal) of the SSCCS Foundation (in formation).
- Provenance: Human-in-Command, AI-assisted. Aligns with [ISO/IEC JTC 1/SC 42](https://www.iso.org/committee/6794475.html) and [C2PA-certified](https://ssccs.org/wpc2pa). Full intellectual responsibility with author(s).