3 ms·

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

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.

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.