Does an AVR Need SIMD? A Roofline Study That Said No

The plan was a coprocessor. An 8-bit AVR runs flight-control math. That means EKF, AHRS, PID, plus some int8 inference. Most of its cycles go to software floating point. The intuition was simple. Bolt a wide SIMD unit on the side. Run many lanes in parallel. Win big. So I started AVR-XPU to explore exactly that.

First, the responsible step. Measure before building. I ran the real workloads through a validated gem5 AVR model. Three questions, with data, not intuition. What do the kernels actually use? Is the idea even compute-bound? How does AVR softfloat compare to a real FPU?

This post is what the measurement said. It killed the wide vector unit. It kept the coprocessor. And it changed what the coprocessor should be.

The setup

The model is a custom gem5 AVR core. It is functionally and cycle validated against a real ATmega328P. For this study I hardened it and instrumented it. Four changes, each driven by a measurement need.

• Hard-halt on unknown opcodes. The port used to silently skip undecoded instructions. That corrupts results quietly. Now it halts and prints the opcode and PC. ISA gaps became visible.
• ELPM + RAMPZ. Implementing these unblocked larger working sets. The C runtime copies .data with ELPM on big devices.
• Op-mix instrumentation. At exit the CPU emits per-mnemonic instruction and cycle histograms. Plus per-function instruction, cycle, and call-count histograms. This is the raw material.

Every kernel is compiled twice. A host reference on x86-64, IEEE-754 round-to-nearest. An AVR build with avr-gcc softfloat, same semantics. Both emit checkpoint traces and a CRC-32 over the output. A gem5 run is valid only if it halts cleanly and matches the host bit-for-bit. For the IEEE-mandated ops they agree exactly. So the host is a deterministic oracle. Even for kernels too big for real silicon.

Per-invocation cost uses a two-run difference. Run each kernel once, then eleven times. Then $(\text{metric}_{11} - \text{metric}_1)/10$ cancels the fixed startup. What remains is one clean invocation.

flowchart LR
  K["kernel (C)"] --> H["host build<br/>x86-64 IEEE-754"]
  K --> A["AVR build<br/>avr-gcc softfloat"]
  H -- "CRC + trace oracle" --> V{"bit-exact<br/>match?"}
  A --> G["gem5 AVR model<br/>op-mix + cycles"]
  G --> V
  V -- "valid run" --> R["roofline + baseline<br/>per-invocation (i11 − i1)"]

Thirteen kernels span three categories. Estimation and control in fp32. DSP in fp32. Inference in int8.

All thirteen validated bit-exact against the host. No run hit an unresolved ISA gap.

§1 — Where the cycles go

The headline is the cost of software float. Kernels with little real work still retire hundreds of thousands of instructions. The EKF covariance predict alone is 800k.

Each fp operation becomes a softfloat call. That is 50 to 170 instructions for one add or multiply. The arithmetic helpers dominate everything. This is the tax the coprocessor was meant to remove.

§2 — The roofline

Now the real question. If hardware arithmetic removes the softfloat tax, what is the next ceiling? The roofline model answers it.

The proposed core has a memory roof and a compute roof. AVR data memory moves about 0.5 bytes per cycle. LD/ST cost ~2 cycles per byte. The compute roof at SIMD width $W$ is $W$ ops per cycle. The two meet at a ridge intensity:

$$I_{\text{ridge}} \;=\; 2W \;\; \text{ops/byte}.$$

Where a kernel sits decides what helps. Right of the ridge, more lanes help. Left of it, only bandwidth helps. Here is the per-invocation data. I is arithmetic intensity. sp@W is attainable speedup over softfloat at width $W$.

Two findings, in order.

First: the baseline is compute-bound, on softfloat. Between 58% and 98% of cycles sit in arithmetic helpers. That is ~100 to 170 cycles per fp op. A scalar hardware FP/MAC datapath removes it. That alone is a 6× to 16× speedup — the sp@1 column. So far the coprocessor looks great.

Second: arithmetic intensity is low. Really low. Measured intensities run 0.08 to 0.61 ops/byte. The scalar ridge sits at 2 ops/byte. Every kernel is far to the left. Every ridgeW is below 1.

Now look at the last three columns. The speedup at width 1, 4, and 8 is identical. Once arithmetic moves to hardware, the kernels go memory-bound. The lanes sit idle, waiting on loads. Wide SIMD buys nothing. The lanes have no data to chew on.

§3 — Against a real FPU

One more check. Maybe softfloat is the wrong baseline. So I ran the same kernels on ARM64 and RISC-V in the same gem5. Both have hardware FP. The output is IEEE-754 bit-identical across all three. The byte axis comes from the memory controller, so it is architecture-independent.

On the fp kernels, ARM64 needs 17 to 76× fewer instructions than AVR softfloat. RISC-V is similar. That is the FPU advantage. AVR turns each fp op into a 50–170-instruction call. ARM and RISC-V do it in about one.

Throughput tells the same story. ARM and RISC-V hit 0.18 to 0.70 fp-ops/cycle. Near the scalar FP roof of 1. AVR softfloat manages 0.006 to 0.010. A 25 to 87× gap.

The int8 kernels show a smaller gap. All three do integer MACs there. So the AVR penalty is just its 8-bit width, not softfloat.

The verdict that killed the original plan

The machine I set out to build is wrong. Wide SIMD is the wrong answer. The speedup is real. But width does not unlock it. The ceiling is memory bandwidth. You don't raise that ceiling with more ALUs.

What the data argues for instead:

1. A scalar hardware FP/MAC datapath. That alone recovers the 6–16×. It removes the softfloat tax that dominates the baseline.
2. More memory bandwidth. Wider loads and a local scratchpad. That, not lane count, sets the post-FP ceiling.

There is a sharper point from §3. The AVR-XPU cannot beat an FPU-equipped ARM or RISC-V on raw fp throughput. So its case is not peak FLOPS. Its case is energy and area for a stripped, domain-specific datapath. A minimal fp/int8 MAC, fed by enough bandwidth, competing on energy-per-op.

My kill-criterion did fire. I had written it down at the start. Kill the project if it is memory-bound. But it killed the right thing. It killed wide SIMD, not the coprocessor. A lean arithmetic core still delivers the win. It just should not be vector-wide.

Why I'm glad I measured first

The elegant path was tempting. Spend a month on an 8-lane vector unit. Then watch seven lanes starve at simulation time. Instead the analysis was a harness, a validated model, and a spreadsheet. It redirected the whole project before any RTL.

The cheapest mistake is one you catch in the model. Intuition about bottlenecks is often wrong. A roofline plot shows where the bottleneck actually is.

---

The gem5 AVR model and ISA work live in a fork (ragnar-vallhala/gem5, branch btp). The harness, kernels, and every run-log live in AVR-XPU. All numbers and figures here are from validated, bit-exact gem5 runs.