Research partnerships

We build custom wide instructions and FPGA designs around research workloads, and we do it as a collaborator rather than as a vendor.

What we bring to a collaboration

Three things, and we would rather describe them narrowly and deliver them than describe them broadly.

  • Instruction set co-design

    If your kernel needs a wide primitive Sparsr does not have, we can add it at 4096 bits — that is ordinary work on this architecture, not a special case. The output is a real instruction: emulator, assembler and RTL support together, so you can develop against it long before hardware exists.

  • FPGA implementation

    We do the RTL, the verification and the host-side integration. You get a design you can run rather than a paper about one, and the software emulator means your group can start writing and testing kernels immediately.

  • Joint grant proposals

    We are set up to be the hardware partner on a consortium proposal, and we can write the architecture and work-package sections. If the funding route you are looking at needs an industrial partner with real silicon expertise, that is a role we can fill.

Read the architecture page first

How a collaboration actually starts

Deliberately low-commitment at the front, because the first question is whether this is a good idea at all.

  1. 1

    Tell us about the kernel

    Send us the inner loop and a description of the data. We will tell you whether it maps onto the machine, what it would need that does not exist yet, and — often enough — that a CPU is the better answer.

  2. 2

    Prototype against the emulator

    Your group writes the kernel against the free SDK, including against instructions we have specified but not yet built. This is where a collaboration proves itself, and it costs neither side hardware access nor money.

  3. 3

    Build the hardware around it

    Once the kernel is real and the primitive is specified, the RTL work and the FPGA implementation follow — either as project work or as a work package inside a funded proposal.

Groups we would particularly like to hear from

These are the fields where we have done the deepest analysis, so a conversation starts further along.

  • Hyperdimensional computing and VSA

    Vector symbolic architectures are the closest match to what Sparsr is for, and the group that gets the reduction unit and the wide rotate specified against a real workload will shape what those instructions become.

  • Quantum error correction

    Stabilizer simulation and Pauli-frame sampling are wide XOR and population count over a working set small enough to keep on chip — a good fit that we would like to test against a real decoder workload.

  • Cheminformatics and molecular screening

    Fingerprint similarity runs on the instruction set as it stands, which makes it the cheapest possible starting point for a collaboration: no hardware roadmap dependency at all.

  • Coding theory and error-correcting codes

    GF(2) arithmetic maps onto the wide instructions with no translation layer. If you are working on codes whose decoders are bounded by long bitwise operations, we want to talk.

All application areas

Start a conversation

Tell us what your kernel does. A description of the inner loop and the shape of the data is more useful to us than a formal proposal, and we will tell you honestly if Sparsr is the wrong machine for it.