APIs are just glue, what the FPGA world needs to be open is open compilers for high level hardware description languages.

However, there is little incentive for FPGA manufacturers to publish enough details for open FPGA compilers to be developed.

Unlike CPUs that can present a public ISA and handle fancy microarchitecture details behind the scenes, FPGA compilers require intimate knowledge of the particular FPGA's microarchitecture. No need to spill the secret sauce.

Also, when you target an FPGA, you target a single FPGA model. Change to a different model even in the same produce family you must recompile. BTW, for large FPGAs compilation can take all night.

And lastly, FPGA compilation is a graph embedding problem which is significantly more difficult that the sequential optimization problem CPU compilers handle. This is why it takes so long to compile for FPGA.

What do you think of Synflows HLS, IDE, and so on for that?

https://www.synflow.com/

I haven't seen hardly any FPGA users or experts review it.

This looks like a high level design entry language. It gets its portability by outputting verilog/VHDL code that is then fed into your synthesis (compiler) tools from your FPGA vendor.

There are fair number of these sorts of languages out there. Currently I'm using Altera's OpenCL kit which certainly falls into this high level design category.

The thing is that even if you're coding in a language that looks like C, you need to understand how hardware is inferred from it. Which requres a basic understanding of hardware concepts like state machines built from combinational logic and flip flops, as well as pipelining.

Bottom line on high level design... Plus side; gloss over details, focus on the workload. Down side; weird idioms, extra overhead compared to low level (i.e. Verilog).

All the HLL to HDL converters I know of require you to structure you HLL code as if it were HDL code. In other words, you are not absolved of understanding how things work at the hardware level and you can't just feed regular code into it and have it pop out hardware.

If you have to write stilted HLL to implement your design anyway, you might as well do it properly and write it in one of the HDLs instead.

>Personally, I suspect that until we have a good, open or OS provided API to FPGA configuration we're going nowhere. 3D acceleration required this in the form of OpenGL and DirectX.

There's no demand for it. There's nearly nothing that the consumer does that requires that level of hardware acceleration (with the possible exception of Photoshop) and server type applications are perfectly fine with custom software interfaces.

There is a huge demand, but it is already met by GPUs. FPGAs work much better for streaming and low latency applications though. See for example the Hololens processor, though that is an ASIC it could be done by an FPGA paired with a GPU.

You missed the whole gaming market in that. There's also offloading I/O (eg Bittorrent) and audio/video playback or conversion. In business desktops, I could see additional uses like security coprocessor or accelerating analysis of large data sets coded in parallelized R or something. Plenty of use-cases in HPC with them long being consumers of FPGA's, ec. Server farms, esp cloud, are competing on performance per watt with FPGA's being champs in that in certain workloads.

So, I see plenty of opportunities on consumer and business side. I think adoption in consumer space will be quite low like with other high-end equipment.

OpenCL runs on FPGAs.