Lattice is seemingly at "wink wink, nudge nudge" levels of support -- their lawyers won't allow them to say anything because they're afraid of pissing off Synopsys, but they also know that they're currently the best supported platform, and don't seem interested in deliberately making things difficult.
I would like to see a FAANG try and support some open tools - it doesn't have to be anything legally sketchy like reverse engineering bitstreams - for example, Yosys only has limited SystemVerilog support
At some point I'd like to see it integrated as the frontend to tools like Yosys to get best-in-class SystemVerilog support in open tools.
I'm really liking Clash and Bluespec (Bluespec is completely open source now) but I don't want to write any conventional languages.
It compiles to Verilog, but the stack is much more integrated than other similar compile-to-verilog HDLs - the simulator is similar to verilator and much easier to get started with.
I'm kind of beginning to feel that Haskell isn't a good medium for HDL code - Verilog already encourages unreadable names like "mem_chk_sig_state" and Haskell code is almost unstructured to my eye (I like functional programming but it seems hard to keep it readable because of the style it imposes - the flow is there but the names are usually way too short for my taste)
In my opinion, the problem has always been their software: the FPGA vendor tools are slow, bloated monstrosities. The core of these tools are written by the big three EDA vendors (Cadence, Synopsys, and Mentor Graphics) rather than the FPGA vendors themselves. The licenses include ridiculous, paranoid restrictions [1] and force the FPGA vendors to keep their bitstream formats and timing databases secret [2] in order to prevent competition from other tool vendors. Most FPGA vendors didn't see this as a problem, but even the ones that did didn't have much of a choice, because the tool market is a cartel.
Thankfully, we now have an open source toolchain [3] with support for a growing number of FPGA architectures [4], and using it vs. the vendor tools is like using gcc or llvm vs. a '90s era, non-compliant C++ compiler. It even has a real IR that isn't Verilog, which has made it easier to design new HDLs [5].
I don't see how a dynamic FPGA accelerator platform can be even remotely viable without this. It's the difference between a developer getting to choose between one of a few dozen pre-baked designs that lock up the entire FPGA (and needing to learn how to shovel data into it), vs. a compiler flag that can give you the option of unrolling any loop directly into any inactive region of FPGA fabric.
It would be quite the cherry on top to see AMD build something interesting in this space. But unless they're willing to fully unencumber at least this one design, I think the effort is likely to fail. The open source guys are chomping at the bit to make this work, and have been making real progress lately. Meanwhile, the EDA vendors have been making promises, failing, and throwing tantrums for the last 20 years. It's time to write them off.
[1] https://twitter.com/OlofKindgren/status/1052822081652617221?...
[2] Imagine trying to write an assembler without being allowed to see the manual that tells you how instructions are encoded. It's like that, but the state-space is hundreds to thousands of bytes in multiple configurations rather than a few dozen bits.
[3] https://github.com/YosysHQ/yosys
[4] https://symbiflow.github.io/
[5] https://github.com/m-labs/nmigen