The Designs That Need an FPU

A floating-point unit is the hardware on a microcontroller that does decimal math in one instruction. A design needs one when its math carries a wide range of values and runs against a tight deadline at the same time. Software does the same floating-point math on any core. That software path takes many times the cycles the hardware does. Whether a design needs the hardware comes down to one test: does the software path fit the time the loop allows?

What an FPU adds

The floating-point unit adds a set of registers and instructions that work on IEEE-754 numbers directly. An add, a multiply, a divide, or a square root on a real number runs as one machine instruction at core speed. Arm documents the unit as giving a tenfold acceleration of single-precision floating-point operations over the software path. The hardware turns a routine that took dozens of cycles into a single step. The unit follows the IEEE-754 single-precision format, so its results match what a desktop tool produces when the same algorithm is checked off-target. That match lets a team prototype an algorithm on a workstation, then move it to the microcontroller. The numbers hold across that move. The agreement holds to the last bit only in the common cases, since rounding order and library functions vary at the edges, so a careful design still checks the on-target result against the reference. The close match shortens that check to a quick verification step. The unit holds its own register bank, sixteen or thirty-two single-precision registers depending on the configuration, so a tight inner loop keeps its working values in the floating-point file, clear of the memory traffic a software path adds. The compiler emits the floating-point instructions straight from C, so a developer writes plain real-number math and the toolchain maps it onto the hardware. One build flag turns the hardware path on. The same source then runs its math through the unit. A build option also sets how the compiler passes floating-point values between functions, so a team keeps that setting consistent across its libraries to hold the calls fast. The fused multiply-add deserves its own mention, since it computes a multiply and an add in a single rounding step, the exact shape of a filter tap or a dot product. That one instruction is the reason a signal loop on the hardware unit runs so far ahead of the same loop in software. Lazy stacking handles the unit’s registers across an interrupt, saving them only when the handler itself uses floating point. The interrupt latency stays low on a system that mixes control code and signal math. The unit also flags overflow, underflow, and invalid results in a status register, which gives a careful design a way to catch a bad number before it propagates. The format defines special values for infinity and for an invalid result, so a divide by zero produces a defined token the code can test for. A design that checks those flags turns a numerical fault into a handled event, the kind of robustness a safety loop wants.

Software covers the same math on any Cortex-M core. The compiler links a floating-point library. Each operation runs as a sequence of integer instructions, tens to hundreds of cycles deep. A loop that runs floating-point math thousands of times a second is where that per-operation cost adds up to real time. A program that only touches a few values at startup never feels it, which is why a quick glance at the code is the wrong way to judge the need. The gap between the two paths is wider on the heavier operations, since a divide or a square root costs many more software cycles than an add or a multiply. Control laws thick with those heavier operations push a software path past its time budget the soonest. Code size enters the picture too, since the software library brings its own routines for every operation the program uses. The hardware path drops those routines, so the firmware that calls the unit comes out smaller as well as faster. Power follows the cycle count, so finishing the math in fewer cycles lets the core return to sleep sooner on a duty-cycled product. A battery sensor that runs a short filter on each wake spends less energy per wake on the hardware path, which adds up over the life of the cell. The unit earns its keep on a low-power product through that energy saving as much as through the raw speed.

The unit on a Cortex-M4 handles single precision, the 32-bit float that holds about seven decimal digits. That format covers the bulk of embedded math, from a control gain to a sensor reading to an audio sample. The format carries its own scale in an exponent, so a program adds and multiplies real numbers the way the algorithm reads on paper. This readability is a quiet safeguard, since code that mirrors the math is easier to review and harder to get subtly wrong. Seven digits hold enough precision for a sensor that resolves a part in a thousand and for a control gain set to a few significant figures. The exponent reaches across many orders of magnitude, so a value near zero and a value in the thousands both sit in the same variable with no rescaling by hand. That auto-scaling is the quiet reason teams reach for floating point even where the raw speed of fixed-point would serve, since it cuts the analysis a wide-range algorithm would otherwise demand. The seven-digit limit shows up only in the rare case that needs more, such as a long running sum or a high-resolution coordinate, the place a design looks past single precision.

The math that needs it

Motor control is the classic case. A field-oriented drive runs trigonometry and a pair of coordinate transforms on every cycle of a current loop that closes tens of thousands of times a second. The sines, the cosines, and the multiplies all land in floating point in the textbook form of the algorithm. The hardware unit holds that whole loop inside its time budget on a Cortex-M4. Switching at twenty kilohertz leaves the processor about fifty microseconds per cycle for the whole control law, sensor read, and housekeeping. The floating-point transforms have to finish in a slice of that window, which the hardware unit makes routine on a Cortex-M4. A Clarke transform and a Park transform together run a handful of multiplies and a sine-cosine pair, the math that turns three-phase currents into the two values the controller regulates. The hardware unit runs that chain in well under a microsecond. The rest of the window stays free for the current sense, the PID step, and the PWM update. The same window has to absorb the worst case, the cycle where every branch goes the long way, so the margin the hardware unit leaves is the difference between a stable drive and an audible whine in the motor. Higher pole counts and faster speeds tighten the window further, which pushes more drives onto a core with the unit.

Sensor fusion is the next case. An attitude estimator or a Kalman filter blends gyroscope, accelerometer, and magnetometer readings through matrix math at the sample rate. The matrices carry values across a wide range. The algorithm leans on real arithmetic to stay stable. The unit runs that fusion step in the gap between samples. A nine-axis fusion at a few hundred hertz multiplies small matrices, normalizes a quaternion, and runs a square root or two on every update. The square roots and the divisions are the operations that punish a software path the hardest, the reason a fusion-heavy product reads the hardware unit early. The covariance update in a Kalman filter multiplies and inverts small matrices on every step. A larger state count multiplies that work steeply, so a six-state filter carries far heavier matrix math per update than a three-state one. A robot, a drone, or a wearable that fuses several sensors at a high rate sits squarely in the territory the hardware unit was added for. A faster platform fuses more often, so a fast drone updates its estimate far more often than a slow handheld. That rate, times the matrix work per update, is the load the core has to clear inside each sample period. Dropping a sample on a fusion loop lets the estimate drift, the kind of error that compounds on a moving platform. The hardware unit holds the update inside its slot. The estimate stays locked to the motion.

Audio and signal work fill out the list. A reverb, an equalizer, or an FFT runs multiply-heavy math on every sample or every frame, at a rate the ear notices the moment it slips. A navigation solution, a power-quality meter, and a vibration analyzer sit in the same place, where real math meets a fixed deadline. The audio case is strict in its own way, since a glitch in one sample buffer reaches the ear as an audible click. A filter bank that has to finish inside one buffer period, every period, gets its margin from the hardware unit running each tap as a single fused multiply-add. The headroom matters for the features stacked on top, since a synth voice, a compressor, and a reverb all draw from the same cycle budget. The hardware unit is what lets a modest Cortex-M4 carry an audio chain that a software path would choke on. Latency counts in audio alongside throughput, since a live instrument or a phone call needs the processing done within a few milliseconds end to end. The single-cycle fused multiply-add keeps the per-sample work small enough that the buffer stays short. A short buffer holds the latency down.

One thread runs through all of them. Three things hold at once: the math carries a wide range of values, the loop has a deadline, and the algorithm comes written in floating point from the start. Any design that holds those three at once reads the hardware unit as a plain requirement.

The test that decides

The decision comes down to a measurement. The team profiles the floating-point math in software on the candidate core, then sets that cycle count against the loop budget. A path that fits the budget leaves the unit optional. A path that overruns the budget names the hardware unit as the fix. The number off the profiler, taken on the real loop, settles the question that a feature list cannot. Worst-case timing carries more weight than the average here, since a control loop has to hold on every single cycle. Profiling the loop at its heaviest input, with interrupts running, gives the figure that the design has to live within. A path that fits with comfortable room invites the smaller part. A path that just squeaks by leaves a design one feature away from a missed deadline. The profile gets taken with the production compiler and its optimization settings, since a debug build runs slower and reads the wrong number. Re-running it after a real optimization pass gives the figure the shipped firmware will hold to. The same profile doubles as a check on the algorithm, since a math routine that runs long often hides a redundant operation. A cleaner formulation of the math removes it. Trimming the math and timing it again sometimes brings a software path back inside the budget on its own.

When fixed-point does the job

Fixed-point math is the path a design takes when it has no hardware FPU. It holds fractional values in plain integers, with the binary point fixed at a chosen place. Any core with no floating-point unit runs real filters and transforms this way, at full integer speed, on hardware the design already has. The Q notation names where that point sits, so a Q15 number gives fifteen bits to the fraction and one to the sign across a 16-bit word. The format costs nothing in silicon, since it rides on the integer multiplier every Cortex-M core already carries. A Q15 or Q31 format reserves a set number of bits for the fraction, so a value lives as an integer the code scales by a known power of two. The arithmetic is ordinary integer add and multiply, the operations every Cortex-M core runs fast. Multiplying two Q15 values lands a 30-bit result that the code shifts back into range, the step a developer has to place correctly at each stage. Years of audio codecs and motor drives shipped this way before hardware floating point reached the low-cost tiers, so the techniques are mature and the reference code is plentiful. Library support helps here, since the CMSIS-DSP routines come in fixed-point forms alongside the floating-point ones. A team can call a Q15 filter from the same library family. That takes some of the hand-coding off the fixed-point path.

The cost of fixed-point is the engineering. A developer picks the scale for each variable, tracks its range across every operation, and guards against an overflow at each step. That analysis is real work that gets redone in full whenever the algorithm changes. Floating point hides all of it, since the format manages its own scale. A bug in the scaling shows up as a silent loss of precision or a sudden overflow, the kind of fault a quick test misses. The engineering hours on that analysis are the real price of staying in fixed-point. The silicon price of the hardware unit is what those hours buy back. Maintenance carries the cost forward, since the next engineer to touch the code inherits the scaling scheme and the assumptions behind it. A floating-point version reads closer to the original math, which lowers that long-term cost on a product that stays in the field for years.

Dynamic range is the hard part for fixed-point. Signals that swing from tiny values to large ones force a single scale to cover both ends, which spends precision at the quiet end to hold the loud one. Holding both ends cleanly is the work a wide-range fixed-point design has to carry by hand at every stage.

Fixed-point earns its place on cost and volume. A part with no FPU costs a little less and draws a little less, so a high-volume product with simple, narrow-range math holds its margin by staying integer. The DSP instructions on the Cortex-M4 speed that fixed-point work, a topic its own guide takes up in depth. Consumer remotes, basic thermostats, and toys run their little math in fixed-point on a cent-counting part, where the engineering is a one-time cost spread across a long production run. The longer the run, the more a fixed-point design pays back the hours its scaling analysis took. Low-volume or fast-moving products read it the other way, where engineering time costs more than the part. A few thousand units of an instrument or a prototype run lands on a floating-point part, since the days saved on scaling analysis outweigh the cents added to each board. Time to market weighs in as well, since a floating-point port of a desktop algorithm reaches a working build faster than a fixed-point rewrite of the same math.

The math itself points the way. If the values span a wide range and the loop is tight, the hardware unit earns its place. If the range is narrow and known on a cost-driven part, fixed-point holds the job. A prototype settles the doubt fastest, since the same C math runs both ways with a build flag. A profiler then reads the cycles each path takes. Naming the heaviest math the loop runs, and timing it, settles the path on numbers.

Which parts carry it, and the cost

The optional floating-point unit rides on the Cortex-M4, the Cortex-M7, and the Cortex-M33. Software floating point covers the cores below them, the M0, the M0+, and the M3, where the compiler links the math as a library. A surprising amount of real signal work ships on those cores in fixed-point, so the absence of a unit does not rule a core out of a signal job. The unit changes the speed and the ease of the floating-point path. The reach of the core stays the same either way. The same logic guides a migration, since a design that grows its math over time can move from an entry core to a Cortex-M4F and pick up the unit with a recompile. Planning that path early, with the math kept in a portable form, keeps the door open to the hardware unit once a future feature needs it. A board laid out for a Cortex-M4F footprint can ship first on a cheaper part and move to the floating-point part when the firmware calls for it. That kind of headroom costs little at design time. It pays back when a later feature needs the floating-point part. A vendor builds a specific part with or without the unit, so a design that needs hardware floating point reads the part number, since the core family alone does not promise it. The letter F in a name, such as an STM32F4 part marked as a Cortex-M4F, signals the unit on many catalogues. The datasheet block diagram settles it for certain, since it draws the floating-point unit in or leaves it out.

The unit is not free on the parts that carry it. It adds silicon and a little static power, paid on every part whether the code calls it or leaves it idle. Single precision covers the bulk of embedded math at full speed on the parts that carry the unit. A design reads single precision as the default and reaches for double only when the error budget calls for it. Double precision holds about sixteen digits in a 64-bit number, the depth a long iterative solver or a high-resolution navigation fix can need. The Cortex-M7 offers it as an option, so a product that needs that depth has a clear part to reach for. A great many embedded products never touch a number that single precision cannot hold cleanly. Double precision also costs more cycles per operation and more register space, so a design that reaches for it on no clear need spends both silicon and speed. The clean rule reads single precision first, and double precision only when the math shows a real error that single cannot hold.