Slashdot Mirror
Xilinx and AMD: an Inevitable Match?
itwbennett writes: Steve Casselman at Seeking Alpha was among the first to suggest that Xilinx should buy AMD because, among other reasons, it 'would let Xilinx get in on the x86 + FPGA fabric tsunami.' The trouble with this, however, is that 'AMD's server position is minuscule.... While x86 has 73% of the server market, Intel owns virtually all of it,' writes Andy Patrizio. At the same time, 'once Intel is in possession of the Altera product line, it will be able to cheaply produce the chip and drop the price, drastically undercutting Xilinx,' says Patrizio. And, he adds, buying AMD wouldn't give Xilinx the same sort of advantage 'since AMD is fabless.'
They could simply get an ARM license and design an ARM server CPU with their FPGA in the same chip.
The manufacturing could be done in Samsung or Globalfoundries since they aren't competitors and are probably going to have the next best manufacturing process next to Intel.
AMDs license for x86 becomes invalid if they are purchased by another company.
There is no evidence whatsoever that Xilinx will buy AMD. It's just some random idiot's speculation.
Before this it was Samsung will buy AMD, the Chinese will buy AMD, Intel will buy AMD, etc.
If AMD wanted to add an FPGA into their design, I am sure that Xilinx would sell them all the parts they wanted. No need to buy the company.
I'm sure someone will correct me if I am wrong, but I thought AMD's license for the x86 instruction set becomes invalidated if they get bought out.
I've been waiting for this tsunami for about a decade. I don't really see it catching on the way things are now.
External or daughter card FPGA boards have been available for a long time now, but can be expensive and used by few people for very specific applications. I own an FPGA board, but not a single one of my coder friends does.
But, if PCs (and servers) start coming with integrated FPGA fabric, that could open up a lot of possibilities to the more adventurous enthusiasts/hobbyists/developers. And with that, further momentum, to eventually build into a tsunami.
Or not. Designing logic to make FPGAs worth the trouble is harder than coding.
The Intel-Altera deal, while beneficial for Altera shareholders, is not any kind of huge win for Intel. Intel was already Altera's fab partner, and there's very little incremental revenue compared to the cost. $2B/year for a $17B acquisition, even at a modest discount rate, is a questionable ROI.
The reason is that this deal is questionable is that system design considerations vary considerably, and a fat CPU like an Intel Xeon is not always the best match for a networking application with an FPGA that close. Most of these server-side applications are, in any event, I/O bound in a server environment. That means fast backplane technologies for interfacing the various physical layer devices for networking and storage. Integration of programmable logic rather than putting it on a daughter card with a dedicated interface defeats the purpose of the flexibility that the FPGA provides in this environment, and that's to be able to bridge new and emerging standards while standard products eventually come in and take up the slack. Too little programmable logic and you have to replace the entire part. Too much, and you're killing your margins even now that gates are supposedly "free". Why would a system architect bother taking the risk on that without substantial advantages over the lifetime of their rack-mount beast? And this is essentially true whether or not the die is integrated or put in an multi-chip module or 3D die stack. Even if we consider other applications such as artificial intelligence and image processing, there are already alternatives out there including dedicated processors and GPUs that are doing much of this today, and they're off-the-shelf parts without dependency on the host CPU which - again - would be an I/O bound operation that you wouldn't necessarily want to involve the CPU in directly.
Bringing this to Xilinx, AMD - as the article suggests - has even less presence in server. More importantly, AMD is always 1-2 generations behind in process technology versus Intel, which translates to even greater sensitivity to how much FPGA one devotes to the die. There is no Xilinx fab relationship with AMD since it's effectively fabless. Xilinx and Altera also play in other spaces where x86 is either not relevant or insufficiently so to justify integration (e.g. automotive, broadcast). All of the above points for Intel-Altera apply even more for AMD-Xilinx.
Even in 2015, we're still dealing with external GPUs and Ethernet PHYs on small motherboards. Unless an application reaches true ubiquity and the cost-benefit is clear, integration for integration's sake is a losing cause. If Xilinx and AMD merge, it may very well hurt both companies. Stay tuned.
While you technically may be correct, Intel is a company with a history and reputation of abusing it's monopoly position to put competition out of Business to the detriment of consumers and the market as a whole.
Guess what happens as soon as Intel threatens to revoke their license? I'm sure AMD would be allowed to pursue their X86 endeavors while the anti-trust case began it's processing.
And when it fails, we can blame Intel for going out of business.
The point is, Intel plays by different rules and their Altera purchase represents a smaller percentage of their total worth. But the most important reason you shouldn't copy Intel is if there is an x86+FPGA market, you will never be able to beat Intel at it. If Intel wants your niche, they will take it from you. If Intel has already moved there before you even started, now you don't even have the ability to establish a new market, losing the only minute advantage there is.
I recommend trying to come up with a new idea that Intel isn't actively pursuing. Get some customers and lots of patents, then when Intel wants to take it from you, they at least have to do some costly patent settlements.
“Common sense is not so common.” — Voltaire
Im almost exclusively AMD in my little shop. The price of entry on manycore esxi host machines is but a fraction of intels. We aren't needing super fast single core performance tho.
My raid 8x 10 sas drives 2U 32 core 64gb rig came in around 8g's Canadian. I doubt intel could touch that value.
Intel came out and said it out right that if AMD was bought by someone else, their current agreement for x86 would be NULL.
If anybody buys AMD, you can say hello to the x86 monopoly of intel... Because AMD will now only be able to make ARM CPUs and GPUs.
If I remember after the last AMD/Intel spat, AMD will lose access to Intels patents if they a bought out. It would have to be a reverse buyout.
Xilinx and AMD aren't a good match. Xilinx has not been targetting the server market. They target custom embedded systems. (See DARPA challenge robots). Now that Altera is focusing on the server market and not on embedded, Xilinx can probably take over that entire space. It seems pretty clear that Altera(Intel) will dominate the server market, Xilinx will dominate the embedded market, Actel will dominate the space/irrational government contractor market, and Microsemi(Lattice) will remain largely irrelevant. At this point, I think the only thing that would change things is if one of these companies gets off their ass and open sources their toolchain so the community can make software support for these parts which isn't completely awful/unusuable.
Ok, so Cyrix was bought by National Semiconductor, which in turn sold Cyrix to VIA. I wonder how much of Cyrix ended up going into VIA's line of C7/Nano processors. . . Did anyone on here actually own a Cyrix machine?
If Xilinx happened to want x86 I'm quite certain AMD would be willing to work with them on a semi-custom part. I bet they could even do an interposer based solution similar to their upcoming HBM GPU design if the price was right. Why buy the cow when you can get milk delivered for reasonable NRE costs?
Meh. Only five years ago AMD had very competitive products in the server range. Opterons were efficient and cheap.
.
I remember Windows Azure launching in Europe with mostly Opterons inside and Steve Jobs buying that capacity to launch iCloud.
The servers at my workplace used to run on Opterons, too. Then our provider changed to Intel (you could still get AMD, but you needed to pay extra) and eventual server upgrades lead to total disapperance of AMD from my previous company
I am pretty sure AMD was not a single digit player in the server market back then.
So if AMD has a change of control, they loose the ability to make their main product, then structure the deal so AMD buys or merges with XLNX.
Intel should welcome the deal. Not because it makes AMD go away, but because it makes them more likely to stay around. First, Intel is a much better company because they have AMD to keep them innovative. Second, the Intel/Altera joining will first give Altera direct access to the Intel fab technology and lock them to the Tick/Tock schedule pipeline. Xilinx would not get the fab side benefits. Eventually, both pairs will start melding the CPU and fabrics. Again, having Xilinx out there will help keep the Intel gorrilla more nimble.
The really interesting question is what should the meld products look like?
One thing that is bugging me is that when you load random s/w on a pc, you expect that it might kill the pc, but 'kill' just means you have to wipe the storage and reload it. With a random config in an fpga, 'kill' can mean you let some smoke out and you have to replace the fpga. For the meld to become common in the server market, this needs to somehow be addressed.
Another thing is the stark contrast between the s/w tools available for cpu's and the tools available for fpga's. While it is true that the fpga tools have advanced remarkably since the 80's, they still have a long way to go to get to where an average s/w designer can do much with them. Even a person experienced in high performance, pipelined, hand scheduled, multi-functional unit, processing s/w will have trouble. Given this, maybe the right way to think of the meld is not so much a general purpose compute speeder-upper, but rather more like a reconfigurable compute/io device onto which you can load specific packages.
External memory access seems a real pain in an fpga. The first thing I'd like to see in a CPU/FPGA meld is to give the fabric good, coherent access to the memory bandwidth on the CPU side of the cache. This, perhaps with more external b/w, might help both compute assist and networking applications.
For 100gig packet processing, getting to where you can use the fabric to move packets to memory, parce and edit them, with the cpu doing classification seems a good first step.