---
title: 'Occamy in Computing: RISC-V, Networks & OCM'
url: https://www.emergentmind.com/topics/occamy
type: topic
---

# Occamy in Computing: RISC-V, Networks & OCM

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 [2501.07330][2501.13570][1502.05094].

## 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 [2511.15564]. 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 [2501.13570]. Third, in concurrency research, “Occamy” is an informal nickname for OCM, but the formal model name remains Observationally Cooperative Multithreading [1502.05094].

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 [2501.07330]. 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 [2511.15564].

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 [2501.07330].

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 [2406.15068].

## 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 [2501.07330].

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 [2501.07330].

| 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× [2511.15564]. 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 [2406.15068].

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 [2511.15564].

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 [2511.15564].

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 [2511.15564]. 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 [2409.17606]. 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 [2409.17606].

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 [2511.15564]. 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 [2505.05911]. 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 [2505.05911].

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 \(O(1)\) 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 \(\sigma \approx 18\), 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% [2505.05911].

The paper also provides explicit models. For AXPY on the multicast path, it reports
\[
\hat{T}(n,N)=400+\frac{N}{4}+\frac{2.47\cdot N}{8n},
\]
and for ATAX it reports
\[
\hat{T}(n,N,M)=566+3.98\cdot N\cdot M+\frac{2.9\cdot N}{8n}+\frac{N\cdot(1+M)}{8}\cdot n.
\]
These formulas are used to expose when offloading is profitable and when serial broadcast costs dominate at larger \(n\).

## 6. Other technical uses of “Occamy”

In switching research, Occamy denotes a preemptive buffer-management scheme for modern on-chip shared-memory switches [2501.13570]. The problem setting is shallow-buffer datacenter switching under intense microbursts and dynamic traffic. The baseline dynamic-threshold policy uses
\[
T(t)=\alpha\left(B-\sum_{i=1}^{N} q_i(t)\right),
\]
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 [2501.13570].

In concurrency research, “Occamy” refers informally to OCM, but the formal model is Observationally Cooperative Multithreading [1502.05094]. 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 [1502.05094].

Source: https://www.emergentmind.com/topics/occamy