Live data from Hacker News

Intel to set its FPGA unit free to pursue its own path

nextplatform.com

61–70 of 84 posts

Re: Intel to set its FPGA unit free to pursue its own path

#61

Earlier quoted context omitted.

> It's one of those things that seem like a good idea, but they just don't work out in practice. GPGPU sucks a lot of air out of the room as well. There aren't many purely computational problems which FPGAs can solve better than a compute-optimized GPU; even though GPUs aren't quite as flexible, they clock a lot faster, they're cheaper, and they're easier to develop for.

I actually think there are a ton of problems which could benefit. But there is just very little mindshare. You basically have 1000x the people working on building software to run efficiently on the GPU. No way FPGA touches that. In addition it's a specialized set of skills to build high performance circuits. Whereas running on a GPU is "just" software. So even though I think FPGA could win out from an efficiency pers…

That's been a historically really good bet for processor architectures -- developer volume beats hypothetical performance.

Essentially the only time it's gone the other way was when there was a toehold in a critical market, where the benefits were so obvious and profitable that they made up for the difficulty (e.g. graphics).

Re: Intel to set its FPGA unit free to pursue its own path

#62

Thank goodness. I've been expecting this ever since Intel bought Altera, they just stuck with it a couple years longer than I figured. They focused solely on the high end, but it turns out nobody really wants FPGA fabric on a CPU. You can already do acceleration over a PCI express link, and that's what you more often do with embedded applications where the CPU is acting more like a dispatch controller than doing the…

They did not ignore the low end by choice. The entire story of Altera inside Intel can be summarized as: Intel fabs make amazing promises about process performance and availability. Altera builds their product stack on that. In the end, the fabs fail to deliver either performance, or sufficient amount of manufacturing capability. Now Altera has to pick which products they want to ship. They obviously can the low end.…

I've had Intel sales people tell me that the entire low end of some their marketed FPGA/ASIC products have never and likely will never be sold

Re: Intel to set its FPGA unit free to pursue its own path

#63
post #36

Earlier quoted context omitted.

They did not ignore the low end by choice. The entire story of Altera inside Intel can be summarized as: Intel fabs make amazing promises about process performance and availability. Altera builds their product stack on that. In the end, the fabs fail to deliver either performance, or sufficient amount of manufacturing capability. Now Altera has to pick which products they want to ship. They obviously can the low end.…

Do you have some citable sources for this? It sounds like it might very well be true, but, well, …

It was widely reported, e.g. https://www.semiaccurate.com/2019/09/23/altera-releases-stra...

Re: Intel to set its FPGA unit free to pursue its own path

#64

Thank goodness. I've been expecting this ever since Intel bought Altera, they just stuck with it a couple years longer than I figured. They focused solely on the high end, but it turns out nobody really wants FPGA fabric on a CPU. You can already do acceleration over a PCI express link, and that's what you more often do with embedded applications where the CPU is acting more like a dispatch controller than doing the…

What is even a "low-end" application of FPGAs, if you don't mind my asking?

Re: Intel to set its FPGA unit free to pursue its own path

#65
post #17

Earlier quoted context omitted.

> FPGA LUTs are just way too slow If, and of course that is a big if, you can repackage a (parallelizable) calculation into FPGA look-up tables and implement multiples of this (e.g. 8 to 80 times) then you can think maybe it's quicker than CPU at 3GHz. However, you have to include DMA of the data to and fro. It's unlikely to be worth the very extensive effort of integrating two wildly different technologies. On the o…

>However, you have to include DMA of the data to and fro. It's unlikely to be worth the very extensive effort of integrating two wildly different technologies. That is exactly the part where having the FPGA next to the CPU helps... You can transparently access the CPU cache via an AXI slave port on the CPU on AMD's MPSoCs at a rate of up to 16 bytes per cycle and you get multiple of those.

Hmm, very interesting! Didn't know that wa possible.

Re: Intel to set its FPGA unit free to pursue its own path

#66
post #64

Thank goodness. I've been expecting this ever since Intel bought Altera, they just stuck with it a couple years longer than I figured. They focused solely on the high end, but it turns out nobody really wants FPGA fabric on a CPU. You can already do acceleration over a PCI express link, and that's what you more often do with embedded applications where the CPU is acting more like a dispatch controller than doing the…

What is even a "low-end" application of FPGAs, if you don't mind my asking?

Some embedded stuff where the FPGA is used to implement some logic on I/Os, some processing that needs to be fast or implement some i2c, CAN, SPI controller trough IP core. Basically a more flexible way than having different chips on the board.

Re: Intel to set its FPGA unit free to pursue its own path

#67

Earlier quoted context omitted.

> I hoped that it would make sense to install certain instructions on your fpga depending on your workloads. It's one of those things that seem like a good idea, but they just don't work out in practice. FPGA LUTs are just way too slow. You'd have to find a case where doing something on a 3GHz CPU clock running multiple instruction parallel gets outperformed by LUTs that runs at 700MHz (at best). And when you cascade…

The right kind of sea of LUTs can outperform anything even if it's clocked at 100 Mhz... the trick is to get a pipeline filled, instead of trying to outrun light. Imagine an LLM with a new token every 10 nS

It is a totally different way of programming and thinking though and you need to spend a lot of thought on design to make it really fast. We could outpace a 3GHz CPU with a Zynq for image processing but it needs some really good FPGA people and the right split between CPU and FPGA. Nothing the average programmer wants to dive into, more something for cost and power sensitive markets with a relative fixed task, not needing ASICs yet. For networks it could pay off if you have the right amountof multipliers in the right places, but only then. As you wrote, don't leave the chip during the processing and you are good to go.

Re: Intel to set its FPGA unit free to pursue its own path

#68

Earlier quoted context omitted.

Intel doesn’t really make low end CPUs like that though. The Zynq is an awesome little chip and there really isn’t anything on the market to compare it to as far as I know. From my perspective sitting on the sidelines of this industry, Intel went all-in assuming companies would want FPGAs in the data centre the same way they want GPUs in the data centre and that bet didn’t pan out.

Intel does have the Cyclone 5 SoC which integrates Cortex-A9 cores much like the Zynq 7000 series. That product predates the acquisition though and they don't seem to have released anything to compete with newer entries in the Zynq lineup

But the bet was customers would buy Xeons with an FPGA block that would "do magic". What magic it would do and how you'd program it in a sane way was never specified in great detail. In any case for those that really want this it turns out you can put the FPGA on the end of a regular PCIe link and get all the same benefits.

Edit: By the way there is some niche research of the FPGA in core (which don't work if the FPGA is over PCIe). This paper describes a way to rearrange memory using a programmable FPGA-based memory controller to optimize database table accesses: https://arxiv.org/pdf/2109.14349.pdf

Re: Intel to set its FPGA unit free to pursue its own path

#69

Thank goodness. I've been expecting this ever since Intel bought Altera, they just stuck with it a couple years longer than I figured. They focused solely on the high end, but it turns out nobody really wants FPGA fabric on a CPU. You can already do acceleration over a PCI express link, and that's what you more often do with embedded applications where the CPU is acting more like a dispatch controller than doing the…

> They have better tools, documentation, and support than Gowin, who is a recent Chinese FPGA upstart using stolen Lattice IP and hires.

Naive of me to ask, but how are they allowed to sell anywhere outside of China?

Re: Intel to set its FPGA unit free to pursue its own path

#70

So many acquisitions end up like this you’d think the shareholders of possible acquiring company might want a “poison pill” or some other mechanism to prevent this kind of merger or maybe the government should make it much much much hardware for companies to merge, mot for the good of the consumer or vendors but for the poor shareholders.

It does feel quite strange. Altera spent the last 7 years getting rid of and merging all their HR/IT/Marketing/Sales/Legal and so on with Intel. All they had that was independent was engineering and planning, and even that wasmt entitely so. They need to start that all from scratch again. The inefficiency of it all astounds me.
Post reply on HN