The Inverse Fast Fourier Transform (IFFT) is an efficient algorithm that converts a frequency-domain representation back into a time-domain signal, performing the inverse of the FFT operation. It computes the Inverse Discrete Fourier Transform (IDFT) in O(N log N) time using the same butterfly-network structure as the forward FFT, differing primarily in the sign of the twiddle factor exponents and a 1/N scaling factor.
In practice
In embedded signal processing, the IFFT is most commonly encountered in pairs with the forward FFT: a signal is transformed to the frequency domain, manipulated (filtering, spectral shaping, equalization), and then reconstructed via IFFT. This overlap-add and overlap-save convolution pattern lets firmware perform FIR filtering of long data streams in O(N log N) rather than O(N²) time, which becomes meaningful on Cortex-M4/M7 or DSP cores processing audio, motor control, or communications data at rates in the hundreds of kilohertz or higher.
OFDM-based communication stacks (Wi-Fi, LTE modems, powerline comms) use the IFFT at the transmitter to synthesize a time-domain waveform from a set of independently modulated subcarriers. Embedded modems implemented on FPGAs or DSP cores (e.g., TI C6000, Analog Devices SHARC) rely on this heavily; even some Cortex-M-class parts running lightweight OFDM profiles use fixed-point IFFT blocks. The CMSIS-DSP library provides fixed-point (Q15, Q31) and floating-point IFFT routines optimized for Cortex-M cores, with hardware acceleration (FPU, SIMD, and where available, Helium MVE instructions) enabled depending on the target core and build configuration.
A common pitfall is forgetting the 1/N normalization. Many FFT libraries, including CMSIS-DSP, omit the scaling in the forward transform and apply it in the inverse, but some libraries do the opposite, and a few split the sqrt(1/N) factor across both directions. Always confirm the convention used by your library; an unscaled IFFT output will be exactly N times too large, producing silent overflow bugs in fixed-point code. A related issue is twiddle factor sign: the IFFT uses complex-conjugate twiddle factors (positive exponent, e^(+j2πkn/N)) compared to the forward FFT (negative exponent). Some implementations share one twiddle table and conjugate on the fly, as discussed in "Computing FFT Twiddle Factors" and "How the Cooley-Tukey FFT Algorithm Works | Part 4 - Twiddle Factors".
Frequently asked
How does the IFFT differ from the FFT algorithmically?
The core butterfly structure is identical. The two differences are: (1) the twiddle factors use the conjugate exponent (e^(+j2πkn/N) instead of e^(-j2πkn/N)), and (2) the output is divided by N. In practice, many implementations simply conjugate the input, run the standard forward
FFT kernel, conjugate the output, and divide by N, reusing the same code path entirely.
Does the IFFT require power-of-two input sizes?
The most common Cooley-Tukey radix-2 IFFT requires sizes that are powers of two (64, 128, 256, 1024, etc.). Mixed-radix variants (radix-4, split-radix, or arbitrary-N algorithms such as Bluestein's) relax this constraint. Many embedded DSP libraries, including CMSIS-DSP, primarily support power-of-two sizes, though some libraries and configurations do support mixed-radix or other sizes. If your block size is not supported natively, common workarounds include zero-padding to the next supported size, selecting a different block size, or using a mixed-radix or arbitrary-N implementation.
Can I use the same FFT library routine for both the forward FFT and the IFFT?
Often yes. A common technique is to conjugate the frequency-domain input array, call the forward
FFT, conjugate the output, and divide by N. Many libraries expose a separate ifft() entry point that does exactly this internally. CMSIS-DSP provides dedicated arm_cfft_f32 and related functions with an ifftFlag parameter to select direction, so you do not need to implement the conjugation manually.
What causes overflow or incorrect results in a fixed-point IFFT?
Two main sources: (1) Missing or mismatched normalization -- if the library does not apply the 1/N scale, the output saturates or wraps. Check your library's documentation for where scaling is applied. (2) Intermediate overflow during the butterfly stages. Fixed-point IFFT implementations often right-shift by 1 at each butterfly stage to guard headroom, which distributes the 1/N scaling across log2(N) stages rather than applying it all at once. CMSIS-DSP
Q15 and Q31 variants use this approach.
When is an IFFT used instead of direct time-domain synthesis?
When you need to synthesize a time-domain waveform from a desired spectral description, or when
convolution with a long
FIR filter is cheaper done via
FFT multiply IFFT than direct convolution. For filters with hundreds or thousands of taps, the overlap-add method (FFT, multiply by frequency-domain filter coefficients, IFFT) is typically faster on MCUs with hardware multiply-accumulate or
SIMD support, such as Cortex-M4/M7 cores, than a direct convolution loop.
Differentiators vs similar concepts
The IFFT is sometimes conflated with the IDFT (Inverse
Discrete Fourier Transform). The IDFT is the mathematical definition of the operation and runs in O(N²) time via direct summation. The IFFT is a class of fast algorithms that compute the same result in O(N log N) by exploiting the symmetry and periodicity of the complex exponential basis -- the same insight the
FFT uses for the forward transform. In casual usage "IFFT" and "IDFT" are often used interchangeably, but in performance-sensitive embedded contexts the distinction matters: only the IFFT is practical for real-time block sizes above a few dozen points on most MCUs.
