ESP32-S3-DevKitC-1 N16R8 — KARQ dense and CNN on silicon
physical_hil
Xtensa LX7 @ 240 MHz, exact ESP-IDF v6.0.2 with its IDF-owned Xtensa toolchain,
MQ_PORT_ESP32S3, portable generic-swar kernel, FreeRTOS
task pinned to core 1, internal memory placement, DMA disabled. 100-sample
distributions; cycles cross-checked by an independent esp-timer.
Both pass host↔silicon output parity; dense also passes on-target
blocking↔cooperative parity. The CNN runtime has no cooperative executor, so its
second slot is a blocking determinism re-run and is labelled as such.
KARQ vs SPQ4, same board, same session
Read that honestly: on this board, this model, and the portable
kernel, SPQ4 is roughly 1.4× faster than KARQ and marginally smaller in flash.
The first silicon run measured 2.1×; we found the cause, fixed it, re-measured
on the same board, and KARQ dense came back 1.55× faster with byte-identical
outputs. We expected that fix to reach parity and it did not — the remaining
difference is partly a requantization path we have not addressed and partly
unattributed, and we say so rather than rounding it away. KARQ's demonstrated
advantage is planned peak SRAM on a different workload (388 B vs 896 B on the
gesture model). That is exactly why SPQ4 remains the default and the rollback
path, and why we do not sell KARQ as a free upgrade.
Scope, stated plainly: this exact board, ISA, SDK, toolchain,
clock, and kernel backend. It does not validate another ESP32-S3 variant, the
unimplemented esp32-s3-simd kernel, any Arm or RISC-V board,
optimized-kernel cycles, or energy. KARQ has run on one ISA, so no cross-ISA
claim exists anywhere in this project.
Raspberry Pi Pico 2 / RP2350 Arm — SPQ4 dense on silicon
physical_hil
Cortex-M33 @ 150 MHz. Firmware built through the Pico SDK, flashed, and captured
by our hardware-in-the-loop pipeline. This is an SPQ4 record and
says nothing about KARQ.
Reproduce the physical result: with a Pico 2 on your desk and the
exact Pico SDK 2.3.0 environment, one command re-runs the whole validation —
python3 studio/validate.py --board pico2-rp2350-arm --synthetic dense —
and prints the same hashes and serial transcript recorded in the evidence report
that ships with the result. Without the board and a matching environment the
pipeline reports unavailable; it will never quietly substitute a
desktop number.
Host harness output
Reference 2-layer demo model (64×128 → 32×64), SPQ4.
These are host measurements (x86 / Apple Silicon,
-O3). Host latency is wall-clock, noise-sensitive, and not a
target metric. The Cortex-M4/M7 __SMUAD backend is compiled and
bit-exact-parity-tested against the portable reference, but
no optimized kernel has ever produced an on-silicon cycle count
— both silicon runs above deliberately use the portable kernel.
Reproduce It Yourself
Three commands. Nothing beyond Python 3.12+ and a C++11 compiler.
$ make test
== make test: ALL CHECKS PASSED ==
$ python3 compiler/main.py --synthetic-demo --out benchmark/model_assets.h
SUCCESS: bare-metal assets written
$ g++ -std=c++11 -O3 -Iruntime/include -Ibenchmark \
benchmark/benchmark.cpp -o benchmark_run && ./benchmark_run
Async vs. Blocking exact bit parity : PASS (bit-identical)
Relative L1 error : 0.2785 %
Flash size reduction : 80.47% vs FP32
Dynamic heap allocation : 0.00 KB
How an engagement runs
- Audit — model, activation ranges, memory map, timing budget.
- Design — SPQ4 or KARQ selected and configured against your accuracy target and silicon.
- Integrate — kernels, RTOS scheduling, build-system wiring.
- Verify — parity, WCET, and footprint evidence delivered with hashes.