> 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.
... 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.