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'

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.