Intel to set its FPGA unit free to pursue its own path
nextplatform.com
Intel to set its FPGA unit free to pursue its own path
1–10 of 84 posts
Re: Intel to set its FPGA unit free to pursue its own path
#2> We wouldn’t place heavy bets on Falcon Shores making it to completion unless a big HPC center adopts it, and given how Argonne National Laboratory was treated, we don’t think there will be a lot of uptake unless Intel makes some pretty big pricing concessions. Which it can ill afford. Hybrid CPU-GPU devices – the original plan for Falcon Shores, have also been shelved.
That's even more eyebrow raising than an Altera spinoff.
Altera is a good side business, but Falcon Shores is like Intel's consolidated future. If they just let that go... What do they expect? That everyone will just buy Xeon CPUs and IGP laptops forever?
Re: Intel to set its FPGA unit free to pursue its own path
#3Damn 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 static ratios of compute – > unless they are determining the ratios. Like the hyperscalers and cloud > builders, who can tell companies like Intel and AMD what their product > roadmaps need to look like.
What do not see what they mean by ratio here. Do they mean die ratio between cpu and fpga?
Re: Intel to set its FPGA unit free to pursue its own path
#4Damn 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 the LUTs, they become slower too.
And that's without solving the problem of closely coupling a CPU pipeline with FPGA logic.
> What do not see what they mean by ratio here. Do they mean die ratio between cpu and fpga?
What they mean is: in something like the Zynq FPGA family, I want a die with 2 CPU cores and 5000K LUTs. The other guy wants 8 CPU cores and 2000K LUTs. It works for narrow applications like signal processing where power efficiency and cost isn't a top concern, but for a hyperscaler, power consumption is a very important metric. As is the cost of paying for a significant part of the silicon die that's sitting there unused.
Re: Intel to set its FPGA unit free to pursue its own path
#5Damn 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…
"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
Re: Intel to set its FPGA unit free to pursue its own path
#6Damn 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…
Thanks for clarifying.
Re: Intel to set its FPGA unit free to pursue its own path
#7Damn 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…
This doesn't make a lot of sense. I mean, there are SOCs out there with asymmetric cores (say, an ARM A53 and an ARM M4 on the same die) for folks who's workloads warrant that sorta thing. I'd expect there'd be s similar market for CPUs, with built in FPGAs of various sizes.
Re: Intel to set its FPGA unit free to pursue its own path
#8[dead]
Re: Intel to set its FPGA unit free to pursue its own path
#9Thank 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 real work.
Intel also have completely ignored the low end of the market. The only true lowend part they have is the Cyclone 10LP, which is literally the exact same part as the cyclone 3/4 from 2008. Just slightly die shrunk. No hard IP support like ddr3 controllers, no MIPI, nothing that people are getting from the competition now.
Intel did realize this, which is why the new AgileX family includes some "low-mid range" parts, but they will be still much more expensive. Low-end to Intel means "under $1k unit cost" which ignores a huge part of the market.
They have better tools, documentation, and support than Gowin, who is a recent Chinese FPGA upstart using stolen Lattice IP and hires. But they will lose to Gowin by default in the commodity space unless they do something.
Re: Intel to set its FPGA unit free to pursue its own path
#10Damn 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…
This doesn't make a lot of sense. I mean, there are SOCs out there with asymmetric cores (say, an ARM A53 and an ARM M4 on the same die) for folks who's workloads warrant that sorta thing. I'd expect there'd be s similar market for CPUs, with built in FPGAs of various sizes.
It only makes sense for a few applications. See the popular Xilinx Zynq UltraScale MPSoC product line. They are popular for digital signal processing, for example. But they are not power efficient, and they are very expensive.
Good enough for a low volume custom solution for which custom silicon is too expensive. Not for a hyperscaler.