Floating-Point Arithmetic: Performance vs. Area on an FPGA

ECE 4515 — Digital Design II · Virginia Tech · Spring 2026

A hardware design-space exploration: build the same floating-point datapath at different pipeline depths, synthesise each on a Cyclone V, and measure what the extra performance actually costs in silicon.

The question

Deeper pipelines let a datapath run at a higher clock, but each additional stage costs registers, and wider or faster arithmetic units cost logic and DSP blocks. On a fixed device, that budget is finite.

How much area does a given amount of floating-point performance cost, and where does the exchange rate stop being worth it?

Method

Three related builds, all targeting a Terasic DE1-SoC (Cyclone V 5CSEMA5F31C6) under Quartus Prime 25.1:

Latency sweep. A floating-point adder built at 5, 6, 7, 8, 9, and 10 cycles of latency, each a separate module, exercised from a common testbench. Varying only pipeline depth isolates its effect from every other design decision.

Performance configuration. Wider, faster arithmetic — fp_add_sub_13, fp_add_sub_15, fp_mult_15, fp_mult_21 — built for throughput.

Area configuration. The same functional problem solved with minimal units — fp_add_sum_5, fp_mul_5 — driving a solver module, with a monitor and hex displays for on-board observation.

Each build was taken through full synthesis and fitting, and results read from the Quartus fitter and timing analyser rather than estimated.

Results

The performance configuration costs 2.2× the logic, 3.4× the registers, and 6× the DSP blocks of the area configuration.

The timing figures are the more interesting half. Both designs close timing, but they sit in completely different places relative to their constraint: the area build finishes with over 13 ns of slack, while the performance build clears by half a nanosecond. One has room for another feature or a faster clock; the other is done — any further logic on that path fails.

(The two builds are constrained differently, so the slack figures indicate margin within each design rather than a like-for-like comparison.)

The 5–10 cycle adder sweep sits underneath this. At 330 ALMs and 288 registers, that testbench build is small enough that pipeline depth is the only variable that moves, which is what makes it a clean measurement of latency-versus-registers before the larger configurations add confounds.

What I took from it

Register count scaled faster than logic. Going for throughput more than tripled register usage while only doubling ALMs — pipelining costs state, not gates, and on an FPGA that is the resource that runs out in a way you feel later, when a subsequent design needs the flops.

The DSP jump from 1 to 6 blocks is the other lesson: hard arithmetic blocks are a small, fixed pool (87 on this device), and a design that spends six of them on floating-point multiply has made a commitment that constrains everything built afterwards.

This is the same exercise as tuning cache and core parameters in a simulator — which I did in Chipyard — except the cost is measured in ALMs and DSP blocks that either fit on the die or don't, rather than in simulated cycles.

Related work in the same course

• Road Rage — the course's final project, a full VGA game in RTL
• A barrel shifter with testbench, and an exhaustive hardware test bench that validates a serial sequential multiplier against a Quartus-synthesised reference across the full input space