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?