Kernel study
Before anyone quotes you custom hardware, someone should measure your kernel. Send us the inner loop and we will tell you what a custom instruction would actually be worth — with numbers, in days, without an FPGA.
A hardware quote without a measurement is a guess
The usual way this conversation goes is that you describe a workload, a vendor describes an accelerator, and somebody produces a number. Nobody has run your code. The estimate rests on how the kernel sounds rather than on what it does, and the first honest measurement arrives after the money is committed.
A kernel study inverts that. We take your actual code, run it on the Sparsr software emulator, and count what happens: which operations dominate, how the data moves, where the time concentrates, and which of that a wide instruction could absorb. Then we write down what we found.
It is deliberately small. Days of work, a fixed price agreed before we start, and no hardware on either side. The point is to find out whether the expensive version is worth doing.
How it works
-
1
You send the kernel
The inner loop, a description of the data it runs on, and whatever you currently use as a baseline. Working code is ideal. A precise description of the loop and the data shape is enough to start. We sign an NDA first if you need one.
-
2
We port and run it
We express the kernel against the Sparsr instruction set and run it on the emulator — including against instructions that do not exist in hardware yet, which is the part that makes this possible without a chip. The emulator is a real implementation of the instruction set, not an approximation of one.
-
3
We measure
Instruction mix, data movement, how much of the work is actually the part you care about, and what fraction a wide primitive could take over. Where a primitive would need to be added, we specify it and estimate what it costs to build.
-
4
You get the report
A written answer with the measurements behind it, and a recommendation you can act on — including, often enough, a recommendation not to build anything. The report is yours. Nothing obliges you to a second phase.
What the report contains
Written for an engineer who will check it, not for a procurement file.
-
Where the time actually goes
A measured profile of the kernel as it runs on the emulator, broken down by operation class. This is frequently the most useful part on its own, because it is the same profile whatever hardware you eventually choose — and it sometimes contradicts what everyone assumed the bottleneck was.
-
What a custom instruction would absorb
The fraction of the work a wide primitive could take over, and the fraction that would remain. A kernel where the interesting loop is a tenth of the runtime has a ceiling on what any accelerator can do for it, and you should know that number before you spend anything.
-
The primitive, specified
If your kernel wants something Sparsr does not have, we describe it precisely: what it computes, what it operates on, and roughly what it costs in silicon area. That specification is useful to you even if we never build it.
-
An honest recommendation
Whether this is worth taking further, and what the realistic alternatives are. Sometimes the answer is that a CPU already does this well, or that the kernel is bounded by memory rather than by arithmetic. We would rather tell you that in week one than in year one.
What it does not require
The barriers that normally stop this kind of evaluation are all on the hardware side, and none of them apply here.
-
No FPGA
Everything runs on ordinary machines. You do not need to rent a cloud FPGA, buy a development board, or wait for hardware availability to find out whether the idea holds up.
-
No RTL
Nobody writes hardware description code during a kernel study — not us and certainly not you. That work belongs to a later phase that this one exists to decide on.
-
No commitment
A fixed price, agreed up front, for a defined piece of work with a written deliverable. If the report says stop, that is a good outcome and the engagement ends there.
When this is the right thing to do
And when it is not — the second list saves both of us more time than the first.
-
Worth doing: you have a loop that dominates
One kernel accounts for a large share of your runtime, you have already optimised it in software, and you are wondering whether hardware is the next step. This is the case the study was designed for.
-
Worth doing: you are scoping a proposal
You need a defensible technical section — for a grant, a board, or an internal budget — and what you have is an intuition rather than a measurement. A study turns the intuition into something a reviewer can check.
-
Not worth doing: the algorithm is settled and small
If the computation is frozen, well understood, and already has a fixed-function implementation somewhere, a programmable processor is the wrong shape for it. We will say so, but you can save the fee by noticing it first.
-
Not worth doing: the work is floating point
Sparsr is built for wide integer and bitwise work. Floating-point-dominated numerical code is a different machine, and we are not currently the right answer for it — sparse or dense. Ask us anyway if you are unsure which yours is.
Why we offer this rather than a brochure
We are a two-person company building a processor. That has one useful consequence for you: we cannot afford to take on work that will not succeed, so we have a strong interest in finding out early — and in telling you.
It also means we take a small number of these each year. If the timing matters to you, say so when you get in touch.
And if the study leads somewhere, the quote for the hardware work is built on the measurements in the report rather than on an estimate. That is the whole reason this step exists.
Start with the inner loop
Tell us what the kernel does and what the data looks like. That is enough for us to say whether a study is worth running at all — and that first answer costs nothing.