BxBFFT vs AMD/Xilinx XFFT
BxBFFT vs AMD/Xilinx XFFT
The BxBFFT far surpasses the AMD/Xilinx XFFT in supported sizes, supported parallelism, achievable Fmax, power consumption, LUT usage, DSP usage, REG usage, supported supported features, and supported controls. The XFFT has just a single advantage, that it typically is lower in BRAM usage.
This is backed up by the data that is discussed below.
The AMD/Xilinx XFFT has a long history, but only when processing data in a single stream at one data point per clock (PPC=1). It's only recently in Vivado 2025.2 that SSR capability was added and that it becomes comparable to a BxBFFT.
Note that "SSR" stands for "Super Sample Rate", which is the number of complex data points processed per clock. Bit by Bit Signal Processing calls the same thing "PPC", which is short for "Points Per Clock". They can be used interchangeably.
AMD/Xilinx SSR XFFTs are available in the Vivado IP Integrator to put into a Block Design. No RTL is provided; only the block design is supported.
The XFFT only supports complex-to-complex power-of-2 FFTs with SSR also a power of 2. Below is a table showing which XFFTs synthesize, in the range from 128 point to 262144 point and PPC2 to PPC64 (SSR2 to SSR64).
Note that for the BxBFFT, all the boxes on the table below synthesize properly, and many more sizes in between. The BxBFFT supports all FFT sizes that are a multiple of powers of 2, 3, 5, and 7. The BxBFFT also supports all values of PPC that evenly divide into the FFT size.
In the table above, it might seem like the sizes giving a "Route 35-66" error should be correctable, since they are under the XFFT core's limits on FFT Size and SSR. However, looking closely at the 32768-point SSR2 synthesis reports shows that that design is using 1,220,930 FDRE's. This unusually high number is far beyond the 850,560 registers in the targetted FPGA. This does not seem correctable.
This is the reason that graphs below show a limited number of points for the performance of the AMD/Xilinx XFFT. For the missing points, the AMD/Xilinx XFFT simply doesn't work.
The plot below compares Fmax estimated by Vivado. The X-Axis of the plot is divided into 6 sections, from PPC2 to PPC64. In each section, FFT size varies from 128 to 262144. This allows a single plot to show a wide overview of FFT performance across a range of FFT Sizes and PPCs.
These plots show setup-limited Fmax when each FFT is compiled with nothing else in the FPGA. Also, the plot doesn't take into account speed limits in the DSPs, BRAMs, or URAMs. So achievable speeds in a real design will be lower. However, speeds won't generally be higher. So the poor Fmax performance of the AMD/Xilinx XFFT will impose severe limits on the designs in which it can be used.
Even when the BxBFFT has far higher Fmax than a design needs, this setup margin has advantages. It gives headroom to absorb timing degradation caused by resource contention from other IP in the FPGA. As a result, BxBFFT designs will close timing more easily than AMD/Xilinx XFFT designs, and BxBFFT designs will close timing where AMD/Xilinx XFFTs cannot.
The plot below compares power consumption estimated by Vivado for the BxBFFT vs power consumption estimated by Vivado for the AMD/Xilinx XFFT.
This shows that a AMD/Xilinx XFFT takes at least 1.5 times the power of a BxBFFT, frequently twice as much power, and sometimes three times the power. As a result, BxBFFT designs are more likely to stay under limits on current draw and temperature than AMD/Xilinx XFFT designs.
This surprising results is backed up by real-world measurements from the Mazin Lab at UCSB. In their MKID processing, they need to produce a large number of sine wave "tones", which they then measure. they ran into thermal issues that prevented them from achieving the desired 2048 tones with the AMD/Xilinx XFFT. The maximum that would run were 1424 tones. Replacing the AMD/Xilinx XFFT with a BxBFFT fixed these power and thermal problems.
The thermal image below was taken by J. Smith of UCSB. Replacing the AMD/Xilinx XFFT with a BxBFFT actually lowered the die temperature from 110 degrees Celsius to 75.7 degrees Celsius -- a drop of 34.3 degrees Celsius!! The design then worked properly with the full load of 2048 tones.
"[The BxBFFT] does seem to cut the power draw pretty significantly over the stock Xilinx FFT." -- Professor Ben Mazin of UCSB
The plot below compares LUTs measured by Vivado for the BxBFFT vs the AMD/Xilinx XFFT.
The AMD/Xilinx XFFT often uses twice the LUTs of the BxBFFT.
The plot below compares REGs measured by Vivado for the BxBFFT vs the AMD/Xilinx XFFT.
The AMD/Xilinx XFFT is also much higher on REGs than the BxBFFT.
The plot below compares DSPs measured by Vivado for the BxBFFT vs the AMD/Xilinx XFFT.
The AMD/Xilinx XFFT is also much higher on DSPs than the BxBFFT.
The plot below compares BRAMs measured by Vivado for the BxBFFT vs the AMD/Xilinx XFFT. BRAMs are the one area where the AMD/Xilinx does well.
As can be seen, the AMD/Xilinx XFFT is lower on BRAMs than the BxBFFT for most cases. It's unclear why this is true. It may be in part because data is being stored by the AMD/Xilinx XFFT in distributed LUT RAM rather than BRAM. This would also explain the high LUT usage of the AMD/Xilinx XFFT.
The BxBFFT supports a much wider range of features than the AMD/Xilinx XFFT. For example, the BxBFFT has options for real-to-complex FFTs, pipelining controls, memory type controls, and controls for automatic generation of twiddles.
Here is a comparison of AMD/Xilinx XFFT controls vs BxBFFT controls in IP Integrator. First, the always-enabled inputs and outputs:
As shown, the BxBFFT doesn't display miscellaneous inputs and outputs unless they are explicitly turned on.
Next, the main configuration page, XFFT vs BxBFFT:
The BxBFFT size is hard-coded at delivery time, since the BxBFFT supports too many sizes to select at implementation time. The XFFT has code for all supported sizes built in.
The XFFT supports many other types of FFTs than just a streaming SSR FFT. Thus it has controls to select FFT type. The BxBFFT type is predetermined; only selections for Forward/Inverse exponent, Forward Control Enable/Disable, and FFT data bit width remain.
The next configuration page is as follows, XFFT vs BxBFFT:
For the AMD/Xilinx XFFT, this page selects the SSR, rounding modes, data bit width, reset types, and flow control method. This is something of a continuation of the general configuration on the first page.
For the BxBFFT, this page selects input-specific options. The input order, the input sample width, and the "fold in", which is whether input data has the zero position at the start or in the center.
The next configuration page is as follows, XFFT vs BxBFFT:
For the AMD/Xilinx XFFT, this page has coarse controls over BRAM vs LUT RAM. It has a control to select complex multiplier type. Much of this is disabled.
The BxBFFT, on the other hand, has output order specification, controls of output data width and bit position, and an option (fold out) to put zero in the center of the output data or leave it as the first sample.
The AMD/Xilinx XFFT has no more options. The BxBFFT continues with its Gain and Pipelining control tabs:
One tab selects Gain Control options. Instead of just Scaled or Not Scaled like the AMD/Xilinx XFFT, the BxBFFT offers options to adjust the rate of scaling and the amount of margin. This allows complex FFTs with mixed radix stages to be controlled in a simple fashion. There is also options to directly control scaling at each stage either statically or dynamically. For dynamic scaling, there is an amplitude monitoring option to help determine where amplitude levels are too high.
The next tab selects pipelining options. This allows extra registers to be inserted either globally or at individual stages. This is not normally needed for small to medium FFT sizes, but in the event of resource contention with other IP in the FPGA it can assist in meeting timing. The plot of Fmax earlier on this page shows how it can be effective for larger BxBFFTs where resources become tight and timing can be reduced.The next two BxBFFT tabs control memory options and multi-vector options:
The BxBFFT's memory options control tradeoffs between LUT RAM, BRAM, and URAM either globally or at individual FFT stages. For very long FFTs, coefficient storage becomes costly, so there are options to not store the coefficients but instead generate them on-the-fly.
The Multi-Vector tab allows a BxBFFT to be split into N shorter FFTs whose length is smaller by the factor of N. This allows for a limited amount of dynamic FFT sizing. For this split, all N shorter FFTs use the same twiddle tables, so some resource savings is achieved over separate FFTs. However, at the moment output data orders aren't as controllable.
As the above shows, the BxBFFT supports a much wider range of features and controls than the AMD/Xilinx XFFT. Where the two have features in common, the BxBFFT generally has finer control. Thus the BxBFFT can be more effective than the AMD/Xilinx XFFT in meeting algorithmic and implementation goals.
The BxBFFT is faster than the AMD/Xilinx XFFT and uses as little as half the power. The BxBFFT has better controls than the AMD/Xilinx XFFT, and many more capabilities and options. The BxBFFT is significantly better than the AMD/Xilinx XFFT on every metric except for BRAM usage. Even the BRAM usage can be mitigated by BxBFFT controls that let data be pushed into LUT RAM instead of BRAMs, or controls that save BRAM by on-the-fly generation of twiddles.