This diagram does a good job showing the performance benefits of specialized hardware versus a generic intel chip. An i7's energy efficiency is a fraction of the performance of that of a GPU or an FPGA, and an ASIC blows everyone out of the water. Of course, as you rise the efficiency scale, you lose generality -- GPU's are only good at solving highly-parallel programs, FPGA's are hard to code, and ASIC's don't give you modifiability once they're made.

At the end of the day, specialization seems like the way to faster programs, but it comes at the price of generality. DSL's like spatial try and bridge that gap by providing programmers tunable, high level directives that can be composed to solve a wide array of problems.

To build off @trip's great summary, one of the main reasons FPGAs are hard to code is because they are slow to code. As discussed in class, a single iteration of an FPGA program can take upwards of 12 hours to complete.

I think the main issue for FPGAs is that they're slow when running - since they're made to be programmable, the dataflow needs to go through a lot of logic to perform a certain operation that an ASIC chip (specifically designed) might only take a few cycles.

I would think to adapt to LUTs, certain data types would be also very hard to use. Ie floats are probably not great to do computation by lookups require large trees of lookups to adapt to the various special cases, where fixed point could be done much more easily.

Also @trip, we do lose generality with ASICs, but what are the bottlenecks that prevent tweaking/producing ASICs for new use cases like we do with software? (other than the extra cost of a physical medium of course) If we can compile spatial code to an FPGA for example, can't we come up with a set of hardware primitives for various tasks and string them together for an ASIC using some other compilation process?