Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nextplatform.com

Post reply on HN
Print view View original

31–40 of 84 posts

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

#31

Post by bfrog »

trsohmers wrote: post #13
mips_r4300i wrote: post #9

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 announced the new Agilex 3 line, which should include some CPLD price point parts and be a real rebirth for ~$100/unit modern devices.

Lets see I guess... I'm not holding my breath, but it'd be great to not use Vivado's slow ass Java IDE one day. Quartus is light years faster seemingly.

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

#32

Post by aleph_minus_one »

SilverBirch wrote: post #23

Yeah it was really funny watching Intel buy Altera at the same time that they were spinning out McAfee and thinking “well we’ll see how long this lasts…” Big chunk of the team from Altera are at AMD now anyway. Hopefully they finally get back to innovating on the actual FPGA now. I’m so tired of the hardened rubbish and cpu integrated rubbish.

> I’m so tired of the hardened rubbish and cpu integrated rubbish.

Was there actually a way to access a CPU-integrated FPGA as an "ordinary" user/customer (i.e. not a "special customer")?

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

#33

Post by bfrog »

tverbeure wrote: post #11
bfrog wrote: post #5

Earlier quoted context omitted.

"a customizable fpga into our CPUs" that already happened, it just didn't happen in x86 land. There have been a good number of products from various vendors that connect up hard cores and fpga fabric. power pc cores, riscv cores, and by large arm cores

That's not what OP meant though. They were talking about custom CPU instructions implemented with FPGA logic.

That doesn't sound that beneficial honestly

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

#34

Post by KirillPanov »

tverbeure wrote: post #4
almatabata wrote: post #3

Damn i hoped we would one day get a customizable fpga into our CPUs. I hoped that it would make sense to install certain instructions on your fpga depending on your workloads. I guess this either kills that possibility or pushes it into a very far future. I do not understand this part though: > There was talk of hybrid CPU-FPGA packages, which never seem to get > commercialized because no system architect likes stati…

> 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…

> where doing something on a 3GHz CPU clock running multiple instruction parallel gets outperformed by LUTs that runs at 700MHz

Easy: go wide.

Make the FPGA-CPU interface four times wider on the FPGA side than the CPU side. Each tick of the CPU clock reads (or writes) one quarter of the bits.

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

#35

Post by snvzz »

thenobsta wrote: post #14

Every time I see an FPGA article, I feel a little sad that Tabula[1] didn't make it -- 1.6Ghz clock and reprogrammable on the fly. RIP. 1. https://en.wikipedia.org/wiki/Tabula,_Inc .

Note the link is broken becuase the dot needs to be within the URL.

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

#36

Post by eqvinox »

Tuna-Fish wrote: post #25
mips_r4300i wrote: post #9

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.…

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

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

#37

Post by rthomas6 »

mips_r4300i wrote: post #9

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…

> nobody really wants FPGA fabric on a CPU.

Not true... Xilinx sells a lot of their Zynq, MPSoC, and RFSoC chips. Though I guess those are more CPU on an FPGA.

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

#38

Post by rowanG077 »

duskwuff wrote: post #16
tverbeure wrote: post #4

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…

> 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 perspective for some problems there is just not enough people/companies working on it to win out. It also doesn't help the tools are raging proprietary garbage fires.

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

#39

Post by rowanG077 »

throwaway4590 wrote: post #12
almatabata wrote: post #3

Damn i hoped we would one day get a customizable fpga into our CPUs. I hoped that it would make sense to install certain instructions on your fpga depending on your workloads. I guess this either kills that possibility or pushes it into a very far future. I do not understand this part though: > There was talk of hybrid CPU-FPGA packages, which never seem to get > commercialized because no system architect likes stati…

Whenever I see talk about Intel's FPGA unit, I link back to an invention I submitted to Intel while I was an intern there [0]. I went through the patent pipeline, but to my knowledge they never did anything with it. This was during the excitement of Intel's original acquisition of Altera. In fairness, I never mocked up a true enough implementation in Verilog to get an idea of real world speedup, and even now, I'm not…

I mean. If you, the original author, didn't even bother implementing and testing the idea why would you expect someone else would? I personally wouldn't touch such a project with a thousand foot pole.
Post reply on HN