There's potentially tremendous value in having an open bitstream.
To get the most out of hardware, you need feedback on how many LUTs each part of your design uses, where the critical dependencies are for the achievable clock rates, and so on.
It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significantly worse.
Imagine there was the equivalent of LLVM for FPGA development. Without open bitstreams, that's never going to happen. (Even with open bitstreams, it'd need tremendous effort to get there, but at least there'd be a chance.)
Why do you think this information is unavailable today?
I can get the critical paths, device utilization, power, etc. from every vendor's software suite I'm aware of. And they are all fully scriptable from the TCL interface. Once I have a mostly stable design, I usually run Xilinx/Vivado from the command line. Same with Lattice. The reports the vendors provide are much better than what would get from the raw bitstream because it has all the symbol information. What you're proposing is akin to decompiling c from object code.
Also keep in mind there is huge variation in architectures between vendors, products, and the various product categories. For example, few things LUT based anymore. Now we have macrocells, "logic elements," and slices, etc. and that's just the soft stuff.
People have been working on implementing FPGA in higher level languages for years. Even LLVM to RTL has been tried a few times. I've observed matlab to RTL is starting to catch on in the DSP/control-system crowd.
LUTs are still the building block of all FPGAs. Logic elements are just a higher level of hierarchy.
For example, according to the Intel Arria 10 handbook, an ALM contains 2 4-input LUTs and 4 3-input LUTs, which can be combined in various ways. (See figure 7 of the A10 handbook.)
> To get the most out of hardware, you need feedback on how many LUTs each part of your design uses, where the critical dependencies are for the achievable clock rates, and so on.
In practice, if you code your Verilog with speed in mind (limited levels of combinational logic, plenty of pipeline stages, one-hot encodings, ...), the synthesis and fitter tool will do an excellent job of extracting high speed. The modern ones will do register clone, pull in registers into RAMs and DSPs etc.
In case of timing problems, the timing analyzer will already show you the critical path, the amount of LUTs, and how the critical paths is routed.
The hardest part of figuring out why a particular path is violating timing is not because of the reporting of the tools, it's because a blob of logic has been flattened and merged into a LUT, and it's hard to identify how a LUT corresponds to the RTL.
Maybe a custom tool can help debugging these kind of things, but I think it's a very narrow case, and IMO not the kind of thing that makes EDA tools unergonomic.
> It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significantly worse.
That was not my point.
My point is: if your goal is to make FPGA design more ergonomic (whatever that means), there's a much higher !/$ in improving the front-end design process than the back-end.
> The hardest part of figuring out why a particular path is violating timing is not because of the reporting of the tools, it's because a blob of logic has been flattened and merged into a LUT, and it's hard to identify how a LUT corresponds to the RTL.
... and we have no realistic hope of figuring out whether maybe the tools can be improved to help with that, because the tools aren't open :)
> if your goal is to make FPGA design more ergonomic (whatever that means), there's a much higher !/$ in improving the front-end design process than the back-end.
And my point was that it's impossible to do Pareto improvements as long as the back-end is a black box. Like, you could come up with a better high-level language for the "front-end", sure. And that new language may be more convenient for writing a design.
But if the way you synthesize this new language is via Verilog, then those nice features you mentioned, like for showing the critical path, will de facto be lost -- because the closed tools will show you the critical path in the intermediate Verilog. And if you've ever actually worked with HLS tools, you'll know that this intermediate Verilog is totally opaque unless you spend a very large time understanding the translation tool.
The new "front-end" solution will be better in some respects, but certainly worse in others, and the only way to get improvements across the board is if you have control over the whole "stack".
So I think you're making some good points, but I feel like you're missing the larger point that a truly open ecosystem is desirable precisely because improvement may come in places and from places that you would never have considered.
To get the most out of hardware, you need feedback on how many LUTs each part of your design uses, where the critical dependencies are for the achievable clock rates, and so on.
It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significantly worse.
Imagine there was the equivalent of LLVM for FPGA development. Without open bitstreams, that's never going to happen. (Even with open bitstreams, it'd need tremendous effort to get there, but at least there'd be a chance.)