OpenPiton: Open-Source Manycore Framework
- OpenPiton is an open-source manycore research framework that delivers a reusable full-system hardware substrate integrating chipset, tiles, NoC connectivity, and a sophisticated cache hierarchy.
- It supports heterogeneous-core integration by enabling diverse cores—such as OpenSPARC T1 and PicoRV32—to coexist within a unified coherent memory system demonstrated through FPGA prototyping and scalable performance.
- OpenPiton serves as a benchmark platform for experimental HPC evaluation, memory-system simulation, and hardware security verification, making it central to manycore research advancements.
Searching arXiv for OpenPiton-related papers to ground the article in cited sources. Searching arXiv for "OpenPiton" and closely related terms. Using the arXiv search tool to retrieve the cited OpenPiton papers. OpenPiton is an open-source manycore research framework that functions as a reusable full-system hardware substrate rather than as a single CPU core. In the REPTILES work, it is explicitly described as the base framework that supplies the chipset, tile organization, NoC connectivity, cache hierarchy, and coherence infrastructure, while the actual processor tiles are provided by Sargantana (Oliete-Escuín et al., 6 May 2026). In JuxtaPiton, it is described as a full-system, open-source manycore research platform with mature FPGA/emulation infrastructure capable of booting full-stack Debian Linux (Lim et al., 2018). Subsequent work also treats OpenPiton as a benchmark family and experimental vehicle for memory-system research, formal security verification, static CWE-oriented RTL analysis, and LLM-based assertion generation (Esmaili-Dokht et al., 2024, Rogers et al., 2024, Ahmad et al., 2022, Menon et al., 11 Mar 2025).
1. Architectural organization
At the architectural level, OpenPiton is described in REPTILES as consisting of a chipset plus one or more tiles. The chipset connects the tiles to system peripherals such as the UART and other platform-level services. Each tile contains three NoC routers, the core, and the cache hierarchy. The cache structure is described as having private L1 instruction and data caches, a private L1.5 cache, and a shared distributed L2 cache, with the L2 implementing a directory-based MESI coherence protocol (Oliete-Escuín et al., 6 May 2026). In JuxtaPiton’s description of the original configuration, OpenPiton is a tiled manycore architecture in which each tile contains a core, an FPU, three P-Mesh NoC routers, and private/shared cache structures; the original tile uses a modified OpenSPARC T1 core implementing SPARCv9, with a 6-stage in-order pipeline, L1 instruction/data caches, an L1.5 cache, and an L2 cache (Lim et al., 2018).
| Element | OpenPiton description | Function |
|---|---|---|
| Chipset | Connects tiles to UART and platform-level services | System integration |
| Tile | Contains core, three NoC routers, and cache hierarchy | Compute and on-chip communication |
| Coherence substrate | Shared distributed L2 with directory-based MESI | Shared-memory coherence |
This organization is central to how later projects reuse OpenPiton. A recurring misconception is to equate OpenPiton with a specific processor core. The REPTILES description directly rejects that interpretation: OpenPiton provides the scalable manycore skeleton, while replicated Sargantana cores populate that skeleton as tiles (Oliete-Escuín et al., 6 May 2026). JuxtaPiton shows the same separation in a different form by replacing the original OpenSPARC T1 core with PicoRV32 while preserving the broader OpenPiton infrastructure (Lim et al., 2018).
2. Extensibility and heterogeneous-core integration
JuxtaPiton presents the first integration of a new core into the OpenPiton framework and uses that exercise to characterize OpenPiton as a coherent manycore substrate with a mature FPGA flow (Lim et al., 2018). The integration point is architecturally specific: PicoRV32 is connected behind OpenPiton’s L1.5 cache by adding transducers that convert PicoRV32 memory requests into OpenPiton L1.5 cache operations. Because of that decision, the existing P-Mesh coherence protocol is reused without modification, and the RISC-V tile becomes a coherent participant in the same shared-memory system as SPARC tiles (Lim et al., 2018).
The JuxtaPiton design also exposes interface subtleties that arise when OpenPiton is used for heterogeneous-ISA research. OpenSPARC is big-endian and RISC-V is little-endian, so the authors resolve the mismatch by flipping the outgoing and incoming data buses for the PicoRV32 core; at software level, endian-flipping macros in C code are used when interacting with shared data. PicoRV32 has no L1 cache, so the L1.5 effectively becomes its first-level cache, and both instructions and data are cached there. The paper further notes that interrupts traverse the cache hierarchy and that the PicoRV32 core is brought out of reset using an interrupt from the OpenSPARC T1 core (Lim et al., 2018).
The FPGA results quantify how far OpenPiton can be pushed toward smaller cores while retaining the same coherent substrate. On a Digilent Genesys2 board with a Xilinx Kintex-7 XC7K325T-2FFG900C using Vivado 2015.4, the OpenSPARC T1 core uses 36,756 LUTs and 24 BRAMs, whereas PicoRV32 uses 1,076 LUTs and 0 BRAMs. At tile level, the OpenSPARC T1 tile uses 64,695 LUTs and the PicoRV32 tile uses 21,862 LUTs. The maximum timing-clean frequencies reported are 109.091 MHz for the OpenSPARC T1 tile and 114.286 MHz for the PicoRV32 tile, and the board can fit 2 OpenSPARC T1 cores or 7 PicoRV32 cores (Lim et al., 2018). These results do not redefine OpenPiton’s baseline architecture; rather, they show that its coherence, cache, and FPGA infrastructure remain usable under substantial core substitution.
3. HPC-oriented adaptation in REPTILES
REPTILES uses OpenPiton as the underlying manycore infrastructure for an HPC-oriented RISC-V multicore. The evaluated prototype contains 4 Sargantana cores, and the paper explicitly states that “the cores themselves are replicated Sargantana tiles.” These tiles are connected through the OpenPiton NoC and memory system so that each tile can communicate with the shared lower-level cache hierarchy and main memory (Oliete-Escuín et al., 6 May 2026).
The evaluated FPGA system includes a 16 KB private L1 instruction cache, a 16 KB High-Performance L1 data cache, a 32 KB L1.5 cache, and a 64 KB shared L2 cache, all using 64 B cache blocks. The private cache levels are configured with 64 MSHRs, the private cache levels connect to the L2 using 64-bit NoC buses, and the platform includes 16 GB of HBM main memory and Ethernet support, enabling a software development vehicle environment with a shared filesystem for benchmarking and live demos (Oliete-Escuín et al., 6 May 2026).
A major contribution of REPTILES is the introduction of OpenPiton improvements aimed at HPC suitability. The design includes parametric NoC width ranging from 64 bits up to 704 bits, configurable cache block sizes of 64, 32, and 16 bytes for all cache levels, parametric numbers of MSHRs, configurable associativity, parallel SRAM access for the L1.5 and L2 caches, and a new connection from Sargantana to the HPDcache. The paper frames these changes as responses to performance constraints in the original OpenPiton that limit suitability for HPC workloads (Oliete-Escuín et al., 6 May 2026).
The processor side of REPTILES couples these memory-system changes with an enhanced Sargantana core. Sargantana is described as a Linux-capable 64-bit RISC-V processor implementing the RV64G ISA, previously reported to reach 1.26 GHz in 22 nm technology. The vector unit is migrated from RVV 0.7 to RVV 1.0; the current design supports most of the RVV 1.0 specification except for LMUL and vector floating-point instructions. Another key change is renaming for vector configuration instructions, which previously stalled the pipeline. Additional extensions include Sdext for debugging and Sscofpmf, which allows Linux to read performance counters through perf. The RTL simulation environment also gains save/restore support using Verilator (Oliete-Escuín et al., 6 May 2026).
Evaluation is reported along two axes. For multicore scalability, REPTILES runs the NAS Parallel Benchmarks with OpenMP over Linux on the FPGA prototype and reports suitable scalability across all evaluated benchmarks, with the 4-thread configuration achieving a speedup of 3.6× for CG and EP and an average speedup of 3.1× across the suite (Oliete-Escuín et al., 6 May 2026). For vector throughput, a vector addition benchmark with 8-bit elements on a standalone Sargantana core shows that the RVV version achieves a 9.3× speedup over the scalar version (Oliete-Escuín et al., 6 May 2026). The evaluated FPGA prototype is limited by the resource constraints of the Alveo U55 FPGA, which the paper identifies as the reason for the 4-core configuration and modest cache sizes.
4. OpenPiton as a memory-system simulation and characterization target
In the Mess framework, OpenPiton is one of three simulator targets used to demonstrate that bandwidth--latency-curve-based memory modeling can be attached to heterogeneous simulation stacks, including RTL manycore simulation (Esmaili-Dokht et al., 2024). The paper uses OpenPiton Metro-MPI as the RTL representative, alongside gem5 and ZSim, and positions this integration as evidence that Mess is not limited to higher-level simulators.
The OpenPiton configuration used there is a 64-core Ariane RISC-V system with a 16 KB 4-way L1 instruction cache, a 16 KB 4-way L1 data cache, and a 4 MB 4-way shared L2 cache. The original model used a single-cycle memory model and was later extended with a fixed-latency model; for the fixed-latency setup, memory latency is set to 170 ns (Esmaili-Dokht et al., 2024). To make RTL simulation practical, Verilator translates each tile’s RTL into a cycle-accurate C++ model, tiles are simulated in parallel, and their communication is handled through MPI (Esmaili-Dokht et al., 2024).
Mess itself characterizes memory with a family of bandwidth--latency curves. The benchmark methodology uses a pointer-chase microbenchmark to measure load-to-use latency and a separate traffic generator to create controlled memory pressure; both are implemented in assembly, with huge pages used and TLB/page-walk effects monitored and subtracted. The simulator then uses those same curves to determine memory latency during simulation, enabling support for DDR4, DDR5, HBM2, HBM2E, Optane, and CXL memory expanders. The open-source release explicitly includes OpenPiton Metro-MPI integrated with Mess for DDR4, DDR5, Optane, HBM2, HBM2E, and CXL (Esmaili-Dokht et al., 2024).
The OpenPiton experiments are notable not only for simulator integration but also for diagnostic value. The paper reports that Mess benchmarking of OpenPiton exposed an unexpected memory traffic pattern, traced to unnecessary eviction of all cache lines rather than only dirty ones due to a bug in the coherency protocol generated by OpenPiton; the bug was reported to the OpenPiton developers, who confirmed it (Esmaili-Dokht et al., 2024). In this setting, OpenPiton serves simultaneously as a simulator target and as an RTL design whose memory/coherency behavior can be stress-characterized.
5. Security verification, CWE-oriented scanning, and formal properties
OpenPiton is a major benchmark family in hardware-security verification research through the Hack@DAC 2019 and Hack@DAC 2021 buggy SoCs, both based on the CVA6/OpenPiton line of open-source SoCs (Rogers et al., 2024). In the property-oriented study, the 2019 version contains 66 inserted bugs and is associated with 11 properties, while the 2021 version contains 99 inserted bugs and is associated with 20 properties. The properties are written in SystemVerilog Assertions, are trace properties and safety properties, and are sampled on a clock edge. The verification workflow uses design documentation and literature, bug descriptions, CWE matching, iterative property refinement, and JasperGold (Rogers et al., 2024).
Several concrete OpenPiton vulnerability examples are highlighted. In the 2019 benchmark, processor access to CLINT improperly grants access to PLIC regardless of PLIC configuration through hardcoded RTL logic in axi_node_intf_wrap. In the 2021 benchmark, Bug 76 concerns register lock registers not being correctly locked by register locks, and another 2021 bug allows writing using JTAG without password because the FSM admits a Write transition without properly enforcing the password check in all relevant cases (Rogers et al., 2024). The paper is explicit that properties are not automatically reusable across the 2019 and 2021 versions because signal names, modules, and FSM structure changed.
A complementary line of work performs source-level static analysis on the Hack@DAC-21 OpenPiton SoC using CWEAT, a framework for CWE analysis directly over Verilog/SystemVerilog ASTs parsed with Verific (Ahmad et al., 2022). For OpenPiton, the paper reports 53 potential weaknesses: 2 for CWE-1234, 13 for CWE-1271, 17 for CWE-1245, 12 for CWE-1280, and 9 for CWE-1262. After manual inspection, 11 are confirmed as real security concerns: 6 from CWE-1271, 4 from CWE-1245, and 1 from CWE-1262 (Ahmad et al., 2022).
The confirmed examples illustrate the types of flaws for which OpenPiton has become a benchmark. In the DMA module, a Physical Memory Protection control register such as pmp_access_type_en or pmp_access_type_new is not properly initialized on reset, yielding confirmed CWE-1271 findings. In security-oriented crypto logic, the paper confirms a deadlock in a mod_exp state machine used in RSA logic and an incomplete case statement in an AES interface FSM. The strongest CWE-1262 example is a register-locking inconsistency in which reglk_mem[0] is protected by reglk_ctrl[3] while other entries are protected by reglk_ctrl[1]; the paper demonstrates an exploit path in which setting REGLK_REGLK in reglk.h to 0xf6 allows an untrusted user to override reglk_mem[0] and weaken protection for downstream registers in AES0, AES1, and SHA256 (Ahmad et al., 2022).
These studies also define the limits of OpenPiton as a verification benchmark. Property coverage is incomplete, some bugs are outside the practical scope of RTL assertions, and version drift makes property reuse brittle (Rogers et al., 2024). The static scanners are heuristic, depend heavily on keyword selection and coding style, and operate with little design context (Ahmad et al., 2022). Even so, OpenPiton’s scale, peripheral richness, and bug-instrumented benchmark snapshots make it a recurrent target for formal and semi-formal security research.
6. Comparative baselines and LLM-based verification benchmarks
OpenPiton is also used as a baseline in coherence-architecture comparison. In the Culsans study, it represents a directory-based manycore research framework used for comparison against a snoop-based coherent cluster of Linux-capable CVA6 cores (Tedeschi et al., 2024). The paper characterizes research platforms like OpenPiton and ESP as using directory-based coherence to scale to many cores greater than 4, and argues that this style is overkill for small embedded clusters of 2–4 cores (Tedeschi et al., 2024).
The quantitative comparison is performed on Splash-3 benchmarks in a dual-core setup. The paper reports that Culsans is up to 32.87% faster than OpenPiton and achieves an average improvement of 15.8% over OpenPiton (Tedeschi et al., 2024). However, the cache configurations are only described as similar rather than identical: the OpenPiton configuration is Dual-core OP with a 16 KB L1 instruction cache, an 8 KB L1 write-through data cache, an 8 KB L1.5, and 2 × 64 KB L2, whereas Culsans uses a 16 KB L1 instruction cache, a 16 KB L1 write-back data cache, and a 128 KB L2 (Tedeschi et al., 2024). This comparison therefore places OpenPiton in a specific design-space role: a manycore-oriented directory-based reference point rather than a universally optimal coherence substrate.
OpenPiton has also become a benchmark for automated assertion generation. In the VERT study, it is one of four open-source SoC/IP benchmark platforms, and four OpenPiton IP blocks are used: IO_CTRL, JTAG, MEM_IO, and NOC_BRIDGE (Menon et al., 11 Mar 2025). The reported byte-level 13-gram overlap scores are extremely low—for example, OpenPiton/IO_CTRL has code overlap 0.0001 and assertion overlap 0.0000, while OpenPiton/NOC_BRIDGE has code overlap 0.0002 and assertion overlap 0.0000—supporting the paper’s claim of negligible leakage between VERT and the evaluation data (Menon et al., 11 Mar 2025).
The performance deltas are substantial. For fine-tuned Llama 3.1 on OpenPiton, syntactic correctness rises to 99.19% on IO_CTRL, 96.67% on JTAG, 100.00% on MEM_IO, and 98.07% on NOC_BRIDGE, while functional correctness reaches 95.16%, 96.67%, 90.38%, and 98.07%, respectively (Menon et al., 11 Mar 2025). For fine-tuned DeepSeek Coder, syntactic correctness reaches 92.23%, 100.00%, 95.83%, and 94.28%, with functional correctness of 86.41%, 88.88%, 93.05%, and 94.28% on the same modules (Menon et al., 11 Mar 2025). The paper further reports that contamination via additional ifdef commands and module instantiations degrades correctness on OpenPiton modules, and that cleaned variable names produce the best results (Menon et al., 11 Mar 2025).
Across these comparative and benchmarking roles, OpenPiton repeatedly appears not merely as a standalone architecture but as a reference substrate against which alternative coherence mechanisms, simulator interfaces, security methodologies, and assertion-generation systems are tested. This suggests that its enduring technical significance lies as much in its role as a reusable experimental infrastructure and benchmark family as in any single instantiated processor configuration.