[CamperBob2]

It's not a good idea to think of "programming" an FPGA to do anything. You're creating dedicated hardware. You tell a CPU what to do, while you tell an FPGA what to be.

When you're faced with a problem and you catch yourself thinking, "I wish I had an ASIC for this," your problem may be a good candidate for FPGA implementation. If what you're itching for is a faster CPU, or one that costs less or uses less power, then it probably isn't.

FPGAs are vital for interfacing to high-bandwidth custom hardware -- at least for those who don't have ASIC budgets -- and they're also useful for certain types of "embarrassingly parallel" problems that GPUs aren't well-suited for, especially where precision timing requirements and low latency are involved.

So, while you wouldn't typically resort to FPGAs when you're implementing an ordinary HTTP server, you might want to use them to build a dedicated TCP/IP offload engine, packet filter, or even a specialized memory controller. They are never going to be mainstream parts, even to the extent GPUs are. If and when you need an FPGA in your project, you'll know it.

[jeffreygoesto]

> You tell a CPU what to do, while you tell an FPGA what to be.

That is the shortest and best description for the difference I've ever read. Kudos. From now on I'll use it to answer questions about FPGAs for accelerating.

I used to tell people that you don't design algorithms but a network of operations and pipelines where you stream your data through.

[banachtarski]

It's a very common trope by FPGA enthusiasts.