Kernel study
Before anyone quotes you custom hardware, someone should measure your kernel. Send us the inner loop. We will tell you in days what a custom instruction would be worth, with numbers and without an FPGA.
A hardware quote without a measurement is a guess
Usually you describe a workload and a vendor describes an accelerator. Then 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 real measurement arrives after the money is committed.
A kernel study inverts that. We run your actual code on the Sparsr software emulator. Counting what happens shows which operations dominate, the pattern of data movement, where the time concentrates, and how much 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. It exists 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 runs the instruction set for real rather than approximating it.
-
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. Often enough that recommendation is to build nothing. The report is yours, and you are free to stop there.
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 write down what it computes and what it operates on, together with its rough 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. Your own laptop is enough to find out whether the idea holds up, so there is no wait for hardware.
-
No RTL
Nobody writes hardware description code during a kernel study — not us and 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 application, a board paper or an internal budget. What you have is an intuition rather than a measurement, and a study turns it into something a reviewer can check.
-
Not worth doing: the algorithm is settled and small
If the computation is frozen, well understood, and already done in fixed-function hardware 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 is free.