BxBChan vs AMD/Xilinx Channelizer Deep Dive
BxBChan vs AMD/Xilinx Channelizer Deep Dive
The current alternative to purchasing a BxBChan is to build a channelizer yourself using available tools. AMD/Xilinx has a demonstration of how to do this using their Vitis software to program the AI engines and PL fabric on their Versal FPGAs. How does this example compare to a BxBChan?
AMD/Xilinx DSP experts created the channelizer example design in the presentation below. This web page shows how this design can be matched using a BxBChan.
The features of this design can be matched almost entirely by an off-the-shelf BxBChan: 2Gsps complex input samples, critically sampled channelizer, 4096 channels, 36 filter taps. One exception is that current BxBChans only support 100dB of dynamic range. The AMD/Xilinx design uses large 32-bit widths in the AI engines, which should allow it to exceed 150dB of dynamic range. However, for most applications 100dB of dynamic range is sufficient, so BxBChan bit widths are set to achieve 100dB of dynamic range.
To process the 2Gsps complex input, the BxBChan FPGA clock is set to 500MHz, and processing parallelism is 4 complex data Points Per Clock (PPC4). PPC4 is also known as SuperSample Rate (SSR) 4.
Three values are provided below for the number of filter taps:
This design assumes 36 filter taps, the same value used by the AMD/Xilinx design. This value is unusually high, and is only necessary for greater than 100dB dynamic range or if there is a very tight filter cutoff requirement. Filter shape is not specified in the presentation. For the BxBChan_36 the filter coefficients are selected for a completely flat passband (except for filter ripple).
This design also assumes a perfectly flat passband (except for ripple), but uses 14 filter taps. Since the AMD/Xilinx presentation has no algorithmic performance requirements nor even plots of achieved performance, it may be that the 36-tap value is not traceable to an actual algorithmic requirement. So this option assumes some flexibility on the number of taps. The value 14 comes from selecting a number of taps that provides 100dB of dynamic range from the plot below:
One of the features of BxBChans is that they come with a full range of tests for performance characterization. One of these tests is the one above, which allows the number of taps to be optimized by measuring the algorithmic filter curves. Unlike the AMD/Xilinx presentation, this allows a number of taps to be selected based on algorithmic requirements.
As can be seen, the only advantage of the perfectly-flat-passband 36-tap filter over a 14-tap filter is a tighter cutoff. Perhaps this is required, and perhaps not. To cover both cases, designs BxBChan_36 and BxBChan_14 are both carried forwards.
For this design, the assumption is that the filter response drops by 6dB at the passband edge. This is a common assumption for many filters, and it should be noted that the AMD/Xilinx presentation says nothing about passband flatness or about the filter shape.
Design BxBChan_8 uses 8 filter taps. This value comes by selecting a number of taps that provides 100dB of dynamic range from the plots below:
This BxBChan_8 design takes maximum advantage of possible flexibility in algorithmic requirements.
The resources for the AMD/Xilinx presentation can be extracted from the presentation above. Values for the BxBChan_36, BxBChan_14, and BxBChan_8 come from Vivado reports, which are part of the implementation tests included in the BxBChan release packages.
| Parameter | AMD/Xilinx Channelizer | BxBChan_36 | BxBChan_14 | BxBChan_8 |
|---|---|---|---|---|
| Fmax | N/A | 654.0MHz | 618.8MHz | 664.0MHz |
| LUTs | 66265 | 87376 | 18023 | 11699 |
| LUT % | 12.73% | 16.78% | 3.46% | 2.25% |
| REGs | 140636 | 79512 | 32575 | 25084 |
| REG % | 13.5% | 7.64% | 3.13% | 2.41% |
| DSPs | 0 | 333 | 157 | 109 |
| DSP % | 0% | 25.38% | 11.97% | 8.31% |
| BRAMs | 143.5 | 219.0 | 110.0 | 78.5 |
| BRAM % | 23.92% | 36.50% | 18.33% | 13.08% |
| AIs | 104 | 0 | 0 | 0 |
| AI % | 34% | 0% | 0% | 0% |
| Interconnects | 173 | 0 | 0 | 0 |
| Interconnect % | 45.4% | 0% | 0% | 0% |
These measurements show that the BxBChan and AMD/Xilinx Channelizer example are quite comparable at 36 taps, with each using different resources rather than one being clearly superior. The BxBFFT uses 25% of the DSPs, 13% more BRAM, and 4% more LUTs, where the AMD/Xilinx channelizer uses 34% of the AIs, 45% of the AI Interconnect, and 5.9% more REGs. It's a question of which resources are more valuable to a project.
If there is some flexibility in the algorithmic requirements for filter cutoff tightness, the 14 or 8 tap solutions become viable. The BxBChan_14 and BxBChan_8 are clearly better than the AMD/Xilinx example channelizer in all resource catetories, with the exception of using a small percentage of DSPs.
When compared to a 36-tap BxBChan, the 36-tap AMD/Xilinx Vitis channelizer example uses more AI engines, AI interconnect, and REGs but fewer DSPs, BRAMs, and LUTs. It also increases the dynamic range from 100dB to 150dB. Which design is best depends on a number of questions.
Is greater than 100dB dynamic range necessary? The AMD/Xilinx channelizer is only clearly superior for the case of dynamic range greater than 100dB. The BxBChan currently achieves 100dB, in a design that can be implemented in Ultrascale, Ultrascale+, or Versal FPGAs. The 24x27 multipliers in the Versals would allow a BxBChan to perform up to about a 140dB dynamic range, but so far there has been no demand for this Versal-specific optimization.
Does the larger design need AI resources? AMD/Xilinx introduced the AI engines to solve important problems for the most performance-critial applications. If a significant fraction of these AI resources are used for a channelizer implementation, they are unavailable for this important work. So the AMD/Xilinx channelizer example may be contra-indicated for designs where AI engines are necessary. If AI engines are not necessary, then why not use a cheaper part with more DSPs and BRAMs and no AI engines? Since the BxBChan uses no AI engines, it either preserves the AI engines for important work or it allows more cost-effective designs with less expensive FPGAs.
Is there uncertainty or flexibility in the channelizer's algorithmic requirements? The curves provided above show how 14-tap or 8-tap BxBChans can take advantage of requirement flexibility to greatly lower resources. Where algorithmic requirements are uncertain, the filter performance information included in BxBChan deliveries can also help clarify the uncertainty to provide optimal solutions. The AMD/Xilinx channelizer example does not include such information, which makes it difficult to achieve these optimizations. The AMD/Xilinx channelizer example would also not achieve the same benefit from these optimizations, since many of its resources are in PL to AI communication, which doesn't change with the number of taps for that design. Thus the BxBChan has a significant advantage in producing an efficient design that matches algorithmic requirements.
Is it desirable to have a channelizer development project, or is it preferable to just have the channelizer? AMD/Xilinx presented an example of how to do a development project to implement a channelizer - leaving out the initial work of algorithm design, the effort of learning to control Vitis, and the final work of verification and testing. On the other hand, a BxBChan is delivered quickly with no development effort. The implementation work of a BxBChan is already done upon delivery, with only a need to set customization options and integrate it. The performance curves provided with the BxBChan support algorithm design, and verification tests are included in the release for inspection. Support is provided. Pipelining and memory placement options streamline integration. BxBChans can typically be delivered in under a week, which prevents risk to project schedules but also allows the possibility of early prototypes for capability demonstrations. So using a BxBChan saves significant project schedule, hours, expertise, and risk.
Will the channelizer work with your tools? The BxBChan is delivered as raw System Verilog RTL, ready to work with a wide variety of available development tools or integrate into Vitis or non-Vitis projects. The AMD/Xilinx channelizer only works with tools that interoperate with Vitis.
Will the channelizer work at the desired number of channels and input sampling rate? The AMD/Xilinx design example is only for a specific number of channels and a specific sampling rate with complex input samples. For smaller cases the AMD/Xilinx example would be overkill and wasteful of resources, and for larger cases it might not work because resources would be exceeded. If algorithmic requirements have flexibility, The AMD/Xilinx example could not take advantage of that flexibility without modification. So any parameter changes would likely require a redesign. For the BxBChan it's also true that parameter changes require a different design, but in this case you just purchase the correct one off the shelf. Furthermore, the BxBChan works with a much larger range of channel sizes and parallel processing rates than the AMD/Xilinx toolset supports. The BxBChan also supports input of real samples instead of complex samples, as is sometimes needed for direct processing of raw ADC data. So the BxBChan is much more flexible to meet design needs.
Should the design be future-proof? The AMD/Xilinx tools for developing channelizers appear to have no end of support from AMD/Xilinx, but the lifetime of the design is limited to that support. The RTL of the BxBChan also appears to have no end of support from AMD/Xilinx, but is also supported by a much larger community including other FPGA vendors and ASIC toolsets. Some vendor will always support the System Verilog RTL of the BxBChan.
Is the design suitable for cost-critical applications? The AMD/Xilinx channelizer development methodology ties a design to AMD/Xilinx's more expensive line of Versal chips, but the BxBChan works fine with more cost-effective older-generation chips such as Ultrascale and Ultrascale+. Support for AMD/Xilinx Series7 FPGAs is being deprecated, but could be revived. Thus the BxBChan is the choice for the most cost-critical applications.
Do you need a channelizer? If you're thinking of a channelizer, and you know approximately what you need, you should contact BxB to get BxBChan sizing information. Then you can see how a BxBChan will fit into your design. Sizing information and performance plots are quick to obtain. Then you can decide what's right for you.