X || A vs. X & A (Using FPGAs From Multiple Vendors)

Are there realistic reasons to design with FPGAs from multiple manufacturers?

Humorous disclaimer: Many of us in the FPGA ecosystem are like the children of divorced parents. May I state up front that I like A (Altera) and X (Xilinx) equally, and I actually perceive the competition as being FPGAs versus the rest of the world. I was just wondering if there are legitimate reasons to include FPGAs from both vendors in a single project.

Problem definition: Processors are one of the few device types for which one cannot second source. Once committed, you are pretty well locked in. Unlike GPUs and CPUs, FPGAs take this a step further by often locking you into the tool flow. Working from the manufacturer's tools, you can compile only to the manufacturer's devices. In contrast, CPU coding is generally portable. You learn one language -- typically C or a variant -- and can compile to almost any microprocessor. GPUs fall in the middle. Nvidia's CUDA certainly won't compile to an AMD GPU, but OpenCL promises to compile either way. Hardware description languages can cross-compile, but they require a level of hardware expertise that is waning in our increasingly software-centric world.

The additional question here is whether anyone cares. Are there legitimate reasons not to be locked into X or A? Among the candidate reasons of merit is the hidden cost of ownership in learning a career-limiting tool. That term was introduced to me by an IBM researcher I respect. The idea in a nutshell is that learning a tool for just one task does not enhance one's resume, and a tool flow locked into a narrow target device brand or type may qualify.

Next, and just slightly less career-limiting than a one-brand tool, is a generic HLL (high-level language) to FPGA compiler like Impulse C, Catapult C, or perhaps OpenCL. (Disclaimer: In addition to Impulse C, Impulse provides OpenCL design services.) One pro of this approach is to be less locked in, though realistically the ability to cross-compile is imperfect. Designs often need to leverage unique HW resources of each brand of FPGA. (You may not discover that you've exhausted these resources until you are quite some way into the process.) Furthermore, different manufacturers' devices are far from socket compatible. Another possible pro of staying with a generic HLL is that it makes things slightly easier to migrate to ASIC, but again, this is not the mainstream use model.

Are there unique hardware propositions in devices from X and A that would compel you to combine them in one application? We've had only a minority of clients answer "yes" to this question. Typically, the presence of both brands in a given organization is more a testament to the discretion of the individual team leads than to any irreplaceable merit.

Our two cents on this topic is that there is some X-and-A merit in using an HLL to leverage heterogeneous programming, provide a broader tool reach, and maximize portability. Also, learning multiple career-limiting tools is probably inefficient. As for legitimate reasons to use X and A, I'd enjoy hearing suggestions from the community. And here's an bonus question: Do you think the fact that ARM and OpenCL's names keep on popping up in both FPGA brands will help increase portability?

My knee-jerk reaction is that you would be more likely to see something like (A || X || M) & L (where M & L stand for Microsemi and Lattice Semiconductor, respectively). I wonder if anyone would care to comment on this?

For complex FPGA functionality, I go with Brand X. For CPLDs, I go with XC9572XL and/or XC9536XL. If I need more than that, it's time for an FPGA. For small FPGAs, I've had good luck with ProASIC3 and Igloo from Brand M(A) [Brand M, formerly also known as a different Brand A]. However, if I were given the choice today for a small FPGA I'd certainly check out Brand L, specifically the iCE40 series (formerly known as SB).

I've used Brand A in the past with good luck, but I haven't seen a compelling differentiator between Brand A and Brand X once Brand X improved its tool usability around 2000. But then, maybe I'm just sore because AHDL didn't catch on :-)

"Do you think the fact that ARM and OpenCL's names keep on popping up in both FPGA brands will help increase portability?"

My answer is No. Aside from the standard interfaces that come with the "ARM" it is the FPGA fabric/design that makes the product, but that still depends on the vendor tool chain.

The task is to design a system rather than an FPGA that is a "smart" peripheral. A system has many independent functions that range from slow human interaction to critical algorithm calculation.

The point is that a single tool flow and design approach is not appropriate.

And the ASIC world has plenty of cheap ARMs and interfaces. The main advantage for FPGA is a shorter design time, but the number of cells and wires on the latest dice will probably make P&R times unacceptable.

Fool that I am, I can only hope that standards win over "lock-out" spec details re the soft- or hard-core processors. I think ARM is a great opportunity for some inter-brand compatibility to be introduced..... And I share the general skepticism that it will be so.

I think this portability or vendor independency of OpenCL will kill the enthusiasm of the FPGA vendors to promote this language. Will the same happen to OpenCL as that happened to SystemC a decade ago?

I longed to see A's OpenCL tool to support the ARM+AXI4+FPGA SoC architecture rather than supporting the PC+PCIe+FPGA arch, but this does not happen until now. The hardware platform is not the bottleneck. The CPU and the on-chip Bus has all the power, and the application demands for OpenCL to differentiate the target embeded products are not rare. I believe the reason is not from engineering but from marketing. They need something proprietary to stop the users from easily moving to the other side.

Why does not X get into the OpenCL and A hold on its OpenCL release for SoC arch? Is it because of the Openness of it and the Portability non-issue?

Hi, Brian: So far about a year has passed, several bloggers have ZED boards, and the biggest deal has been that Adam Taylor has an OS running on one core and bare metal on the other.

Xilinx changed Vivado and has a new architecture for the latest device that seems to emphasize HLS rather than ARM SoC. (haven't heard much about Altera)

Sure makes me wonder about the popularity/success of ARM on FPGA.

OpenCL is just a generalization of the Graphics PU concept rather than a general system solution to the memory wall/ von Neumann bottleneck.

Just as in most designs most paths are not critical for performance but absolutely necessary for product success. As you know, I am working on a design that is programmable using "C" source. It takes 3 true dual port memory blocks and 100 to 200 LUTs. NO proprietary HW or RISC.