Occamy in Computing: RISC-V, Networks & OCM
- Occamy is a term used in computing to denote three distinct technical constructs: a chiplet-based RISC-V accelerator, a network buffer management scheme, and a nickname for Observationally Cooperative Multithreading.
- In its accelerator form, Occamy features 432 cores with explicit DMA, clustered scratchpad memory, and streaming extensions to optimize performance for both dense and sparse workloads.
- The term also covers a preemptive buffer-management method in high-speed shared-memory switches and a concurrency model, illustrating its versatility across hardware and software system designs.
Searching arXiv for papers on “Occamy” and closely related usages to ground the article in current literature. arxiv_search(query="Occamy", max_results=10) Occamy is a technical name used in several distinct computing literatures. In contemporary computer-architecture research it denotes an open, silicon-proven, chiplet-based RISC-V manycore for HPC and AI, implemented in 12 nm FinFET with HBM2E memory, clustered scratchpads, explicit DMA, and streaming extensions for dense and sparse workloads. In unrelated work, the same name denotes a preemptive buffer-management scheme for on-chip shared-memory switches, and “Occamy” also appears as a colloquial nickname for Observationally Cooperative Multithreading (OCM) systems (Scheffler et al., 13 Jan 2025, Shan et al., 23 Jan 2025, Stone et al., 2015).
1. Scope of the name
The term has three technically separate meanings. First, Occamy names a manycore RISC-V accelerator and chiplet roadmap for HPC and AI, including a dual-chiplet, dual-HBM2E system and later mesh-oriented successors (Scheffler et al., 19 Nov 2025). Second, “Occamy” is the title of a 2025 networking paper on preemptive buffer management in shallow-buffer, high-speed datacenter switches, where the design actively reclaims over-allocated shared buffer by head-drop (Shan et al., 23 Jan 2025). Third, in concurrency research, “Occamy” is an informal nickname for OCM, but the formal model name remains Observationally Cooperative Multithreading (Stone et al., 2015).
A common source of confusion is that these usages are unrelated in mechanism, problem setting, and evaluation methodology. The hardware-architecture papers concern RISC-V chiplets, HBM, scratchpads, DMA engines, and interconnect scalability. The switch paper concerns packet descriptors, cell pointers, dynamic thresholds, and expulsion bandwidth in traffic managers. The OCM usage concerns shared-memory programming semantics, yield-delimited atomic regions, and CM serializability.
2. Occamy as a chiplet-based RISC-V manycore
In the accelerator literature, Occamy is presented as a 2.5D-integrated RISC-V system fabricated in GlobalFoundries 12 nm LP+ FinFET and assembled on a passive 65 nm interposer (“Hedwig”), with two compute chiplets and two 16 GiB HBM2E stacks for 32 GiB total DRAM (Scheffler et al., 13 Jan 2025). The full system offers 432 cores organized as 48 clusters, with 9 cores per cluster. Each cluster contains eight worker cores and one DMA control core, shares a 128 KiB scratchpad memory divided into 32 banks, and includes an 8 KiB shared L1 instruction cache. Worker cores are RV32G-class cores derived from Snitch lineage, while host control is Linux-capable RV64GC/CVA6-class functionality in the host domain (Scheffler et al., 19 Nov 2025).
The worker microarchitecture is specialized for sustained floating-point throughput under both regular and irregular access patterns. Each worker integrates a 64-bit SIMD FPU supporting FP64, FP32, FP16, FP16alt, FP8, and FP8alt formats, together with widening sum-dot-product and three-addend summation support for narrow formats. A hardware loop buffer reduces loop-control overhead, and three Streaming Units (SUs) connect directly to floating-point registers. All three SUs support up to 4D affine streams; two additionally support indirect streams with 8/16/32-bit indices, stream intersection and union, and related sparse-tensor or graph-style access patterns. The DMA control core drives asynchronous data movement, including 1D/2D transfers and double buffering between off-chip memory and cluster scratchpad (Scheffler et al., 13 Jan 2025).
The system is explicitly scratchpad-based rather than cache-coherent. Per-cluster scratchpads, a chiplet-level 1 MiB global SPM on the 512-bit network, and a 512 KiB SPM on the 64-bit network are orchestrated by software, atomics, and DMA. This design choice trades hardware-managed coherence for predictable local latency, bulk-transfer efficiency, and direct control over data placement. The papers characterize that choice as central to sustaining utilization on sparse and stencil kernels, where conventional cache hierarchies often pay heavily for indirection and irregular reuse (Paulin et al., 2024).
3. Execution model, ISA support, and measured performance
Occamy’s compute model combines explicit DMA tiling with in-core stream semantics. Dense kernels configure affine streams and use hardware-loop repetition to reduce a loop body to the useful floating-point operations. Sparse kernels configure indirect streams so that index traversal, gather/scatter, and stream intersection move into the SU hardware rather than scalar address-generation code. The result is a programming style in which worker cores operate on tiles resident in SPM while DMA overlaps the next transfers, and barriers plus atomics coordinate cluster-level and system-level progress (Scheffler et al., 13 Jan 2025).
The reported measurements span dense linear algebra, stencil codes, sparse-dense and sparse-sparse linear algebra, and ML inference. At 1 GHz, total FP64 peak is reported as 768 DP-GFLOP/s, while the roadmap paper also reports 876 GFLOP/s peak DP performance at 1.14 GHz under typical conditions (Scheffler et al., 13 Jan 2025).
| Workload | Best reported result | Additional metric |
|---|---|---|
| FP64 GEMM | 686 GFLOP/s | 89% FPU utilization |
| FP64 stencil | 571 GFLOP/s | 28.1 GFLOP/s/W |
| FP64 SpMM | 307 GFLOP/s | 42% FPU utilization |
| FP64 SpMSpM | 187 GCOMP/s | 17.4 GCOMP/s/W |
| FP16 GPT-J inference | 490 tokens/s | 29.3 tokens/s/W |
| FP64 GCN layer | 413 GFLOP/s | 54% FPU utilization |
These results are accompanied by workload-specific speedups from the streaming extensions. Dense GEMM with SU acceleration is reported at 2.7× speedup, stencil computations at up to 3.9×, graph convolution network layers at up to 2.3×, and sparse-dense SpMM at up to 4.6× (Scheffler et al., 19 Nov 2025). The sparse-sparse metric is reported in GCOMP/s because the core operation is index comparison during stream intersection rather than ordinary floating-point throughput. For stencil workloads, the papers report 83% FPU utilization and a technology-node-normalized compute density of 11.1 DP-GFLOP/s/mm²; for sparse-dense linear algebra, they report 42% FPU utilization and 5.95 DP-GFLOP/s/mm² normalized density (Paulin et al., 2024).
The reported interpretation is not that Occamy maximizes absolute low-precision dense matmul throughput against the latest tensor-core GPUs. Rather, the architecture is positioned as sustaining comparatively high utilization across mixed dense and sparse phases by pushing stream semantics, indirection support, and explicit data movement into the ISA and the cluster memory system.
4. Hierarchical interconnects, chiplet links, and mesh-based successors
Occamy uses a hierarchical AXI4 interconnect rather than a mesh. Inside a compute group of four clusters, the design instantiates a 512-bit AXI4 crossbar for DMA engines and instruction-cache traffic and a 64-bit atomics-capable AXI4 crossbar for synchronization and message passing. At chiplet scope, the wide domain includes an HBM crossbar, a group-interconnect crossbar, and a system crossbar; the narrow domain includes a 64-bit SoC crossbar. Group ports provide 64 GiB/s on the 512-bit path and 8 GiB/s on the 64-bit path (Scheffler et al., 19 Nov 2025).
Inter-chiplet communication is divided into narrow and wide segments. In the silicon-proven design, the wide segment reaches an effective duplex bandwidth of up to 64 Gb/s with 96% utilization on a 16 KiB transfer and 1.6 pJ/bit, while the narrow segment reaches up to 1.33 Gb/s effective duplex. Reported latencies are 27 cycles for host access to remote host SPM via the narrow segment and 61 cycles for DMA transfer across the wide segment (Scheffler et al., 19 Nov 2025).
The same literature also makes the scaling limits of this hierarchy explicit. The roadmap paper attributes about 31% of compute-domain area to crossbars and identifies centralized routing, long global wires, routing congestion, and constrained off-die scaling as principal limitations of the hierarchical approach (Scheffler et al., 19 Nov 2025). FlooNoC is presented not as Occamy’s shipped NoC, but as a physically implemented mesh alternative evaluated against “the same compute clusters” connected by a hierarchical AXI interconnect instead of a mesh (Fischer et al., 2024). In that comparison, the mesh-based design reports 645 Gbps/link, 103 Tbps aggregate bandwidth for an 8×4 mesh, 0.15 pJ/B/hop at 0.8 V, and a 30% area reduction versus a traditional AXI4-based multi-layer interconnect, corresponding to a 47% increase in GFLOPSDP within the same floorplan (Fischer et al., 2024).
The roadmap names the mesh-oriented successor Ramora. Relative to Occamy, Ramora is reported to provide 33% more clusters per chiplet, an 11% higher peak clock, 1.29 TFLOP/s peak DP performance, higher HBM bandwidth utilization, and substantially higher edge bandwidth through LVDS-based die-to-die connectivity (Scheffler et al., 19 Nov 2025). In this lineage, Occamy is the silicon baseline from which the mesh transition is motivated.
5. Offload-overhead analysis in an Occamy MPSoC configuration
A separate 2025 study analyzes offload overheads on an Occamy heterogeneous MPSoC under bare-metal execution to isolate hardware latencies (Colagrande et al., 9 May 2025). In that configuration, the system comprises a single CVA6 host core and 288 Snitch RISC-V accelerator cores organized into eight quadrants with four clusters each, for 32 clusters total. Each cluster contains eight compute cores, one data-mover core tightly coupled to a DMA engine, a 128 KB TCDM scratchpad divided into 32 banks, a per-cluster hardware barrier, WFI support, and low-latency interrupt mechanisms through CLINT MSIP and a custom MCIP register.
The paper decomposes host-centric offload into phases A–I: sending job information, waking selected cores, retrieving the job pointer, retrieving arguments, retrieving operands, executing the kernel, writing back outputs, signaling completion, and host resumption. On the baseline narrow/wide AXI crossbar hierarchy, the aggregate overhead grows with cluster count: a single cluster averages about 242 cycles, while 32 clusters reach up to about 1146 cycles for Matmul, with application-dependent variance (Colagrande et al., 9 May 2025).
The optimization is a hardware/software co-design centered on multicast and a Job Completion Unit (JCU). The narrow-network crossbars are extended with mask-based multi-destination writes so that job metadata and wakeups become multicasts rather than per-cluster host stores. The JCU turns global completion into a constant-time host notification. With multicast plus JCU, the paper reports a residual overhead of about 185 cycles with , nearly constant across cluster counts, and runtime improvements of up to 2.3× for fine-grained kernels. The study further states that this restores more than 70% of ideally attainable speedups, and that the proposed runtime model predicts selected applications with relative error consistently below 15% (Colagrande et al., 9 May 2025).
The paper also provides explicit models. For AXPY on the multicast path, it reports
and for ATAX it reports
These formulas are used to expose when offloading is profitable and when serial broadcast costs dominate at larger .
6. Other technical uses of “Occamy”
In switching research, Occamy denotes a preemptive buffer-management scheme for modern on-chip shared-memory switches (Shan et al., 23 Jan 2025). The problem setting is shallow-buffer datacenter switching under intense microbursts and dynamic traffic. The baseline dynamic-threshold policy uses
but the paper argues that non-preemptive schemes cannot reclaim over-allocated buffer quickly enough because they must wait for packet departures at port rate. Occamy makes preemption practical by decoupling admission from expulsion and using spare packet-descriptor and cell-pointer bandwidth to perform head-drop on over-allocated queues. It reuses dequeue-pipeline structures, never touches cell data during expulsion, gives the scheduler fixed priority over expulsion reads, and uses round-robin selection rather than longest-queue tracking. Reported results include up to about 55% improvement in end-to-end performance in testbeds and about 48% in large simulations, together with hardware cost below 0.03 mm² and about 1 mW (Shan et al., 23 Jan 2025).
In concurrency research, “Occamy” refers informally to OCM, but the formal model is Observationally Cooperative Multithreading (Stone et al., 2015). OCM is a shared-memory parallel programming model in which programmers write threads in a cooperative, nonpreemptive style and place explicit yield points; the runtime may execute threads in parallel so long as the result is observationally consistent with some cooperative schedule. The defining correctness notion is CM serializability: code between successive yields is atomic with respect to other threads, and implementations may use global locks, per-object locks under two-phase locking, software transactional memory, or hybrids. The model’s significance is semantic rather than nominal: “Occamy” in this setting is only a colloquial nickname, whereas the published technical term is OCM (Stone et al., 2015).