Runs on: your own CPU. No FPGA, no PCIe, no cloud instance.
How to get it: it is in the Sparsr SDK download, as
bin/sparsr-vmandlib/libsparsr_vm.so. It is a self-contained binary — you do not need a .NET runtime installed to use it.
The Sparsr VM is a model of the Sparsr device that runs on an ordinary computer. It executes RV32I, plus Sparsr's 4096-bit wide instructions, against the same memories and the same register file that hardware has.
All 39 RV32I tests of the RISC-V Architectural Certification Tests (ACT4) pass, and every one of them produces a signature region byte-identical to the RISC-V Sail reference model.
That second half is the part that matters. An ACT4 test checks its own answers using instructions executed by the device under test, so a device could in principle agree with itself and still be wrong. Sparsr therefore also runs a signature build of every test — the same instructions compiled to write their answers out — and compares those bytes against what Sail wrote. That comparison is not computed by the VM.
The scalar half of the machine is therefore not "we think it works". It matches the reference model of the architecture, instruction by instruction.
Two limits on what that proves. It covers RV32I only, so it says nothing about the wide
instructions in the custom-0 space. And it tests the VM, not the FPGA.
As a backend, inside your program. Your host application links libsparsr_host.so as
usual and picks the VM at run time:
SPARSR_BACKEND=vm ./my_host_appNothing in your source changes. The same program runs against hardware later by changing that one variable.
As a program, on its own. When something is wrong and you want the kernel without the host application around it:
sparsr-vm run kernel.spex --traceOther commands:
sparsr-vm run <kernel.spex> load a kernel and run it
sparsr-vm serve hold devices and answer the wire protocol
sparsr-vm info what a running endpoint is and can do
sparsr-vm shutdown ask a running endpoint to stop
sparsr-vm help every optionThere are two backends over the same device model, and the difference is where the device lives.
SPARSR_BACKEND |
Where the device runs | Use when |
|---|---|---|
vm |
inside your process | the default choice — it is much faster |
vmproc |
a separate sparsr-vm process, over a socket |
a wedged kernel should not wedge your program, or you want to attach a debugger to the device alone |
The same kernel image runs on both. vm is faster by a wide margin, because vmproc pays
for a round trip on every operation.
| Scalar registers | 32, 32-bit, RV32I |
| Wide registers | 32, 4096 bits each |
| Instruction memory | 1,024 words (4 KiB) |
| Data memory | 1,024 words (4 KiB) |
| Co-processor memory | 32 slots, 7,680 bytes total, stored compressed |
Those are the shipping sizes. See Memory Model for how the three memories differ and how CMEM compression works.
It is not cycle-accurate. It executes instructions for functional correctness and does not model the pipeline, so it cannot tell you how fast anything will run on hardware. Use it to find out whether your kernel is right, not how quickly it finishes.
Its data-transfer timing means nothing. Moving data in and out of the modelled memories does not resemble a real PCIe transfer.
It is not the hardware's instruction set. The VM runs RV32I. Sparsr FPGA hardware today decodes the older MIPS instruction set, so a kernel built for one will not run on the other. That is the whole difference between this page and Software Emulator.
| You wrote your kernel in | Use |
|---|---|
| C | the Sparsr VM — SPARSR_BACKEND=vm |
| Sparsr Assembly, for FPGA hardware | the Software Emulator — SPARSR_BACKEND=softemu |
The Software Emulator is the older of the two and matches what the FPGA runs. The VM is where new work happens, and it will become the default once the assembler and the hardware move to RV32I.