The Sparsr architecture
What the machine is, what its instruction set covers today, and what it is designed to grow into.
Two register files, one machine
Sparsr is not a coprocessor bolted onto a host CPU. The wide side is the point of the design; the scalar side exists to drive it.
-
A 32-bit scalar core
A conventional five-stage pipelined 32-bit RISC core with the usual 32-bit register file. It handles addressing, control and the ordinary integer work around a kernel. It is deliberately unremarkable — nothing about Sparsr is a bet on the scalar side.
-
A 4096-bit wide register file
A separate file of 4096-bit registers, with its own instructions. This is the width the machine is designed around: not a 512-bit vector extension sitting beside a 64-bit core, but the width at which data is loaded, operated on, and stored.
The wide instruction set today
What is implemented and running, in the emulator and in RTL. Stated plainly, because a processor company that is vague about its own opcode list is not worth evaluating.
| Instruction | What it does |
|---|---|
| WAND, WOR, WXOR | Bitwise logic across the full 4096 bits, one instruction per operation. |
| WL, WS | Wide load and store between compressed memory and a wide register, at an address fixed in the instruction. |
| WLR, WSR | The same, with the address taken from a live 32-bit register — the register-indirect form, which is what makes a wide register file usable from a loop written by a compiler rather than by hand. |
| ADD, SUB, AND, OR, XOR, NOR, LW, SW | The scalar side: ordinary 32-bit integer and memory operations. |
Compression lives in the load/store path
A wide load does not simply fetch 4096 contiguous bits. Sparse rows are held in compressed memory in a run-length-style format, and the wide load and store instructions run them through the codec on the way to and from the register file.
The consequence is a programming model rather than a speed figure: a kernel addresses compressed sparse data directly, instead of decompressing it into a buffer with general-purpose instructions first. No baseline instruction set does this, and it is the property that most decides which workloads suit Sparsr — the format is tuned for data that is genuinely sparse, but not arbitrarily so.
It also sets a real limit worth knowing before you evaluate: how much a single wide register can hold depends on how sparse the row is, so very dense and very sparse data both sit outside the band the codec is good at.
The programming model
A Sparsr program is a host application plus one or more kernels — the same split as a GPU, and for the same reason.
-
The host drives the outer loop
Control flow, iteration and orchestration live in the host application, written in C, C++, C# or Python. The runtime moves data and dispatches kernels.
-
The kernel is the wide part
A kernel is the piece that touches the wide registers. Kernels are written in Sparsr assembly or in C/C++ through sparsr_intrinsics.h, and are straight-line wide-data code today.
-
The backend is a runtime choice
libsparsr.so selects between the software emulator and FPGA hardware at runtime, so the same host application and the same kernel run against either without recompiling the host.
-
Most users should not have to write one
For an established high-level domain the kernels come out the same every time, so they belong in a library rather than in your code. We are building those — the first is a PyTorch device that runs standard Torchhd programs on Sparsr through an ordinary .to("sparsr") call. It is in development and not released, so today using Sparsr still means writing a kernel.
On the roadmap
Sparsr's instruction set is explicitly not fixed. Adding a primitive at 4096 bits is ordinary roadmap work, so a missing instruction is a question of sequencing, not a closed door. These are the ones being worked on, and they are published because knowing what is not there yet is what lets you judge whether Sparsr fits your kernel.
| Planned primitive | What it unlocks |
|---|---|
| A wide reduction unit | Population count, parity, prefix-rank and threshold-accumulate over a wide register, in segmented per-lane form rather than only as a single reduction to one scalar. This is the most requested primitive across every workload we have surveyed. |
| A per-block wide rotate | Rotation and permutation within a wide register — the binding operation for hyperdimensional computing, and for quasi-cyclic codes. |
| A raw wide load/store path | A route into the wide register file that bypasses the compression codec, for data that is dense enough that compressing it costs more than it saves. |
| Wide arithmetic | Carry-propagating addition across the wide register, for the bit-parallel dynamic-programming kernels that need it. |
Where it runs
Three destinations. The third is a partnership rather than a product, and it is the one people tend not to ask about.
-
On your own machine
The software emulator implements the full instruction set on an ordinary CPU. It is the target you develop and test against, it needs no hardware and no account, and it is free.
-
On FPGA
Sparsr's FPGA target is AWS EC2 F2, on a Virtex UltraScale+ HBM part. F2 is the development and validation vehicle for the design rather than a finished product baseline — it is where the RTL is proven. Hosted access is coming — see pricing for when.
-
On your own silicon
Sparsr is a processor design, so it does not have to run on hardware we operate. If you already build silicon, or ship your own FPGA-based products, the wide register file and its instruction set can be embedded in your device as licensed IP — including with instructions specified around your workload rather than ours. We are open to that, and would rather hear from you early in your design cycle than late.
Does your kernel fit?
The short test: if the inner loop is dominated by bitwise operations over long bit vectors, and the data is sparse but not extremely so, it is worth a conversation — including if the primitive you need is one of the roadmap items above.