A heterogeneous hardened-CPU + reconfigurable-fabric compute module for AI inference and robotics control — spun out of Kestrel K1's accelerator research once the fit turned out to be a different product, not a component of it.
This project started as a side question inside Kestrel K1's accelerator-comparison research: whether an updatable soft CPU core / eFPGA could work as a gaming handheld's main processor. It doesn't — the power/clock-speed tradeoff on that fabric class is structural, not a maturity gap, and a modern gaming UI/OS needs more than a soft core can deliver at Kestrel's power budget. But the same fabric stopped looking like a workaround and started looking like the right architecture once the workload shape changed from branchy scalar code to dataflow: dense multiply-accumulate, deterministic control timing, many parallel sensor/actuator I/O lines. That's a robotics/AI compute problem, not a handheld problem, so it's its own project rather than a Kestrel component.
A soft CPU core on generic LUTs and reconfigurable routing is the worst case for interpreted, branchy scalar code — it's paying fabric-level overhead for work a hardened core does natively and more efficiently. Dataflow work is the opposite case: dedicated parallel pipelines built directly in the fabric, running next to a hardened CPU that handles orchestration. Raptor Core keeps both, each doing the job it's actually good at.
| Workload | Why the fabric helps |
|---|---|
| NN inference / sensor fusion math | Dense MAC is what DSP blocks are built for — e.g. Efinix Ti60-class fabric has 160 DSP blocks, each capable of INT8 quad-multiply or a fused BFLOAT16 multiply-add in hardware |
| Motor/sensor control loops | Cycle-accurate, deterministic timing — no OS/RTOS scheduler jitter, a real capability advantage independent of power |
| Sensor bridging | Many simultaneous parallel I/O interfaces without contending for a shared bus/DMA like an MCU would |
Existing heterogeneous hardened-CPU + fabric parts, as a starting reference point for what a Raptor Core module could be built on or benchmarked against — not a sourcing decision yet.
| Part | Role |
|---|---|
| AMD Kria K26 SOM | Hard Cortex-A53/R5 + fabric, ROS 2-ready — the reference heterogeneous pattern |
| Microchip PolarFire SoC | Hard RISC-V + fabric, real-time control + reconfigurable I/O as the core pitch |
| Efinix Sapphire RISC-V SoC | Hard core + fabric on one die — BFLOAT16 DSP path is the point here, not soft-core clock speed |
| Lattice CrossLink-NX / CertusPro-NX | Low-power edge AI/vision sensor bridging |
| QuickLogic EOS S3 | Cortex-M4F + small eFPGA, always-on voice/sensor wake tier — legitimate fit, not a stretch |
This doc is the seed of the project, not a finished spec. No system architecture, BOM, or cost reference exists yet — those are the next docs, once the questions below have a first-pass answer.
| Question | Why it matters |
|---|---|
| Buy a reference SOM (Kria/PolarFire) vs. design a custom board? | Sets the whole cost and timeline profile, same fork Kestrel K1 hit with its own silicon question |
| How does this compare to existing robotics compute (Jetson Orin, Raspberry Pi + HAT accelerators)? | Needed before claiming the heterogeneous approach is actually better for a given workload, not just architecturally interesting |
| What's the first concrete workload to validate against? | "AI/robotics" is too broad to design a board for — needs one real control-loop or inference target to size the fabric against |