5 ms·

Sounds like a bit of a gimmick. FPGAs are typically used in ASIC development to emulate the ASIC being developed. I've seen boards with 20 FPGAs emulate an AS

by YZF 12y ago

Sounds like a bit of a gimmick. FPGAs are typically used in ASIC development to emulate the ASIC being developed. I've seen boards with 20 FPGAs emulate an ASIC design at <~1/10th of the speed at >>x10 power. While FPGAs are programmable hardware they are far less efficient than custom hardware for various reasons. Naturally ASIC emluation is an application where FPGAs have a very large advantage over software... At volume they're also a lot more expensive and good tools are also very expensive (virtually no mass produced commercial product uses FPGAs). Now obviously if the FPGA is inside the Xeon you're not really paying much more for it (except you lose whatever other function could be crammed in there). Companies like Microsoft, Facebook, Google have enough servers to make a custom block inside Intel's CPU more attractive than an FPGA in terms of price/power/performance (and they can get that from ARM vendors which is probably scaring Intel). CPU vendors have spent the last several decades moving more and more applications that used to be in the realm of custom hardware to the realm of software. There are certainly niches of highly parallelizable operations but a lot of general purpose compute is very well served by CPUs (and a lot of it is often memory bandwidth bound, not compute bound). Some of these niches have already been semi-filled through GPUs, special instructions etc. The FPGA on the Xeon is almost certainly not going to have access to all the same interfaces that either a GPU or the CPU has and is only going to be useful for a relatively narrow range of applications. I think what's going on here is that as the process size goes down simply cramming more and more cores into the chip makes less and less sense, i.e. things don't scale linearly in general. So the first thing we see is cramming a GPU in there which eventually also doesn't scale (and also isn't really a server thing). Now they basically have extra space and don't really know what to put in it. Also each of the current blocks (GPU, CPU) are so complicated that trying to evolve them is very expensive. EDIT: Just to explain a little where I'm coming from here. I worked for a startup designing an ASIC where FPGAs were used to validate the ASIC design. I also worked on commercial products that included FPGAs for custom functions where the volume was not high enough to justify an ASIC and the problem couldn't be solved by software. I worked with DSPs, CPUs, various forms of programmable logic, SoCs with lots of different HW blocks etc. over a long long time so I'm trying to share some of my observations... If you think they're absolutely wrong I'd be happy to debate them. EDIT2: Re-reading what I wrote it may sound like I am saying I am an ASIC designer. I'm not. I'm a software developer who has dabbled in hardware design and has worked in hardware design environments (i.e. the startup I worked for was designing ASICs but I was mostly working on related software).

astrodust 12y ago
FPGAs are terrible at emulating ASICs, but CPUs are even worse, yet FPGAs do excel at certain problems that can be expressed as programmable logic that operates in a massively parallel manner. What if the Intel FPGA did have access to the same resources as a GPU? This isn't inconceivable, it's in the same socket as the CPU. This gives you the ability to implement specialized algorithms related to compression, encryption, or stream manipulation in a manner that's way more flexible than a GPU can provide, and way more parallel than a CPU can handle.
- CamperBob2 12y ago
  What if the Intel FPGA did have access to the same resources as a GPU? This isn't inconceivable, it's in the same socket as the CPU. An FPGA that competes with a modern GPU would probably cost in the neighborhood of US $50,000 per chip.
  - astrodust 12y ago
    In a general sense, yes, but not in very narrow problems where the GPU would stumble and flail because of architectural limitations that would prevent it from fully applying itself.
- YZF 12y ago
  Because the CPUs are so tightly coupled to their peripherals (e.g. the L1 cache) it is extremely hard to give other blocks on the same chip the same access. I've seen this over and over in SoCs. Something like a video codec, even though it's on the same die, doesn't have a tight interface to the CPU. Even something like a SIMD unit doesn't always have the same interfaces though it's part of the CPU. Being on the same die is better than being on a separate chip but there are some internal interfaces that rely on placement and latency on the die. E.g. it's unlikely that you can add new instructions to a CPU via FPGA or have the FPGA interact with the L1 cache. It's more likely there will be some sort of shared memory and standard peripheral interface to the FPGA (e.g. interrupts, I/O). EDIT: So to expand on this the FPGA is expected to have a relative high latency to the CPU and a relative low bandwidth to external resources (e.g. if you compare the CPU interface to L1). It's unlikely that the FPGA will have the same cache hierarchy that a CPU core has (size and performance). So it'll be useful where change is expected, the bottleneck is compute, the task is highly parallelizable, the standard instruction set/other blocks aren't very good at, and going for a pure ASIC solution doesn't make sense (either in a separate block or onboard a customer version of the same chip) either because of price/time/volume.

by YZF 12y ago

astrodust 12y ago

FPGAs are terrible at emulating ASICs, but CPUs are even worse, yet FPGAs do excel at certain problems that can be expressed as programmable logic that operates in a massively parallel manner. What if the Intel FPGA did have access to the same resources as a GPU? This isn't inconceivable, it's in the same socket as the CPU. This gives you the ability to implement specialized algorithms related to compression, encryption, or stream manipulation in a manner that's way more flexible than a GPU can provide, and way more parallel than a CPU can handle.

CamperBob2 12y ago
What if the Intel FPGA did have access to the same resources as a GPU? This isn't inconceivable, it's in the same socket as the CPU. An FPGA that competes with a modern GPU would probably cost in the neighborhood of US $50,000 per chip.
- astrodust 12y ago
  In a general sense, yes, but not in very narrow problems where the GPU would stumble and flail because of architectural limitations that would prevent it from fully applying itself.
YZF 12y ago
Because the CPUs are so tightly coupled to their peripherals (e.g. the L1 cache) it is extremely hard to give other blocks on the same chip the same access. I've seen this over and over in SoCs. Something like a video codec, even though it's on the same die, doesn't have a tight interface to the CPU. Even something like a SIMD unit doesn't always have the same interfaces though it's part of the CPU. Being on the same die is better than being on a separate chip but there are some internal interfaces that rely on placement and latency on the die. E.g. it's unlikely that you can add new instructions to a CPU via FPGA or have the FPGA interact with the L1 cache. It's more likely there will be some sort of shared memory and standard peripheral interface to the FPGA (e.g. interrupts, I/O). EDIT: So to expand on this the FPGA is expected to have a relative high latency to the CPU and a relative low bandwidth to external resources (e.g. if you compare the CPU interface to L1). It's unlikely that the FPGA will have the same cache hierarchy that a CPU core has (size and performance). So it'll be useful where change is expected, the bottleneck is compute, the task is highly parallelizable, the standard instruction set/other blocks aren't very good at, and going for a pure ASIC solution doesn't make sense (either in a separate block or onboard a customer version of the same chip) either because of price/time/volume.