My last post benchmarked a simulated buck-converter control loop on a Nucleo-F767ZI. I talked about memory placement, killing off divisions, clock speed, I/D-cache. Last best was 100 cycles, and I left it there. Now I wanted to look deeper and see if that could be brought down further.

Phase 7: what does -O2 actually buy you?

I didn't want to just rebuild the whole project at -O2, because then every number from the last post would shift at once and I'd have no way to say which change caused what. GCC lets you override the optimization level for one function only, so I did that instead:

__attribute__((optimize("O2")))
__attribute__((noinline))
static void control_step_dtcm_zerodiv_o2(void)
{
    /* exact same body as control_step_dtcm_zerodiv() */
    ...
}

noinline matters here, without it, GCC would just inline this -O2 function straight into its -O0 caller and the whole point of isolating it disappears.

29% off, just from a compiler flag on one function. I checked the disassembly to see why, and it's satisfying: GCC glued almost every multiply-then-add in the function into a single fused-multiply instruction, on its own, no code change from me:

vfma.f32 s13, s14, s10     ; integral += error * DT
vfma.f32 s15, s14, s11     ; the KI * integral term
vfnms.f32 s14, s13, s15    ; duty * V_IN, fused into a subtract
vfms.f32 s15, s8, s9       ; v_out * INV_R, same deal
vfma.f32 s13, s14, s12     ; i_l += di_dt * DT
vfma.f32 s14, s15, s12     ; v_out += dv_dt * DT

(vfnms/vfms are the same, just for subtraction instead of addition.)

One honest caveat: I can't say that whole 29-cycle drop is "the FMA instruction." -O0 also just wastes a lot of cycles shuffling things through the stack that -O2 stops doing regardless of fusion. This number is both effects mixed together, not FMA alone.

Phase 8: can we make use of SMLAD instruction ?

If we look at this equation:

duty = KP * error + KI * integral;

That's two multiplies added together. Exactly the shape the M7's SMLAD instruction is built for: one cycle, two 16-bit multiplies, one add. The other two lines (di_dt, dv_dt) don't have that shape, so I left them alone. Only this one line moved to fixed-point; everything else in the function stayed plain float.

Before → after, for the four variables in that line:

What comes out of SMLAD, and what happens to it after:

int32_t duty_acc = __smlad(KP_KI_PACKED, err_int, 0);        /* KP*error + KI*integral, one instruction */
int16_t duty_q15 = (int16_t)((duty_acc + (1 << 10)) >> 11);  /* shift back down into q15 range */
duty = (float)duty_q15 * INV_Q15_SCALE;                       /* back to an ordinary float */

One instruction does both multiplies and the add. The two lines after it undo the fixed-point trip: shift the accumulator back into q15 range, then convert straight back to float so the rest of the function — di_dt, dv_dt, both still plain float the whole time.

SMLAD itself really is cheap. One instruction, one cycle, for two multiplies and an add. But getting error and integral into the right shape for it costs way more than that: rounding and converting each one to fixed-point, then packing them together, adds up to somewhere around 20-25 instructions to save maybe 6. On a chip with a real hardware FPU, plain float math is already about as fast as instructions get, so there was never much room for this to pay off on just one lone multiply-add. Honestly: SMLAD lost here. Roughly 2x worse than the plain -O0 float version.

Phase 9: can we go lower?

Every state variable in this whole project is volatile. volatile forces a real memory access on every single read and write, even inside one function, even when nothing else could possibly be touching that memory at the same time. Looking at the Phase 7 disassembly, that's exactly what's happening — loads and stores to DTCM sitting in between instructions that could otherwise have just passed values register-to-register. Dropping volatile from the state (keeping it only on the cycle-count variable itself, which is the actual thing being measured) let -O2 keep the variables error, integral, duty, di_dt, dv_dt, sitting in FPU registers the whole way through, only writing back to memory at the end.

Second idea, from just staring at the five lines: dv_dt = INV_C * (i_l - v_out*INV_R) never actually needed duty, error, or integral — it only needs i_l and v_out, and those don't change until the very end of the function. Moving dv_dt equation earlier changes nothing about the math or the result:

float error = V_TARGET - v_out;
float dv_dt = INV_C * (i_l - v_out * INV_R);   /* moved up, same value either way */
integral += error * DT;
duty = KP * error + KI * integral;

I tested both changes separately, same as every other phase here:

−11 and −4 add up to exactly −15, so these are two genuinely separate wins. And the disassembly backs both of them up: the de-volatiled version loads each variable once and stores it once instead of round-tripping through memory constantly; the reordered version shows dv_dt's instructions actually mixed in with the rest of the chain's instructions.

New best case: 56 cycles. That's 44% off the original -O0 number, from software changes alone, same chip, same clock.

I also measured these combinations:

(I didn't actually build that second row — -O0 never keeps a value in a register across two statements regardless of any qualifier, so I don't expect removing volatile there to move the number.)

The honest ranking, apples to apples: -O0 sits around 100 whether or not volatile is there, because -O0 throws away the exact opportunity volatile would even be blocking. -O2 + volatile drops to 71 purely from fusion and general codegen quality. -O2 + non-volatile drops further to 60, and that last 11-cycle gap is volatile's entire real cost that only shows up once you're running an optimization level aggressive enough to have wanted the register in the first place.

Where things stand now

Is this the limit, or am I missing something?

• Phase 8's loss is specific to this chip and this shape of math. Something with several dot products back to back, which is what SMLAD is actually built for, could easily go the other way.

• Phase 9's reorder trick only found one independent piece to exploit. A busier control loop might get a lot more out of the same idea.

• v_out, i_l, and duty here would be read from an ADC register and a PWM compare register. Those two specific touchpoints do need volatile in a real implementation. The Phase 9 finding doesn't disappear because of that, though, it just narrows: read the ADC once into a plain local at the top of the function, do all the intermediate math (error, integral, duty, di_dt, dv_dt) as ordinary non-volatile values exactly like this phase did, then write the final duty into the PWM register once at the end. Two real volatile touches instead of zero.

So here's a genuine question for anyone who does this for a living: is 56 cycles close to what this chip can actually do for this shape of math, or is there real headroom left that I just haven't found? If you've pushed a Cortex-M7 control loop further than this, I'd genuinely like to hear how.

Either way it was worth the time. Went from 294 cycles down to 56 by just paying attention to what the compiler and the hardware were actually doing, one change at a time.

Please reach out if you want to look at the code!

Next up is a new physics problem on a different silicon.

Happy weekend :)

Where this started

I was talking to a few folks building power supply components for AI infrastructure. A lot of engineering is currently focused on innovative Gallium-Nitride based FETs due to their high switching frequencies and low switching losses at high frequencies. I was more curious around how a controller could cater to such high frequencies. Basically, the controller has to supply a PWM signal to the MOSFET to switch it. So although you have a high performance MOSFET, you need an equally capable controller to be able to switch it.

These converters sit on drones, aircraft, robots, data centers. They need to be cost effective and light-weight and small size. So you can't use a GPU or a desktop computer. You need a microcontroller or a DSP.

So the goal became: take a DSP/microcontroller, reduce the problem (mathematically) to a single simplistic loop, calculate the number of CPU cycles it takes to generate the output of this loop, optimize it.

I have deliberately kept it super simple: no I/O, no ADC, no output PWM, single core CPU. It all boils down to how fast this loop can run, given it has all the inputs 'somewhere' close to the CPU

My development board is a Nucleo-F767ZI: an STM32F767ZI, Arm Cortex-M7, clockable up to 216 MHz, with 512KB of RAM split into 128KB of DTCM, 368KB of AXI SRAM1, and 16KB of AXI SRAM2, plus 16KB each of L1 instruction and data cache.

The datasheet -> https://www.st.com/resource/en/datasheet/stm32f767zi.pdf

The application under test

The thing being optimized is deliberately simple: a simulated single-phase buck converter (12V in, 5V target out) driven by a PI controller — proportional-integral, no derivative term.

The physics:

L * di_L/dt = D(t) * V_in - v_out
C * dv_out/dt = i_L - v_out / R

discretized with forward Euler. The controller itself is:

error    = V_target - v_out
integral += error * dt
duty      = Kp * error + Ki * integral   (clamped to [0.01, 0.95])

Our main control loop computes duty cycle (a float, 0.01–0.95) → that gets written into a timer's compare register → the timer hardware generates the actual high-frequency square wave at that duty ratio → a gate driver IC boosts and level-shifts that logic-level signal to what the MOSFET gates need. The control loop only ever touches the first step; everything from the timer onward is fixed-function hardware doing exactly what it's told.

The whole point is: how fast can this one real control loop run, and what does each architectural detail actually buy us?

That question collapses to a single metric. control_step() runs once per switching cycle, so:

max_switching_frequency = clock_frequency / cycles_per_control_step_call

Every experiment below is really just an attempt to shrink the denominator.

Methodology

Timing comes from the Cortex-M7's built-in DWT (Data Watchpoint and Trace) cycle counter — a free-running counter built into the core, no peripheral clock or external hardware needed:

#define DEMCR       (*(volatile uint32_t *)0xE000EDFCUL)
#define DWT_LAR     (*(volatile uint32_t *)0xE0001FB0UL)
#define DWT_CTRL    (*(volatile uint32_t *)0xE0001000UL)
#define DWT_CYCCNT  (*(volatile uint32_t *)0xE0001004UL)

static inline void dwt_init(void)
{
    DEMCR   |= (1UL << 24);   /* TRCENA: turn on the trace/debug block */
    DWT_LAR  = 0xC5ACCE55UL;  /* unlock DWT registers */
    DWT_CYCCNT = 0UL;
    DWT_CTRL |= 1UL;          /* enable the free-running cycle counter */
}

Each variant of control_step() runs in a tight loop of 10,000 iterations, timed like this:

for (loop_count = 0; loop_count < 10000UL; loop_count++)
{
    uint32_t start = DWT_CYCCNT;
    control_step_variant_N();
    uint32_t stop = DWT_CYCCNT;
    elapsed_cycles_variant_N = stop - start;
}

Only the last iteration's timing survives, that's the steady-state cost once everything has settled.

One more deliberate choice: everything below was built at -O0. That means no compiler optimizations hiding what a straightforward, un-clever implementation actually costs — every intermediate value round-trips through a stack slot, every const read is a real memory load.

The five variants under test

Every experiment below reuses the exact same PI control math from control_step() — physics and controller code untouched. Here's the naive version, the starting point every variant is measured against:

static void control_step_naive(void)
{
    float error = V_TARGET - v_out;
    integral += error * DT;
    duty = KP * error + KI * integral;

    if (duty > 0.95f) duty = 0.95f;
    if (duty < 0.01f) duty = 0.01f;

    /* three real divisions, no precomputed reciprocals */
    float di_dt = (1.0f / L_VAL) * ((duty * V_IN) - v_out);
    float dv_dt = (1.0f / C_VAL) * (i_l - (v_out / R_LOAD));

    i_l   += di_dt * DT;
    v_out += dv_dt * DT;
}

Three vdiv.f32 instructions per call: 1.0f / L_VAL, 1.0f / C_VAL, and v_out / R_LOAD. What changes between variants is only two things: where the live state (v_out, i_l, duty, integral) physically sits in memory, and how many of those three divisions get precomputed away as constants — INV_L (= 1/L_VAL), INV_C (= 1/C_VAL), INV_R (= 1/R_LOAD) — instead of recomputed on every call. Five variants exist, testing those two axes independently:

Variants 4 and 5 aren't a separate axis from 1/2/3 — they're the same DTCM placement, just with the arithmetic changed.

All five variants run back-to-back in the same build, so a single flash-and-run gives a direct, apples-to-apples comparison instead of stitching together numbers from separate rebuilds.

Phase 0 — starting point: SRAM1 and SRAM2

The naive, 3-division version of control_step() was measured first with its state living in SRAM1, then again with it moved to SRAM2 — two different physical RAM banks, both reached over the chip's shared AXI bus matrix rather than wired straight into the core. Referenced directly from the datasheet

The 7-cycle gap is noise. Per ST's AN4667 system architecture app note, SRAM1 and SRAM2 are described identically: both plain banks accessible from the AHB bus matrix, with no documented latency difference between them. This is the least-optimized memory placement available on this chip.

Phase 1 — moving to DTCM

Same math, same constants, only the variables' physical address changed — this time onto DTCM, the 128KB bank wired directly to the Cortex-M7 core with zero wait states, bypassing the shared bus matrix entirely. Referenced directly from the datasheet

A ~12% drop just from moving three floats and one duty-cycle variable off the shared bus. This DTCM-vs-SRAM gap held at a nearly constant ~39-41 cycles in absolute terms through every later phase that didn't involve caching, even as it shrank as a percentage.

Phase 2 — DTCM, partial division removal

vdiv.f32 is a real cost, but there's no published Cortex-M7 instruction-timing table to quote. The only way to find out is to measure before/after.

INV_L and INV_C — the reciprocals of the inductor and capacitor values — get precomputed once as compile-time constants, removing 2 of the 3 divisions per call.

~14 cycles per division removed after pre-compute.

Phase 3 — DTCM, all divisions removed

R_LOAD is just as fixed a constant as L_VAL/C_VAL — only v_out (the numerator) varies at runtime — so the last division, v_out / R_LOAD, becomes v_out * INV_R the same way the other two did.

Worth noting: the first two divisions saved ~12-13 cycles each (25 total), but the third only saved ~11. Division latency on this core isn't perfectly uniform per call.

Phase 4 — 216 MHz

Reaching the chip's full 216 MHz from bare metal takes a specific sequence of register writes: enabling Over-drive mode (required above 180 MHz), raising flash wait states before switching the clock so the core doesn't fetch corrupted instructions once flash can no longer keep up, then configuring and locking the PLL.

Result, same 5-way comparison, now at 216 MHz:

Cycle counts went up by a strikingly uniform ~126 cycles across every variant, regardless of memory placement or division count. That uniformity is itself informative: it's strong evidence the added cost is pure instruction-fetch overhead (same code, same Flash, same new wait-state count for everyone), fully decoupled from the DTCM/SRAM/division questions under test.

The clock went up 13.5x; max achievable switching frequency only went up ~9-10x (e.g. zero-div: 62.0 kHz → 552.4 kHz). That gap — 13.5x of clock buying only ~9.5x of usable frequency — is the real, quantified cost of running unaccelerated flash fetches at high speed.

Phase 5 — I-cache

I-cache is the direct mitigation for exactly that gap:

#define SCB_CCR   (*(volatile uint32_t *)0xE000ED14UL)
#define ICIALLU   (*(volatile uint32_t *)0xE000EF50UL)

static inline void icache_enable(void)
{
    ICIALLU = 0UL;              /* invalidate I-cache (write-only, self-clearing) */
    __asm volatile ("dsb");
    __asm volatile ("isb");
    SCB_CCR |= (1UL << 17);     /* IC: instruction cache enable */
    __asm volatile ("dsb");
    __asm volatile ("isb");
}

I-cache recovered a real, uniform ~55 cycles per call — but that's only ~44% of the 216 MHz penalty, not all of it. The likely reason: I-cache only accelerates instruction fetches. control_step() also loads several const float values every call (L_VAL, C_VAL, R_LOAD, V_TARGET, KP, KI, DT), and those live in .rodata, which sits in Flash right next to the code. Loading one is a vldr from a Flash address: a data read. I-cache does nothing for that.

Phase 6 — D-cache

D-cache covers exactly the gap I-cache couldn't: data reads/writes to anything reached over the AXI bus matrix — Flash .rodata and SRAM1/SRAM2. It does not cover DTCM, which bypasses the bus matrix entirely.

#define SCB_CCSIDR  (*(volatile uint32_t *)0xE000ED80UL)
#define SCB_CSSELR  (*(volatile uint32_t *)0xE000ED84UL)
#define SCB_DCISW   (*(volatile uint32_t *)0xE000EF60UL)

static inline void dcache_enable(void)
{
    uint32_t ccsidr, sets, ways;

    SCB_CSSELR = 0UL;                        /* select L1 data cache */
    __asm volatile ("dsb");

    ccsidr = SCB_CCSIDR;
    sets = (ccsidr & 0x0FFFE000UL) >> 13;    /* NumSets - 1 */
    do {
        ways = (ccsidr & 0x00001FF8UL) >> 3; /* Associativity - 1 */
        do {
            SCB_DCISW = ((sets << 5) & 0x00003FE0UL) | ((ways << 30) & 0xC0000000UL);
        } while (ways-- != 0UL);
    } while (sets-- != 0UL);

    __asm volatile ("dsb");
    __asm volatile ("isb");
    SCB_CCR |= (1UL << 16);   /* DC: data cache enable */
    __asm volatile ("dsb");
    __asm volatile ("isb");
}

Result:

154 vs. 151 vs. 151. The DTCM-vs-SRAM penalty that held steady at 12-16% through every single earlier phase is gone. Once the working set is small enough to be fully cache-resident (which this tiny, hot, 10,000-times-repeated loop is), where the data physically lives stops mattering. Caching didn't shrink the memory-placement penalty, rather it erased it.

That still leaves a real question: DTCM never touches D-cache at all, so why did the three DTCM variants drop by 208-233 cycles too, not just "modestly"? DTCM's own state genuinely never goes through D-cache. But control_step() also reads several shared plant/controller constants (V_TARGET, DT, KP, KI, L_VAL, V_IN, C_VAL, R_LOAD) that live in Flash .rodata, and those are data-cacheable — for every variant, DTCM included. Once D-cache is warm, each of those reads turns from "cross the AXI bus matrix, pay flash wait states" into "hit in cache" — and a cache hit is fundamentally faster than any bus transaction, wait states or not, because it skips the AXI-bus-matrix crossing entirely, not merely the 216MHz-specific wait-state tax.

Every variant gets the same "Flash constants are now cacheable" benefit, since they all read the same shared constants. SRAM1/SRAM2 get an additional benefit on top of that — their own state variables, which used to cost a bus-matrix trip on every access, now also hit in D-cache. DTCM never collects that second benefit (its state was already bypassing the bus matrix for free), which is exactly why its drop is the smaller of the two groups, not why it barely dropped at all.

Two honest caveats belong right next to that result, not buried in a footnote. First, this doesn't generalize to every workload — a larger working set that doesn't fit in 16KB of D-cache, or a colder/less-repetitive access pattern, would very likely show the DTCM-vs-SRAM gap again. Second, part of the drop's overall size (not its DTCM-vs-SRAM split) is specific to -O0: GCC reloads each const float from Flash on every use, not once per function (DT alone is referenced three times in control_step()). Each of those redundant reloads was a full stalled Flash read before; now they're all cache hits. An -O2 build would keep more of these values in registers to begin with, so D-cache's relative contribution there would likely look smaller.

Summary in a few words

That's roughly a 45x improvement in the number that actually matters for a real converter — achievable switching frequency — built entirely from independently measured, real-hardware levers: moving off the shared bus into DTCM, eliminating divisions, raising the clock, enabling I-cache, enabling D-cache.

Again, this is purely raw bare metal performance of the hot loop. We have ignored the ADC, PWM generation, real switch inefficiency and other losses. It also won't be fully analogous to production DSP code, since the state space will likely be larger and other data will be competing for the same cache/SRAM/DTCM space. But the experiment sets a clear direction for where to focus optimization effort. That's the whole point: how fast can we ultimately go with the silicon?

In future, I will post more around such software optimizations meant for real physics problems. Happy week ahead :)