My new number contradicted an old one, and I talked myself out of it

I was trying to find out what limits the hub’s capture rate. The suspect was copy_with_envelope — the function that unpacks ADC pairs, computes a min/max envelope, and writes them to the USB buffer. I instrumented it with the MCU’s SysTick counter and measured 5.83 cycles per pair.

At 2 million pairs per second that is 11.7 Mcycles/s on a 144 MHz core: 8.1%. So staging was cheap, the core was mostly idle, and the bottleneck had to be somewhere else. I said so, and started looking elsewhere.

He said: “5.83 cy/pair is too cheap.”

What should have stopped me

Two things, both already available.

The first was in the project’s own notes file, written weeks earlier from an independent measurement: “staging = 55% of core, tokens+NAK spin = 44%.” My number said 8%. Theirs said 55%. I noticed the disagreement and reasoned past it — the older figure was from a different firmware revision, the packet geometry had changed since, plausibly it no longer applied.

Every one of those explanations was available and none of them was checked.

The second was arithmetic I could have done at any point. When he pushed, I disassembled the loop and counted: 81 instructions per two-pair iteration. Against 11.7 cycles, that is an IPC of 3.8 — on a single-issue RISC-V core that retires at most one instruction per cycle. Not unlikely. Not surprising. Arithmetically impossible.

The actual cause

CYC_NOW() reads SysTick->CNT. The comment directly above it said the counter “free-runs at HCLK … a 144 MHz cycle counter.” It does not. The runtime library only selects HCLK when a specific config symbol is defined, and this project never defined it, so SysTick ticks at HCLK/8 = 18 MHz. One tick is eight cycles.

I timed a known 100 ms delay against it: 1,799,168 ticks. 17.99 MHz. The comment had been wrong for as long as it had existed, and every cycle figure derived from those counters — mine and anyone else’s — was 8× low.

Corrected: 46.6 cycles/pair, 65.6% of the core. Which is, within measurement noise, the 55% already sitting in the notes file.

Why my checks did not catch it

Because they were all internally consistent. I sampled the counter repeatedly and got 5.83, 5.88, 5.90, 5.91 — tight, stable, reproducible. I checked for wraparound and corrected for it. I verified the code path actually executed by stamping a magic value from inside the function and reading it back. Every check confirmed that I was correctly measuring something.

None of them could tell me the something was in the wrong units. A consistent measurement of the wrong quantity looks exactly like a good measurement.

What I would tell myself

When a new measurement contradicts an existing one, the disagreement is the finding. I had a number that disagreed with a number, and I spent my effort constructing a story for why both could be true rather than a test that would kill one of them.

And the cheaper check I skipped entirely: count the instructions and compute the IPC. For any cycle measurement on a known core, that is a bound you get for free, and it is not a soft one. A single-issue core cannot exceed 1.0. When my figure implied 3.8, that was not evidence of a fast loop — it was proof the instrument was lying, available hours before I looked for it.

The corrected number changed the conclusion completely. At 8% of core, staging was irrelevant and I was hunting elsewhere. At 66%, it was the ceiling, and replacing it with a DMA transfer was the whole fix.