He's annoyed that the HDL doesn't describe the entirety of a typical FPGA "program". Some things just can't be emulated efficiently by the FPGA fabric (or they are common enough patterns that it would be wasteful to do so) and the workaround that has become the de-facto standard is to include "ASIC chunks" in the middle of all the programmable gates. For instance, you might have a serial output that runs at 10Gbps while the rest of the FPGA runs at 500MHz. To bridge the gap between the slower programmable logic and the fast transceiver you need a shift register. The way you specify this in code is by importing a vendor-specific "library" -- except it's not really a HDL library at all, it's a black box that the proprietary back-end hooks up to to the "ASIC chunks" at compile time.
It's like compiling against a binary library, except that the binary isn't another piece of software, it's an etched pattern on your FPGA's wafer. Even if you did have the "source code" it wouldn't do you any good unless you have a foundry in your backyard :-)
I'm skeptical of the calls for a higher level of abstraction. How are you going to abstract away the fact that the FPGA has exactly 2 embedded memory controllers that have precisely A, B, and C inputs and X, Y, and Z outputs? Either you come up with a solution that's effectively just as ugly as what we have now (because it exposes the FPGA's resources explicitly) or you come up with a solution that hides these details and as a result becomes enormously fragile because it's easy to accidentally change something that prevents the compiler from inferring which embedded ASIC chunk you meant to use. You need to be aware of limitations to work within them, and the limitations seem to be stuck with us for the foreseeable future.
"How are you going to abstract away the fact that the FPGA has exactly 2 embedded memory controllers that have precisely A, B, and C inputs and X, Y, and Z outputs?"
The same thing we do every time, Pinky: assume the existence of a sufficiently advanced compiler. ;)
Wouldn't an ASIC have hard macros anyway? It sounds to me more like the author is annoyed that "it's 2014 and we are still using HDL", and also that FPGAs are somehow supposed to be readily exploitable for general-purpose computation.
It sounds like he doesn't think the level of abstraction offered is high enough. If you are using an FPGA as a general purpose device, and not for prototyping, then a higher level of abstraction would be helpful. Otherwise, if you are prototyping, you may want a lower level of abstraction that may offer a closer approximation to your end goal.
It's like compiling against a binary library, except that the binary isn't another piece of software, it's an etched pattern on your FPGA's wafer. Even if you did have the "source code" it wouldn't do you any good unless you have a foundry in your backyard :-)
I'm skeptical of the calls for a higher level of abstraction. How are you going to abstract away the fact that the FPGA has exactly 2 embedded memory controllers that have precisely A, B, and C inputs and X, Y, and Z outputs? Either you come up with a solution that's effectively just as ugly as what we have now (because it exposes the FPGA's resources explicitly) or you come up with a solution that hides these details and as a result becomes enormously fragile because it's easy to accidentally change something that prevents the compiler from inferring which embedded ASIC chunk you meant to use. You need to be aware of limitations to work within them, and the limitations seem to be stuck with us for the foreseeable future.